大規模インジェクション 「LizaMoon」攻撃について調べてみた。 - piyolog

piyolog

piyokangoの備忘録です。セキュリティの出来事を中心にまとめています。このサイトはGoogle Analyticsを利用しています。

大規模インジェクション 「LizaMoon」攻撃について調べてみた。

最近TL上で「新しいタイプのSQLインジェクション攻撃」というキーワードを見かけます。情報元をたどっていくとどうやらこの攻撃は「LizaMoon(ライザムーン)攻撃」という名称の模様。攻撃で用いられた手法があまりないパターンであったということでどういうものか調べてみました。
 

(1) LizaMoon攻撃とは何か

先月末、3/29にwebSenceのBlogに「新しい悪意ある大規模なインジェクションが行われた」として、次のポストが行われました。

Websense Security Labs and the Websense Threatseeker Network have identified a new malicious mass-injection campaign that we call LizaMoon. Websense customers are protected with the Advanced Classification Engine

LizaMoon mass injection hits over 226,000 URLs (was 28,000) − WebSence
 
このポスト以降、様々なニュース系サイトでLizaMoon攻撃による改ざんが行われていたことが明らかになり、有名なサイトではあのiTunes(Apple.com)のサイトも改ざんを受けています。今回はかなり大規模な攻撃が行われ、実に22万以上のサイトが改ざんされたとのこと。
この攻撃を受けるとどのようなことが起きるかといえば、まず行われるのはWebサイトが改ざん。その後、そのサイトをユーザーが訪れるとLizaMoonというホスト名の攻撃サイトに強制的に誘導されます(リダイレクトされる)。これがLizaMoon攻撃と呼ばれる所以で、攻撃サイトに誘導以降はMicrosoftが提供しているMicrosoft Security Essentialsに似た偽のアンチウィルスソフトのダウンロードを促され、このツールを通じてクレジットカード情報の入手などが行われます。
ちなみにLizaMoonのドメイン自体は3/25に開設されたばかりだそうです。
 
サイト閲覧から偽AVソフトをダウンロードさせられるまでの動画がYoutubeにあげられています。この偽アンチウィルスソフトを入れる流れは他の事例でも出ていたものと酷似しており、多くのアンチウィルスベンダの製品ではマルウェアとして検出が行われるように対応済みだそうです。

 
また、この攻撃はその特徴に単一のIPアドレスからの攻撃であるという点があげられ、多くのレポートでも取り上げられています。攻撃元のIPアドレスは「95.64.9.18」であり、誘導される様々なホストも同一のIPを指しているそうです。

ちなみに4/5時点でのAVベンダの対応は次の通り。

ベンダ 対応確認 ソース
Mcafee 対応済み(4/2)
TrendMicro 対応済み(3/30)
Symantec 不明(未評価)  
Sophos 対応済み(4/1)

 

(2) Webサイトが改ざんされるまでの流れ

どのようにして攻撃が行われるか、一連の流れはIBMのレポートが参考になります。
このレポートによると攻撃を行う前に、まず攻撃先のサイトが脆弱であるかどうかのチェックが十分に時間をかけて行われているそうです。そのため、2月ぐらいには次のようなSQLインジェクションの痕跡が見受けられたとレポートされています。
・DBの種類、バージョンの調査
・テーブル名、カラム名、カラムのデータタイプの調査

この調査により収集された情報をもとに攻撃コードが生成され、データベースの値にクロスサイトスクリプティング(持続型)を発動させるコードが保存されます。その値はWebサイト上に無効化されることなく出力されることが大半であるため、サイト上にスクリプトが埋め込まれてしまい、ユーザーにスクリプトを実行させる改ざんされた状態となります。SQLインジェクションクロスサイトスクリプティングの組み合わせで行われる攻撃と考えることが出来ます。
 
具体的な攻撃コードについては、次のFAQに投稿されたものが実際に行われた攻撃コードに近いものと推測されます。投稿された日付も去年の9月末であるため、今回の大規模攻撃の予兆自体はそのころから出始めていたのかもしれません。
Attack on ASP site that uses a SQL server database−StackOverFlow
 

(3) 対策

攻撃に用いられる手法は目新しいものではなく、SQLインジェクションであることに変わりはありません。そのため、いわゆるSQLインジェクションへの対策が取られていればこの攻撃による改ざんは行われません。仮に対策を検討する必要がある場合、参考に記載した安全なSQLの呼び出し方にある通り、静的プレースホルダを用いるのが最も良い選択ではないかと考えます。
 

(4) なぜこれが今流行しているのか

2009年にはGumbler型の攻撃が流行ったこともあり正規なWebサイトであっても、脆弱な個所が残っていれば改ざんされるという危険性は誰もが知っていたはずです。そのため、何故このような攻撃が今大規模に行われるようなことになったのか、社内のセキュリティチームの推測では、これが「数値リテラルSQLインジェクションを巧妙に利用した攻撃であるためではないか」とのこと。実際、攻撃コードとして渡されるSQLの文字列にシングルクォートなどの文字は一切含まれていません。
数値リテラル型のSQLインジェクションとは何?という方は徳丸氏の次のエントリを参考にして下さい。(または同氏著の「安全なWebアプリケーションの作り方」のP129,130を参考)
数値項目に対するSQLインジェクション対策のまとめ −徳丸浩の日記
 
SQLインジェクションであれば既知の攻撃手法でありWAFで防ぐことは出来るのではという考え方もありますが、例えばブラックリストタイプのWAFでこの数値リテラル型をつくSQLインジェクションを防ぐことが出来ません。HTTPリクエストとして受けた文字列だけで、最終的にデータベースに対して発行されるSQLでその文字列がどのような扱いになるか(数値リテラルになるのかどうか)判断することが出来ないためです。
そのため、予めWAF側にどのValue値が数字のみの許容とするのかを定義する必要があり、ホワイトリスト型の機能を持つWAF製品で、かつもれなく設定されている必要があり、完全に防御されているのかどうか確認するだけでもかなり時間を要するのではないかと思います。そもそもWAFに対してそこまできめ細かく設定をしているようなWebアプリケーションの開発担当者であれば、「SQLインジェクション」という非常に危険性の高い脆弱性は早急に解消しているのではないかとも思えます。(取り消し理由は下記追記を参照ください)
トレンドマイクロによると海外ほど大規模ではないにせよ、既に日本のサイトでもいくつかの改ざんが確認されているそうです。以前のGumblerのように、海外の動向から少し遅れる形で流行する(大規模な改ざんが行われる)可能性は残っており、今後も引き続き注意して見ていく必要があります。
 

(追記)…とドヤ顔で書いていたら。

日本のWAF界の重鎮であるお二方(@ockeghem,@ymzkei5)に「それ"完璧なWAF"w」とご指摘をいただきました。上記の記載は私の勉強不足でして、「ブラックリスト型のWAFはLizaMoon攻撃に対して有効」です。誤解が広まることが無い様に、徳丸氏に次のようなエントリまでご用意頂き、深く感謝いたします。
ライザムーン(LizaMoon)攻撃に対してもWAFは有効−ockeghem(徳丸浩)の日記