急増したSQLインジェクション、McColo遮断の影響は：川口洋のセキュリティ・プライベート・アイズ（12）

　皆さんこんにちは、川口です。昨年末に実家へ帰省した際、中学時代の同級生と16年ぶりに同窓会を開きました。久しぶりに生存確認ができた友人、見た目も中身も変わっていない友人、見違えるように変化している友人など、それぞれ違った時間を過ごしていたことが分かりました。懐かしい話に花を咲かせる時間はあっという間に過ぎてしまいました。昨年末は16年ぶりの同級生の変化を楽しんでいましたが、インシデントの変化は楽しい変化ばかりではありません。今回は2008年11月、12月と大きく変化した傾向について解説します。

ネット界の悪の枢軸？ McColoとインターネットの関係

　まず、McColoの遮断の影響とSQLインジェクションの関係性について説明します。

　McColoとは、スパム送信を容認していたホスティングサービス会社です。スパム送信業者はこのMcColoと契約し、大量のスパムを送信していました。このMcColoが2008年11月12日にインターネット接続を遮断されたことがニュースになっています。

　スパム送信業者御用達のMcColoがインターネットから遮断されたことで、スパムの量が減ったという情報も出ていました。日々、スパムに悩まされている私にとっても大変うれしいニュースでした。しかし、McColoは別のISPと契約し、再接続してきたことでスパムの量が回復しつつあるという情報もありました。

　スパム送信に関する話題が多いMcColoですが、それ以外の活動はどうだったのでしょうか。私はMcColoのネットワークからの攻撃がJSOCのシステムに記録されているかを確認しました。2008年の1年間を調査したところ、疑わしいアクセスとしてはポートスキャンのみ検知しており、そのほかのSQLインジェクションやバッファオーバーフローなどのような攻撃は検知していませんでした。McColoを利用していたスパマーはスパム送信に明け暮れていたのでしょう。もしくはボットネットのコントロールサーバ（通称C＆C）として活動し、世界中のボットを操り攻撃を仕掛けていたために、McColoのネットワークを経由した不正アクセスは記録されていなかったのかもしれません。

McColo遮断とSQLインジェクションとの関係

　次にMcColo遮断の影響を確認しました。McColoがボットネットを悪用してSQLインジェクションを行っていた場合、McColoの遮断によって攻撃が減少しているはずです。McColoが遮断された11月12日前後のSQLインジェクションの検知傾向は以下のようになりました。

グラフ1　11月14日ごろのSQLインジェクション検知件数

　11月13日を境にしてSQLインジェクションの件数が減少しています。これはMcColoの切断によってSQLインジェクションを行うボットへ指令が送られなくなったことが影響しているのでしょうか。グラフ2は11月全体のSQLインジェクションの検知傾向を示したものです。

グラフ2　11月全体のSQLインジェクション検知件数

　このグラフを見ると、11月の前半から攻撃の件数は少なくなっており、11月14日から減少しているというよりも11月13日あたりに一時的に攻撃が急増しているようです。残念ながらこのデータではMcColo遮断の影響は分かりませんでした。

　気になることは11月12日からSQLインジェクションが急増した原因です。それは、10月に注意喚起を出したIDS／IPSの回避を狙ったSQLインジェクションが多数のIPアドレスから再開されたからです。

　このSQLインジェクションは2008年10月頭でいったん終息しており、それ以降は従来と同様の（IDS／IPS回避を狙っていない）SQLインジェクションが行われていました。しかし、この時期になって再びこの巧妙なSQLインジェクションが行われるようになりました。しかも前回の攻撃と比較して攻撃元IPアドレスの数も多く、間違いなくボットネットを使って攻撃していることが分かります。

　McColo遮断とSQLインジェクションの急増、何かの偶然なのでしょうか。JSOCのセキュリティアナリストはMcColo遮断に喜ぶ間もなく多数のSQLインジェクションの対応に追われていました。

2008年12月からSQLインジェクションが急増

　2008年11月に一時急増したSQLインジェクションも再び落ち着き、12月になりました。このまま年末年始を平穏に過ごせるか、と淡い期待をしていた12月14日、SQLインジェクションが再び急増しました。折しもその日はフィギュアスケートの浅田真央選手のグランプリファイナル優勝に関連して、韓国から2ちゃんねるが攻撃されている日でした。

　2008年12月14日から急増したSQLインジェクションはいままでと比べものにならないほどの攻撃件数でした。1日で約30万件の攻撃を検知しており、多い日で120万件以上のSQLインジェクションを検知しました。11月までは月間26万件が最高の検知件数でしたが、わずか数時間でそれを上回るほどの攻撃が集中して行われました。12月のSQLインジェクションの検知傾向を示したものが以下のグラフです。

【緊急注意喚起】改ざんされたWebサイト閲覧による組織内へのボット潜入被害について[12/24更新] | LAC via kwout
グラフ3　12月のSQLインジェクションの検知数

　12月14日から急増していることが分かります。また2005年からのSQLインジェクションの検知傾向を示したものが以下のグラフです。

SQLインジェクション攻撃検知数（2008年12月まで） | LAC via kwout
グラフ4　2005年からのSQLインジェクション攻撃検知数の推移

　2008年12月は11月と比較して、約100倍に攻撃が増加しています。いままで注意喚起を出してきたものとは比べものにならない変化になっています。攻撃元IPアドレスは1日に5000以上にもなりました。世界中の5000台以上のボット感染パソコンが攻撃者によって悪用されているものと考えています。

　ちょうど、12月10日ごろからInternet Explorerの未公開の脆弱性を狙った攻撃コードが出回っており、今回のSQLインジェクションで誘導される悪性サイトにもこの脆弱性を悪用する攻撃コードが仕込まれていました。攻撃者は修正プログラムがリリースされるまでのわずかな時期を狙って、攻撃を開始した可能性が高いのではと考えています。

　攻撃元IPアドレスの国別の分類を示したものが以下のグラフです。

グラフ5　攻撃元IPアドレスの国別統計グラフ

　攻撃の実に6割以上が韓国から行われており、2ちゃんねるへの攻撃とまったく無関係ではないのでは、と私は考えていますが、関連する情報は見当たらないようです。2008年前半は中国からの攻撃が大部分を占めていましたが、2008年夏ごろから攻撃元が世界中に分散するようになり、そして12月は韓国、日本を中心としたIPアドレス群から攻撃が行われました。同じ国からの通信はファイアウォールで遮断対応することが難しいことを狙い、攻撃対象の周辺国に存在するボットネットを悪用して攻撃を行っているのでしょう。

　12月からは攻撃手法も複合化されました。データベースの改ざんを狙ったSQLインジェクションに加え、データベースの情報を盗む目的でのSQLインジェクションも同時に行うようになりました。データベースの改ざんと情報の詐取、一石二鳥を狙う意図が見えます。その結果、1つの攻撃元IPアドレスから同時に5回以上のSQLインジェクションのリクエストが連続して行われるため、攻撃の件数も比例して増加しました。

攻撃対象の変化……まるでパズルのように

　改ざん被害に遭ったサイトにも特徴がありました。改ざんされたサイトから誘導される悪性サイトにはjp.jsやkr.js、cn.jsという国を識別するJavaScriptコードが用意されていました。攻撃者は日本のサイトを改ざんした場合には、jp.jsを、韓国のサイトを改ざんした際にはkr.jsというように挿入するJavaScriptコードを変えているのでしょう。これにより悪性サイトへ誘導されるユーザーに対してより効率的に攻撃を行えます。jp.jsとkr.jsというJavaScriptコードを持つ悪性サイトについて検索エンジンで改ざんされたサイトを調査したところ、日本語と韓国語のサイトが多くありました。今回のSQLインジェクションは日本と韓国のサイトに対して、集中的に行われたのかもしれません。

　12月下旬からはSQLインジェクションで注入される文字列の中にいままでに見られなかった奇怪なものがありました。以下のような文字列をデータベースに挿入しようとしています。

　現在も行われている攻撃の多くはscriptやiframeタグを埋め込むものですが、この攻撃はHTMLとして解釈不可能な文字列を埋め込もうとしています。この文字列が埋め込まれたサイトをWebブラウザで参照した場合、HTMLとして解釈されず、ホームページにそのまま表示されます。

　これら文字列は一見意味がないように見えますが、最近よく挿入されている文字列（<script src=http://）と近いだろうと予想しました。「<raqmtr$r……」と「<script src……」の文字コードを比べてみると、10文字ずつ0123446419という数字でXOR（排他的論理和）をかけられていることが分かります。それぞれ以下のように変換できます。

　このように0123446419 という数字でXORすることによりそれらしい文字列を導き出すことができましたが、変換前のままではHTMLとして解釈されず、意味のない文字列として処理されてしまいます。では、攻撃者の狙いは何だったのでしょうか？

1. SQLインジェクションのUPDATEコマンドの直前にXORし、復元する
2. この攻撃の後、別の攻撃によってXORするコードを埋め込み、復元する
3. 特定のWebブラウザの脆弱性で実行できてしまう環境が存在する（私はそのような脆弱性は知りませんが）
4. 脆弱なサイトをマーキングする
5. 攻撃元の環境によって勝手に変換されてしまった

　いずれも推測の域を出ませんが、今後の動向に注意しています。

　今回の攻撃急増の影響で、お客さまに通知するインシデントの数も増加しました。その結果、毎月発行している月次報告書のボリュームが大きくなり、あるお客さまでは前月の4倍のサイズになってしまいました。

　その報告書を見たITとはまったく無縁なスタッフが「このお客さまの報告書が厚くなっていますが、攻撃が増えましたか？」と専門家でない人にも分かるほどの攻撃の増加だったのです。セキュリティと直接かかわりのない人に伝えるにはこれくらい分かりやすくならなければならないものだなと思いながら、今夜も分かりにくいことを伝える能力を磨くため、飲みに行くのでした。