3月2日に、@IT編集部主催の「@IT セキュリティソリューション Live! in Tokyo」にて、NTTデータ先端技術の辻さんとインターネットイニシアティブの根岸さんとともに、ランチセッションに出演してきました。辻さん&根岸さんのトークに絡ませてもらい、あっという間にランチセッションは楽しく終了しました。
事前の準備中はあれだけいろいろと話そうと思っていたのに、いざ始まると時間が足りないくらい盛り上がりました。ちょっと物足りないと思うくらいがいいのかもしれませんね。その会場で使った、2002年と2012年付近の出来事を示した資料がこちらです。
私はちょうど10年前の2002年にラックに入社しました。振り返ってみればあっという間の10年の社会人生活です。こうしてみると、いろんなインシデントがリアル世界とサイバーの世界で起こっていたんだなと懐かしくなります。
さて、最近はどのセミナーに行っても、旬な話題は「標的型攻撃」です。私もいろんなところに呼ばれるたびに「とりあえず今回の(プレゼンorセミナーの)テーマは標的型攻撃でお願いできますか?」といわれることが多く、たくさんの方が注目しているインシデントであることを実感しています。
標的型攻撃の話ばかり取り上げていては私も飽きてしまうので、他のネタを探していたところ、弊社のセキュリティ監視センターJSOC(Japan Security Operation Center:ジェイソック)で少し珍しいSQLインジェクションを観測しました。今回はその珍しいSQLインジェクションについて取り上げます。
余談ですが、@ITの読者はWeb系の記事を書くと引きが強いという傾向があるようですので、たまには取り上げなければと思っていたところです。決して、遅筆をお詫びする意味で書いているわけではありません(笑)。
今回取り上げるSQLインジェクションは、以下のようなリクエストから始まります。
何やらunion selectとして16進数で文字列を指定した後、into outfileを使ってファイルに書き込んでおり、攻撃対象としてMySQLを狙ったもののようです。User-Agentにはいかにも普通のブラウザのようなものが設定されています。このリクエストをデコードしてみた結果は、以下のようになります。
少し見やすくなりました。さらに、0x6A7573745F615Fで始まっている部分をデコードすると以下のようになります。
union selectとinto outfileを使い、以下のようなPHPファイルを作成しています。
このPHPファイル自体には特に害をなすような処理は入っていません。アクセスすると特定のメッセージを表示して、自身を削除するようになっています。
攻撃者は、このようなSQLインジェクションと、それによって作成されたファイルへのアクセスを「1セット」として攻撃を行っています。作成したファイル(jatest7.php)にアクセスすると、以下のようにレスポンスコードとメッセージが出力され、対象のWebアプリケーションが脆弱であるか否かを確認できるようになっているのです。
つまり攻撃者は、このようなSQLインジェクションを仕掛けることで、対象のシステムが「MySQLで動いているか?」「ファイルが作成可能か?」「ファイルが削除可能か?」ということを判別しています。
実はこのような攻撃手法は、2008年から散見されていました。以前のケースでも、全く同じようなPHPファイルが作成され、「jatest2.php」や「jatest3.php」という名前が付けられていました。
その後、最近まであまりこのような攻撃は行われていなかったのですが、3月になって一時的に攻撃が復活したようです。このタイプのSQLインジェクションの攻撃観測状況は以下のようになります。
2011年を通して、ほとんどこのようなSQLインジェクションは行われていないことが分かります。期間を2012年3月に絞って詳しく見てみると、次のような観測結果になりました。
2012年3月13日に急に攻撃が増加しましたが、3月16日には収束しています。
実は「ちょうどいいタイミングでコラムのネタができた」と執筆準備に入った矢先に、この攻撃が行われなくなってしまいました。攻撃対象となった環境もあまり多くはなく、検索エンジンを使用して、何らかのキーワードにマッチするWebサーバに対して攻撃を仕掛けたのではないかと推測しています。
次に、このSQLインジェクションの攻撃元IPアドレスを分類してみました。
どうも日本のIPアドレスから行われることが多いようです。攻撃元IPアドレスのおよそ半分ではWebサーバが稼働しており、そのうち9割ではApacheが稼働していました。もしかすると、脆弱性があるApache+MySQL環境に侵入し、そこを踏み台にして攻撃を行っているのかもしれませんが、いまのところはっきりとした証拠はつかめていません。
ここまでMySQLが稼働するWebアプリケーションをターゲットにした攻撃について紹介しましたが、偶然、PostgreSQLが稼働するWebアプリケーションをターゲットにしたSQLインジェクションも観測しました。
castで型変換エラーを起こしてデータベースの情報を参照するタイプの攻撃ですが、少し気になったのは以下の点です。
2005年以降、SQLインジェクションはメジャーな攻撃手法になりました。攻撃件数が非常に多くなっているため、かえって攻撃件数が少ないものが気になったのです。
【関連記事】
川口洋のセキュリティ・プライベート・アイズ(1)
あの「SQLインジェクション」騒動の裏で(前編)
http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/001.html
この攻撃がピンポイントで行われていることが気になって調査してみたところ、対象となったシステムでは、いずれもPostgreSQLのエラー出力を含むページがGoogleにインデックスされていました。このエラー出力の結果からすると、対象のシステムにはSQLインジェクションの脆弱性があるのかもしれません。
ひょっとしたら攻撃者も同じように考え、PostgreSQLのエラー出力をGoogleで検索し、その検索結果に載っているシステムに対して攻撃を行ったのかもしれません。検索エンジンを使って攻撃対象をリストアップすること自体はよくありますが、「よくもまあ、PostgreSQLを選んだな」という印象でした。
ちなみに、以前データベースの管理ポートに対する攻撃の観測状況を記事にした際にも、PostgreSQLを狙う割合が最も少ないと紹介しました。SQLインジェクションについても、PostgreSQL環境をターゲットにした攻撃の割合は少ないです。とはいうものの、攻撃が行われる確率が低いとはいえ、PostgreSQL環境が侵入される事例もありますので、管理者の方は注意を怠らないでください。
【関連記事】
川口洋のセキュリティ・プライベート・アイズ(25)
実録・4大データベースへの直接攻撃
http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/025.html
今回は少し珍しいSQLインジェクションを取り上げました。
世間は標的型攻撃でにぎやかですが、相変わらず、ものすごい数のSQLインジェクションが日々やってきています。この事実を考えると、安全なWebサイトを作ることが大事であることに変わりはありません。「基本が大事である」ということは「@IT セキュリティソリューション Live! in Tokyo」でもお話しさせてもらいました。
なお、大盛況だった先日のランチセッションですが、実は一番盛り上がったのは講師控室でした。ランチセッションの前後に、辻さんと根岸さんと交わした会話の一端を紹介すると、
という具合で、「むしろ、こっちを中継した方が盛り上がるんではないか?」というツッコミがあったくらいです。この会話の続きを楽しむために、今日も飲みに行くのでした。
川口 洋(かわぐち ひろし)
株式会社ラック
チーフエバンジェリスト
CISSP
ラック入社後、IDSやファイアウォールなどの運用・管理業務をへて、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
アナリストリーダとして、セキュリティイベントの分析とともに、IDS/IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。
現在、JSOCチーフエバンジェリストとしてJSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。また、YouTubeのlaccotvにて、「川口洋のつぶやき」に出演中。
Copyright © ITmedia, Inc. All Rights Reserved.