【CSL】CSL緊急注意喚起レポート
～新手のSQLインジェクションを行使するボットの確認～

1. はじめに

新手のSQLインジェクション攻撃を実行するボットを確認しました。このボットに関しては海外¹でも報告されています。この攻撃は、マイクロソフト社製のWebサーバIIS/ASP/ASP.NET上で開発されたWebサイトを狙ってデータベースの改ざんを行います。改ざんを狙うボットや攻撃はこれまで数多く存在していました。今回、注意喚起を行う理由は、攻撃方法が、これまでほとんど観測されていない手法だからです。

 

この攻撃の特徴は、IDS/IPS/WAF²などの防御システムをすり抜けること並びにサイトの管理者が気づきにくくすることが目的と推測されます。

弊社の監視センターJSOCでも、9月30日早朝からこの新手のSQLインジェクション攻撃を検知し、また、実際に被害にあったサイトも確認されたため、広く注意を喚起するものです。

これらの情報が、皆様方の今後のセキュリティ対策に少しでもお役立ていただければ幸いです。当社は、ネットワークが安全に保たれ、日本の皆様が安心して利用できるよう、ネットワークの安全のために今後も研究調査を続けていく所存です。

なお、本文書の利用はすべて自己責任の下でお願いいたします。本文書の記述を利用した結果生じるいかなる損失においても、株式会社ラックは責任を負いかねます。

本レポート上に記載されている会社名および製品名は、各社の商標または登録商標です。

 

2. 今回確認されたSQLインジェクション攻撃の特徴

今回のSQLインジェクション攻撃には、2つの特徴があります。

1. Cookieを使用してSQLインジェクションを行う。
2. インジェクションされる攻撃コード（SQL文）が、IDS/IPS/WAFなどの防御システムによって検知されないようにされている。

特徴1：

表1が、今回確認したSQLインジェクション攻撃のIIS³のアクセスログとなります。下線部分がSQLインジェクション攻撃を実行する文字列となります。この文字列はCookieに含まれていた内容です。これまでのSQLインジェクションでは、HTTPのGETまたはPOSTリクエストの変数として、攻撃の実行文字列をWebアプリケーションに送り込んでいました。今回、確認したSQLインジェクション攻撃では、Cookieを使用して、インジェクションをかけるパラメータと攻撃の実行文字列を送り込んでいます。なお、IISの初期設定ではCookieの内容はアクセスログに記録されません。よって、初期設定状態で運用しているサイトでは攻撃が来ていることすら認識することが出来ません。（後述、JSOCで観測している攻撃元IPアドレスで攻撃の有無を調査する方法はあります。）

 

表1 アクセスログの例

Webアプリケーションがパラメータを受け取る方法として、通常はGETやPOSTのどちらかを指定して行いますが、実際、どちらの方法でも受け取れるようにプログラミングを行っていることも多々見かけます。IIS/ASP/ASP.NETにおいては、GETやPOST以外にCookie経由でもパラメータを受け取ることが出来る仕様になっているため、この攻撃はそれを悪用したものと考えられます。（Cookieにてパラメータを受け取れるフレームワークはIIS/ASP/ASP.NET以外にPHPも同様と確認していますが、現時点では他のフレームワークの状況は当研究所では未確認です。）

この攻撃の本質は、使用しているCookieの値に対してインジェクションを行うということではなく、GETやPOSTで渡されると期待されている値を、GETやPOSTの代わりにCookieを使用して受け渡すものであり、その狙いは、防御システムを回避しようと企んでいると推測されます。

実際に、Webサーバには下記のようなリクエストが送信されます。

 

表2 Cookieを利用したSQLインジェクションのGETリクエスト

また、代表的なIDS/IPS製品において、Cookieを利用したSQLインジェクション攻撃が検知できるか否かを表3にまとめました。

 

表3 Cookieを利用したSQLインジェクション攻撃の検知可否（2008年9月29日現在）

IDS/IPS	検出・防御可否 ベンダーオリジナル	検出・防御可否 JSOC追加機能
製品A	×	○
製品B	×	○
製品C	○	○
製品D	×	×

また、オープンソースで開発がすすめられているSnortでは、下記のようなシグネチャを作成することで、このCookieを使用したSQLインジェクション攻撃を検知できると考えられます。

 

表4 Snortシグネチャ例

※注意：後述する特徴2は考慮していません。通常のIDS/IPSレベルで特徴2に対抗するのは極めて困難であると考えられます。

 

特徴2：

今回のSQLインジェクション攻撃では、IIS/ASPの仕様を悪用し、挿入するSQL文を工夫することで、IDS/IPS/WAFなどの防御システムを回避する試みが確認できました。こちらのほうが特徴1よりも問題が大きいと推測しています。下記が、その工夫が見られるIISのアクセスログです。下線の箇所を注目してください。キーワードの中に%が含まれています。この%は続く2文字が16進数であることを表しています。例えば、%20はスペースに%3Dは=に置換されます。IIS/ASPでは、%に続く文字が16進数表記できない文字列が続いた場合、%を除去して、WebアプリケーションにSQL文を送り込みます⁴。この場合、「DEC%LARE 」や「e%xec」はそれぞれ「DECLARE 」や「exec」としてWebアプリケーションに渡されます。よって、構文エラーなどにならず、（当該WebアプリケーションにSQLインジェクションの脆弱性が存在した場合）攻撃SQL文が実行されてしまいます。多くのIDS/IPSでは、リクエストに含まれる特定のキーワードとのパターンマッチにより、SQLインジェクションの試みを検知します。このため、検知するキーワードの中に無効な%が含まれると、検出するのが非常に困難になります。また、WAFにおいても％の取扱において、このIIS/ASPの仕様を理解していないと、IDS/IPSと同様に検出できない可能性があります。

 

表5 IISのアクセスログ

また、本件はSQLインジェクションに止まらず、以下のようなクロスサイトスクリプトにおいても同様の問題が生じます。

の代わりに、

 

3. 攻撃による影響

このSQLインジェクション攻撃が成功した場合、どのような影響を受けるのかを解説します。2の特徴1にて、実際のアクセスログをご紹介しました。実際の攻撃文字列はCAST文により難読化処理が施されています。この難読化処理を解除したものが下記の通りです。下線が挿入されるSQL文となります。このSQL文が実行されると、全てのユーザ定義テーブルの文字列フィールドにscriptタグ

が埋め込まれてしまいます⁵ 。

 

表6 難読化を解除した攻撃文字列

このscriptタグが埋め込まれたフィールドから編集したWebサイトを閲覧すると、悪意あるWebサイトに誘導されて、次の脆弱性を悪用した攻撃コードが実行されてしまいます。

• Microsoft Data Access Componentの脆弱性（MS06-014）
• Microsoft Access Snapshot Viewerの脆弱性（MS08-041）
• Adobe FlashPlayerの脆弱性
• NCTsoft NCTAudioFile2 ActiveXコンポーネントの脆弱性
• REALNETWORKS RealPlayer ActiveX コンポーネントの脆弱性

上記の脆弱性を悪用した攻撃コードのうち、どれか一つでも侵入に成功すると、ユーザーのクライアントPCに不正プログラムが次々とダウンロードされ、実行されてしまいます。不正プログラムが実行されると、ユーザの閲覧したWebサイト履歴が監視されたり、金融・ゲームサイトにログインする際にアカウント情報が奪取されてしまいます。

また、Adobe FlashPlayerの脆弱性を悪用するFlashファイルを調査してみると、Flashファイルの中に"ly20088.asp?gameee="という文字列が含まれます。さらに攻撃コードの中にも"I LOVE gameee TEAM"という文字列が確認できました。このgameeeを含む文字列は、SQLインジェクションを実行するASPROXボットで確認されています。このため、今回のSQLインジェクションを実行しているのは、ASPROXボットの亜種と考えられます。

今回は、この新手の攻撃手法がボットにより行使されましたが、通常の侵入や情報窃取のための手法やツールへの応用は、当研究所並びにJSOCでは、現時点では確認していません。今後、新たな被害を生まないよう、継続して注視を続けます。

 

4. 対策

まず、攻撃が来ているか否かを調査してください。無償のSecureSite Checker Freeで確認できます。

ログがうまく取得できていない場合は、データベース内のフィールドにscriptタグが埋め込まれていないか確認してください。万一、被害が確認された場合、一度サイトを停止し、データベースのクリーニング、再発防止策を講じて再開されることをお勧めします。

＜対策の骨格＞

SQLインジェクションなどのWebアプリケーション対策は、本命の脆弱性を持つWebアプリケーションでの対策（W）と、その前面で防御するフロントライン（F）、後ろで守るバックライン（B）並びに、全体として見える化を行う（L）に分けることができます。

※SQLインジェクション攻撃への対策については、CSL、DBSLの最新レポート、および情報処理推進機構（IPA）が提供するドキュメントをご参照ください。

また、今回のSQLインジェクション攻撃に特化した対策としては、下記をあげます。ご参考になれば幸いです。

1）GETおよびPOSTでの変数取得処理の実装について（W）

IIS/ASPにおいては、変数取得の処理に注意する必要があります。Requestオブジェクト（ASP.NETの場合、HttpRequest.Params）から変数を取得するように実装していると、今回のようなCookieに実行文字列を設定したSQLインジェクションの影響を受ける可能性が高くなります。そのため、GET・POSTそれぞれにおいて、GETであればQueryStringから、POSTであればFormから変数を取得するように実装する必要があります。

http://msdn.microsoft.com/ja-jp/library/cc338801.aspx
http://msdn.microsoft.com/ja-jp/library/system.web.httprequest.params(VS.80).aspx

次にリクエストからparam変数を取得する事例をご紹介します。

表7 param変数取得例

 

2）アクセスログへのCookie情報の記録（L）

本来は、脆弱性を作りこまない開発基準やWebアプリケーションの脆弱性を修正することが基本だと考えますが、現実問題として、すぐに修正することが困難な場合も多々あります。そのため、SQLインジェクション攻撃を検知する仕組みとして、次の設定変更を推奨いたします。

今回標的となったIISでは、初期設定の状態ではCookie情報がアクセスログに記録されません。そのため、アクセスログにCookie情報を保存するよう、設定変更することが望ましいです。設定方法については、下記のMicrosoft社のWebサイトをご参照ください。

Microsoft: Customizing W3C Extended Logging (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/96af216b-e2c0-428e-9880-95cbd85d90a1.mspx?mfr=true

 

3）攻撃元IPの制限（F）

暫定的な対策となりますが、今回の攻撃元IPは現在の観測では以下の２つのIPアドレスです。ファイアウォールなどで制御してください。

61.152.246.157（中国）
211.144.133.161（中国）
（※上記IPアドレスには、決してアクセスしないでください）

 

4）データベーストリガを活用した改ざんコマンドのロールバック（B）

上記で紹介した、DBSL最新レポート 「緊急対応から見たWebサイト用データベースセキュリティ対策」内でも紹介していますが、データベーストリガにて、挿入されたSQL文をデータベース実行時にキャッチして無効にする方法となります。

今回の場合、挿入されるscriptタグは

（※Webサイトへは決してアクセスしないでください）となりますので、以下のようなデータベーストリガを組み込むことも有効です。

表8データベーストリガ例1

或は、

表8データベーストリガ例2

今後、iframeタグが挿入されることも考えられるため、表8も考慮して良いかもしれません。

表8データベーストリガ例1

いずれにせよ、データベースサイドで組み込む対策は、他への影響などが無いか良く考慮し、自己責任において実施をお願いします。

5）WAFの導入（F）

本問題をクリアしたWAFの導入を検討する。サイトごとに投資可能な金額は異なると思いますが、今後、益々悪質になることを考えると、費用対効果は高いと考えます。

 

6）セキュアなWebアプリケーション（W）

SQLインジェクションを防ぐことが出来なくとも、データベースから表示（HTML文を生成）するときに、サニタイジングを行う手段もあります。ただし、汚染されたデータベース（SQLインジェクションにより改ざんされた）で運用を継続してよいかどうかは良く吟味をしなければならないポイントです。

最後に、当社JSOCで検出しているSQLインジェクションの最新トレンドを以下に示します。

（クリックすると拡大）

これを見ると、SQLインジェクションアタックは6月・7月に一時落ち込みましたが、9月に入り再度急増していることが分かります。今後、この種の攻撃は、益々巧妙に既存の防御システムを回避するようにさらに悪質化することが想定されます。現状に安心することなく、常に防御システムが機能しているのか、異変は起きていないか、確認できるようにしておくことが肝要です。

以上