サーバーがハッキングを受け侵入されるケースはこの数年、増加傾向にあります。ベライゾンが調査したケースにも、Web経由でのハッキングはたくさんあります。今回お伝えしたいのは、実はこのデータ漏洩の事例の大半で、Webサーバーのログに明確な痕跡が見つかっていることです。つまり、ログを確認する習慣をつければ、データ漏洩事件をすぐに見つけられる可能性が高まることになります。

図1●フォレンジック分析でデータ漏洩/侵害の証拠があった事件となかった事件の割合(対象はベライゾンの事例)
図1●フォレンジック分析でデータ漏洩/侵害の証拠があった事件となかった事件の割合(対象はベライゾンの事例)

 ベライゾンが毎年発行しているデータ漏洩侵害調査報告書(DBIR) の統計にも、この事実が数字として表れています。具体的には、フォレンジック分析でデータ漏洩の証拠が見つかった事例はケース全体の84%あります。そして、それらの証拠は大抵、アプリケーションログやシステムログといったログデータの中に見つかっています。

 データ漏洩のほとんどのケースでは、第三者からの指摘を受けて初めて、自社が攻撃を受けデータ流出が起きたことに気づいています。ただ、それでは対処が遅れがちです。そこで重要なのが、攻撃の兆候や攻撃を受けたことをいち早く把握するために、ログを日々確認することです。以下で、あまり労力をかけずにWebサーバーのアクセスログ(以下Webアクセスログ)をレビューする方法を紹介しましょう。

まずログファイルのサイズをチェックする

 SQLデータベースを使用したショッピングサイトなどでは、SQLインジェクション攻撃は実際に行われる可能性が高い攻撃の一つです。SQLインジェクション攻撃による被害が初めて明るみに出てから既に10年以上たちますが、現在でもSQLインジェクションによる攻撃はなくなっていません。SQLインジェクション攻撃の特徴として、攻撃を受けた日のWebアクセスログのファイルサイズが通常時に比べて増大します。そのため、日ごとのWebアクセスログのサイズ比較により、攻撃を受けた日を特定できるケースがあります。

図2●ログファイルのサイズが平時よりも大きくなった場合は要注意
図2●ログファイルのサイズが平時よりも大きくなった場合は要注意
1日ごとのログファイルのサイズを調べると、攻撃を受けた日(サイズが増大した日)を特定できるケースがある。

 筆者が調査の初期段階でSQLインジェクション攻撃の有無を判断する場合は、Webアクセスログのリクエスト部分に注目して調べていきます。HTTPリクエストのうち、SELECTやUPDATEなどSQLコマンドが含まれているものだけを抽出、ソートし、上から眺めていきます。SQLインジェクション攻撃を受けている場合は、同じようなリクエストが数千、数万行にわたって続いているはずですから、そこで攻撃があったことに気づくことができます。また、この時点でSQLインジェクション攻撃を受けたWebページ、すなわち脆弱性のあるWebページが判明します。

 SQLインジェクション攻撃の場合、攻撃者は本格的な攻撃の前にデータベースの構造を調べることがよくあります。特にデータベース名、テーブル名、カラム名などの情報を取りに来ます。そこで、こうした調査・偵察用のリクエストがログの中に見当たらないか、探してみるとよいでしょう。通常のシステム運用ではこのような情報をWeb経由で取得する必要があるとは考えられませんので、もしこのようなSELECT文を含んだHTTPリクエストがある場合は、攻撃が行われる/行われたサインだと考えられます。

 このような攻撃でデータベース構造やテーブル構造が攻撃者に知られると、攻撃者は容易にデータベース内の情報にアクセスできるようになります。これが、もし共有サーバーを使ったショッピングサイトで発生すると、自社が攻撃の起点になって、他社サイトへの攻撃が発生する危険が膨らみます。反対に他社サイトの脆弱性を突かれて自社サイトが攻撃される場合もあります。

 ほかに、重要情報が入っているテーブル、カラムにアクセスしているHTTPリクエストを検索するだけでも攻撃の可能性を見つけることができます。ただ、まれにSQLインジェクション攻撃のコードが、一見しただけではアクセス対象が分からないように隠ぺいされている場合があります。例えばSQLインジェクションコードがASCIIコードに変換されたり、Base64などでエンコードされることがあります。通常のSQLコマンドの「SELECT」はASCIIコードでは「%53%45%4C%45%43%54」に、Base64エンコードでは「U0VMRUNUCg==」に、それぞれ変換されます。このような場合は、SQLコマンドをASCIIコードやBase64エンコード化した文字列でログを検索する必要があります。該当するログレコードの文字数が通常のログレコードと比べて極端に長くなることに着目することでも、SQLインジェクション攻撃が行われたことに気づくことができます。

 POSTメソッドでのHTTPリクエストも注意したい点です。自社サイトにないWebページなどからPOSTメソッドのHTTPリクエストがあり、サーバーのレスポンスコードが200(リクエスト受け付けに成功)になっている場合、既に侵入されていると考え、対処を始めるべきです。この場合は、POSTメソッドの送信元IPアドレスや、POSTリクエストを受け付けているページ名などを探すと、何が起きたかを推測できるログが発見できるはずです。

 最後にもう一つ、HTTPリクエストに含まれるクライアント情報にも目を向けます。これを見ると、通常のWebブラウザー以外でアクセスしてきているログを発見できることがあります。Webブラウザーではなく攻撃ツールが使われている場合には、このログから異常を察知できます。

 ここまで紹介した方法だけで、何が起こったのかを完全に把握できるわけではありません。それでも、Web経由の攻撃の、かなりの部分を発見できるでしょう。

 いずれにせよ、セキュリティ対策としては、重要な情報を守ることが第一です。漏洩した際のダメージが大きい情報は、外部から間接的にでもアクセス可能なサーバーには保管しないことをお勧めします。どうしてもオンラインでアクセス可能な領域に情報を保管する場合は、適切なデータ暗号化とその暗号鍵の安全な管理を徹底する必要があります。


鵜沢 裕一
ベライゾンジャパン
シニアコンサルタント
フォレンジック調査対応部