連載

2012年3月23日

ちょっと変わったSQLインジェクション：川口洋のセキュリティ・プライベート・アイズ（39）

[川口洋（株式会社ラックチーフエバンジェリスト CISSP），＠IT] PC用表示関連情報

LINE

Hatena

＠IT編集部のセミナーに出てきました

　3月2日に、＠IT編集部主催の「＠IT セキュリティソリューション Live! in Tokyo」にて、NTTデータ先端技術の辻さんとインターネットイニシアティブの根岸さんとともに、ランチセッションに出演してきました。辻さん＆根岸さんのトークに絡ませてもらい、あっという間にランチセッションは楽しく終了しました。

　事前の準備中はあれだけいろいろと話そうと思っていたのに、いざ始まると時間が足りないくらい盛り上がりました。ちょっと物足りないと思うくらいがいいのかもしれませんね。その会場で使った、2002年と2012年付近の出来事を示した資料がこちらです。

図1　2002年と2012年付近の出来事

　私はちょうど10年前の2002年にラックに入社しました。振り返ってみればあっという間の10年の社会人生活です。こうしてみると、いろんなインシデントがリアル世界とサイバーの世界で起こっていたんだなと懐かしくなります。

　さて、最近はどのセミナーに行っても、旬な話題は「標的型攻撃」です。私もいろんなところに呼ばれるたびに「とりあえず今回の（プレゼンorセミナーの）テーマは標的型攻撃でお願いできますか？」といわれることが多く、たくさんの方が注目しているインシデントであることを実感しています。

　標的型攻撃の話ばかり取り上げていては私も飽きてしまうので、他のネタを探していたところ、弊社のセキュリティ監視センターJSOC（Japan Security Operation Center：ジェイソック）で少し珍しいSQLインジェクションを観測しました。今回はその珍しいSQLインジェクションについて取り上げます。

　余談ですが、＠ITの読者はWeb系の記事を書くと引きが強いという傾向があるようですので、たまには取り上げなければと思っていたところです。決して、遅筆をお詫びする意味で書いているわけではありません（笑）。

MySQLを狙ったSQLインジェクション

　今回取り上げるSQLインジェクションは、以下のようなリクエストから始まります。

図2　MySQLを狙ったSQLインジェクション

　何やらunion selectとして16進数で文字列を指定した後、into outfileを使ってファイルに書き込んでおり、攻撃対象としてMySQLを狙ったもののようです。User-Agentにはいかにも普通のブラウザのようなものが設定されています。このリクエストをデコードしてみた結果は、以下のようになります。

図3　図2の内容をデコードした後のリクエスト

　少し見やすくなりました。さらに、0x6A7573745F615Fで始まっている部分をデコードすると以下のようになります。

図4　さらにデコードしたリクエスト

　union selectとinto outfileを使い、以下のようなPHPファイルを作成しています。

図5　作成されるPHPファイル

　このPHPファイル自体には特に害をなすような処理は入っていません。アクセスすると特定のメッセージを表示して、自身を削除するようになっています。

　攻撃者は、このようなSQLインジェクションと、それによって作成されたファイルへのアクセスを「1セット」として攻撃を行っています。作成したファイル（jatest7.php）にアクセスすると、以下のようにレスポンスコードとメッセージが出力され、対象のWebアプリケーションが脆弱であるか否かを確認できるようになっているのです。

レスポンスコードが「404 Not Found」だった場合
　→SQLインジェクションが失敗
レスポンスコード「200 OK」かつ「c6db3524fe71d6c576098805a07e79e4not_unlinked」だった場合
　→SQLインジェクションでファイル作成は成功しているが、ファイルの削除は権限などの問題で失敗
レスポンスコード「200 OK」かつ「c6db3524fe71d6c576098805a07e79e4unlinked」だった場合
　→SQLインジェクションでファイル作成が成功し、かつファイルの削除が可能であることを確認

　つまり攻撃者は、このようなSQLインジェクションを仕掛けることで、対象のシステムが「MySQLで動いているか？」「ファイルが作成可能か？」「ファイルが削除可能か？」ということを判別しています。

3月に突然急増した攻撃件数

　実はこのような攻撃手法は、2008年から散見されていました。以前のケースでも、全く同じようなPHPファイルが作成され、「jatest2.php」や「jatest3.php」という名前が付けられていました。

　その後、最近まであまりこのような攻撃は行われていなかったのですが、3月になって一時的に攻撃が復活したようです。このタイプのSQLインジェクションの攻撃観測状況は以下のようになります。

図6　2011年4月から1年単位で見た、「ちょっと変わった」SQLインジェクションの観測状況

　2011年を通して、ほとんどこのようなSQLインジェクションは行われていないことが分かります。期間を2012年3月に絞って詳しく見てみると、次のような観測結果になりました。

図7　2012年3月の攻撃観測状況

　2012年3月13日に急に攻撃が増加しましたが、3月16日には収束しています。

　実は「ちょうどいいタイミングでコラムのネタができた」と執筆準備に入った矢先に、この攻撃が行われなくなってしまいました。攻撃対象となった環境もあまり多くはなく、検索エンジンを使用して、何らかのキーワードにマッチするWebサーバに対して攻撃を仕掛けたのではないかと推測しています。

　次に、このSQLインジェクションの攻撃元IPアドレスを分類してみました。

図8　攻撃元IPアドレスの国別分類

　どうも日本のIPアドレスから行われることが多いようです。攻撃元IPアドレスのおよそ半分ではWebサーバが稼働しており、そのうち9割ではApacheが稼働していました。もしかすると、脆弱性があるApache＋MySQL環境に侵入し、そこを踏み台にして攻撃を行っているのかもしれませんが、いまのところはっきりとした証拠はつかめていません。

PostgreSQLを狙ったSQLインジェクションも

　ここまでMySQLが稼働するWebアプリケーションをターゲットにした攻撃について紹介しましたが、偶然、PostgreSQLが稼働するWebアプリケーションをターゲットにしたSQLインジェクションも観測しました。

図9　PostgreSQLを狙ったSQLインジェクション

　castで型変換エラーを起こしてデータベースの情報を参照するタイプの攻撃ですが、少し気になったのは以下の点です。

攻撃件数が非常に少なく、ターゲットも少ないこと
この攻撃リクエスト以外のSQLインジェクションを検知していないこと
環境としては少ないPostgreSQLを狙っていること
Accept-Languageがロシア語であること
攻撃元IPアドレスもロシアであること
過去数カ月、JSOCではこの攻撃元IPアドレスからの攻撃を観測していないこと

　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」でもお話しさせてもらいました。

　なお、大盛況だった先日のランチセッションですが、実は一番盛り上がったのは講師控室でした。ランチセッションの前後に、辻さんと根岸さんと交わした会話の一端を紹介すると、

パスワード管理どうしてる？
人材育成が大事だよな～
アメリカ人のFacebookの使い方について
（その数日後に予定されていた）Appleの新製品発表をリアルタイムで見るか否か
次のコラムのネタを何にするか
外国人にガジェットの自慢をされた話
診断手法の中身を整理しないといけないんじゃないかという話
3月31日にAnonymousがやるらしい「オペレーションブラックアウト」はどうなのか
アダルトななでしこ
オカンからAnonymous逮捕を知らされる

という具合で、「むしろ、こっちを中継した方が盛り上がるんではないか？」というツッコミがあったくらいです。この会話の続きを楽しむために、今日も飲みに行くのでした。

Profile

川口　洋（かわぐち　ひろし）
株式会社ラック
チーフエバンジェリスト
CISSP

ラック入社後、IDSやファイアウォールなどの運用・管理業務をへて、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。

アナリストリーダとして、セキュリティイベントの分析とともに、IDS／IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。

現在、JSOCチーフエバンジェリストとしてJSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。また、YouTubeのlaccotvにて、「川口洋のつぶやき」に出演中。

「川口洋のセキュリティ・プライベート・アイズ」バックナンバー