クッキーに隠されたSQLインジェクション、対策は？：川口洋のセキュリティ・プライベート・アイズ（8）

　皆さん、こんにちは、川口です。先月、私は遅めの夏休みを取り、草津温泉に行ってのんびりとした休日を過ごしてきました。温泉に入って、おいしい料理を食べて、お酒を飲んでまったりしていました。そんな夏休み明けを待ち構えていたかのようなインシデントについて解説します。

インシデント発生！

　2008年10月2日、ラックはプレスリリース「新手のSQLインジェクションを行使するボットの確認」を出しました。

　いままで何度もSQLインジェクションに関する注意喚起をしてきましたが、今回JSOCで観測したSQLインジェクションは以下のように攻撃手法が進化していたため、再度注意喚起を出しました。この手法の特徴は以下のとおりです。

• CookieにSQLインジェクション攻撃が埋め込まれている
• 攻撃自体にIDS／IPS／WAFの検知機能を回避する手法が取られているため、IDS／IPS／WAFを設置していても検知・遮断されないケースがある

　これをひとことで表現すると「IDS／IPS／WAFのようなセキュリティ機器を回避するためだけに攻撃手法が進化した」のです。今回の攻撃により、セキュリティ機器による検知・防御が難しい脅威が登場したといえます。また、通常のWebサーバの設定ではCookieの値のログを取得していないため、Cookieに含まれた攻撃の存在をWebサーバのログから確認できません。現在も攻撃を受けたことに気付いていないWebサーバの管理者は多数存在するでしょう。

Cookieに隠されたSQLインジェクション

　今回の攻撃の1つの特徴はCookieにSQLインジェクションが埋め込まれていることです。いままでのSQLインジェクションは以下のようなものが主流でした。

　今回観測したSQLインジェクションは以下のような攻撃内容でした。

　Cookieの値にSQLインジェクションが含まれていますが、注目すべきポイントはCookieに含まれているその形式です。URLの“/index.asp”の後に続くべきパラメータがそのままCookieに含まれています。ASPのRequestオブジェクト（ASP.NETの場合、HttpRequest.Params）を使っている場合、クエリ文字列やフォーム以外からでもデータを読み込めます。もしRequestオブジェクトから読み込んだデータの取り扱いにSQLインジェクションの脆弱（ぜいじゃく）性がある場合、データベースを操作されてしまいます。

IIS／ASPの機能を悪用

　今回の攻撃手法のもう1つの特徴は攻撃のリクエストに“%”を含ませることでセキュリティ機器の検知機能の回避を狙っていることです。%文字を含んだSQLインジェクションは以下のようなリクエストになっています。

　色を付けた「DE%CLARE」や「NVAR%CHAR」などに注意してください。HTTPリクエストに含まれるSQLステートメントの文字列の間に%が含まれています。通常%は16進数表記の場合に使用します。%20や%3DのようにASCIIに変換できる場合、IIS／ASPはその文字列を置換します。しかし、%CLや%STなどのように16進数表記できない場合には%文字のみを除去します。リクエストとしては%が入っていても、Webアプリケーションには%が入っていない状態で使用されるため、動作には問題がありません。

　攻撃者はCookieや%文字を使用するように攻撃の内容を変化させていますが、Webアプリケーションとしては正しく動作するように攻撃を細工しています。しかし、この細工によって攻撃の成功確率が上がるわけではありません。それでは、なぜ攻撃者は今回のように攻撃手法を変化させたのでしょうか。これについては先ほども触れたように私は攻撃者がセキュリティ機器を回避するためだけに攻撃手法を進化させたのではないかと疑っています。

回避されたセキュリティ機器

　IDS／IPS／WAFといったセキュリティ機器の基本機能は文字列のマッチングによる検知です。攻撃に利用される文字列をシグネチャとして定義し、その文字列を含んだ通信が発生するとアラートを出力する仕組みになっています。攻撃者の心理としてはセキュリティ機器のシグネチャに該当しないように、かつ攻撃としては成立するように攻撃を行うことを狙います。そこで攻撃者はIIS／ASPが%文字を除去する機能に目を付けました。以下のように攻撃者は%文字を含む攻撃を行います。その攻撃の過程で攻撃内容がどのように解釈されるかを示しています。

図1　新型SQLインジェクションにて、攻撃内容は各機器にどう解釈されているか

　このようにセキュリティ機器が処理する文字列とWebアプリケーションが処理する文字列が異なることを悪用して攻撃を発見されにくくしているのです。セキュリティ機器の開発者側としては単純に「DE%CLARE」「NVAR%CHAR」という文字列をシグネチャとして登録すればいいというわけではありません。攻撃者にはたくさんの選択肢があるからです。

• %文字を入れる位置は変更可能
  →「DECLA%RE」など
• %文字は1カ所に入るとは限らない
  →「DE%CLA%RE」「DE%%CLARE」など

　これらのパターンを網羅したシグネチャを定義した場合、数千種類以上のパターンが必要となります。その結果、セキュリティ機器のパフォーマンスに負荷がかかり、著しい影響を与えてしまいます。いまごろ各セキュリティ機器の開発者はハードウェアの限られたリソースでパフォーマンスを考慮しながら、シグネチャの開発を行っているでしょう。JSOCでも新しい脅威を検知するためにIDS／IPS用のオリジナルシグネチャ（JSIG）を開発して提供していますが、今回の攻撃にはとても頭を悩ませました。詳細について公開することはできませんが、攻撃者の心理を想像してチューニングしたJSIGを追加しました。

　今回の攻撃はCookieにSQLインジェクションが行われており、これもセキュリティ機器を回避する要因になっています。最近の高機能なセキュリティ機器はプロトコル解析機能が付いています。HTTPプロトコル解析機能は、どの部分がクエリでどの部分がCookieであるかなどを判別しています。リクエストの内容を解析し、ヘッダによって含まれる文字列の特性ごとにシグネチャを作成することで検知性能を向上させることがセキュリティ機器の開発者の狙いです。例えば、Snortのhttp_inspectプリプロセッサはHTTPのプロトコル解析機能を実装したプリプロセッサです。このプリプロセッサを組み込むことで、HTTPリクエストの中で解析する場所を細かく指定できます。

　現在行われているSQLインジェクションのほとんどはHTTPリクエストのクエリやフォームの部分に含まれています。プロトコル解析機能が付いているセキュリティ機器はクエリやフォームの部分を判別してその部分にSQLインジェクションを示す文字列が含まれていないかを調査します。攻撃者はSQLインジェクションのシグネチャがCookieを対象としていない可能性が高いことを知っており、ASPの仕様を悪用してCookieへSQLインジェクションを行ったのでしょう。CookieにSQLインジェクションが行われたことでプロトコル解析機能のあるセキュリティ機器の検知機能を素通りしてしまいました。

　今回はこの“高機能”である部分を逆手に取って攻撃が行われました。高機能であるがゆえ、攻撃者に狙われるという皮肉な結果となってしまったのです。攻撃者はセキュリティ機器のシグネチャとIIS／ASPの仕様について熟知しているのでしょう。

攻撃者の心理

　攻撃の内容自体はいままでと変わりはなく、Webアプリケーションの開発者が適切にアプリケーションを実装していれば被害を受けることはありませんので安心してください。つまり、これらのことから今回の攻撃はセキュリティ機能を回避するためだけに攻撃手法が進化していることが分かります。おそらく、攻撃者は世界中を何万件以上も攻撃するうちに、セキュリティ機器によってブロックされて、成功するWebサーバの数が頭打ちになったことを感じたのでしょう。攻撃者にとっては新しいターゲットが必要になり、攻撃手法の改良を行ったと考えられます。

　今回のSQLインジェクションは2008年9月30日の朝に数時間のみ行われました。その後、攻撃が沈静化していることがかえって不気味です。今回の攻撃は新型攻撃ツールの試し打ちをしたのでしょうか。2008年3月に注意喚起を出した件も実は2007年11月から攻撃を検知していました。2008年3月になり大規模な攻撃が行われ、さらにボットに組み込まれ、攻撃の規模が拡大しました。今回の攻撃で試し打ちをした後は、攻撃ツールのチューニングをし、ボットへの組み込みをして、大規模な攻撃を行ってくるのではないかとJSOCは警戒しています。

対策は？

　今回のSQLインジェクションの対策も「脆弱なWebアプリケーションを作らない」ことに限ります。WebアプリケーションにSQLインジェクションの脆弱性がなければ、Cookieに攻撃が行われても、%文字列を含む攻撃であっても影響を受けることはありません。セキュリティ機器によって大部分の攻撃を検知、遮断することはできますが、今回のような悪らつな攻撃手法は日々開発されており、回避される可能性がゼロではありません。やはりセキュアなアプリケーション開発に勝る対策はありません。

　Cookieからデータを読み込むためにはRequest.Cookiesが用意されていますので、これを使うことをお勧めします。クエリから値を読み込むためにはRequest.QueryStringが、フォームから値を読み込むためにはRequest.Formが用意されています。Requestオブジェクトを使っている、いないにかかわらずSQLインジェクションの脆弱性を生まないような実装をするべきことはいうまでもありません。しかし、意図しないパラメータからの値の取得をしないためにもRequest.Cookies、Request.QueryStringやRequest.Formなどを使い分けた方がよいでしょう。

　しかし、「脆弱なアプリケーションを作らない」ことが難しいのが現実です。そのために多層防御の概念が重要です。Webアプリケーション、データベース、セキュリティ機器を組み合わせた対策をお勧めします。多くのWebサーバの標準設定ではCookieをログに残すようになっていないため、Cookieをログに残す対策も検討してください。今回はスペースの都合上、そのすべてを記載できませんので「CSL緊急注意喚起レポート〜新手のSQLインジェクションを行使するボットの確認〜」を参照することをお勧めします。

　進化したSQLインジェクションによって、夏休みボケに浸る間もなく怒とうの1週間を過ごしました。今後も攻撃者の手法は進化し、さらに大規模な攻撃を仕掛けてくるでしょう。しつこい攻撃者に対抗するために、気力の回復も欠かせません。今日も「麹の宵」のたい飯に舌鼓をうちながら飲むのでした。