GumblarからDarkleech Apache Moduleまで、巧妙化の足跡：こうしてWebは改ざんされた（2）（2/3 ページ）

» 2013年08月07日 18時00分公開

[林憲明（トレンドマイクロ），＠IT]

Webサーバに悪意ある設定ファイルをロードさせる攻撃

　Gumblar攻撃から1年後の2010年、ある改ざん被害者から、Webサーバで公開していたコンテンツファイルの提供を受けました。これらを確認して筆者は驚きました。

　「汚染されていない……」

　これまで見てきた不審なリダイレクト方法は、「悪意あるIFRAME」や「悪意あるJavaScript」を注入するといった手口でした。このためコンテンツを確認して注入個所さえ特定できれば、犯罪者によって仕掛けられた攻撃の連鎖をたどることができ、最終目的を把握できました。

　こうした注入が見られないということは、犯罪者が正規のWebサイトをリダイレクタ化する方法を変えてきたことを意味していました。

　彼らが取った方法とは、Webサーバ「Apache」の設定ファイル「.htaccess」を書き換えるものでした。本来この設定ファイルは、Apacheの動作をディレクトリ単位で制御するために用意するものです。初期設定では存在せず、利用者が自ら用意する必要があります。

　犯罪者は、この設定ファイルでRewriteRule、ErrorDocumentルールを指定し、悪用することでリダイレクタ化を実現しました。実際に設置された設定ファイルの抜粋を見ながら、その影響を考察してみたいと思います。

# HostRule
RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteRule ^(.*)$ http://（中略）/ [R=301,L]
ErrorDocument 401 http://（中略）/
ErrorDocument 403 http://（中略）/
ErrorDocument 404 http://（中略）/
ErrorDocument 500 http://（中略）/
# /HostRule

リスト　犯罪者によって改ざんされたWebサーバ「Apache」の設定ファイル「.htaccess」

　犯罪者が行ったのは、サイトの訪問者がインターネット検索エンジン（抜粋では、Googleのみ）からアクセスしてきた場合、RewriteRuleで指定したサイト（すなわち、悪意あるサイト）へリダイレクトされるように指定する細工でした。

　ほとんどのサイトでは、インターネット検索エンジン経由で訪れる閲覧者が多くの割合を占めています。従って、この設定は犯罪者にとって好都合であったといえます。

2013年に確認された設定ファイル「.htaccess」の改ざん事例では、「RewriteCond %{HTTP_REFERER}」の指定内容が拡張されていることを確認しています。これにより、インターネット検索エンジンを経由した場合のみならず、主要なポータルサイトから訪れた場合にも、悪意あるサイトへリダイレクトされます。

　さらに、404、403などのエラーを表示する代わりに、ErrorDocumentで指定したサイト（いうまでもなく、悪意あるサイト）へリダイレクトするように指定されています。犯罪者はWebサーバに悪意ある設定ファイルを読み込ませることでトラフィックの横取りに成功したといえます。

　しかも、この攻撃手法はコンテンツファイルの監視という予防策を無効化するものでした。加えて、攻撃者に思わぬ副産物まで与えています。

　Webサイトの管理者が、「サイトを見ていたらセキュリティ対策ソフトが反応した」という報告を受けた場合、一般にはその再現性を確認するはずです。このとき管理者は、日頃から管理しているサイトですから、ほとんどはURLを直接入力したり、ブックマーク経由でアクセスすることでしょう。しかし、上記の悪意ある設定では、このような確認方法では、犯罪者が仕掛けたワナが発動することはありません。

　再現性の低さが原因特定を複雑にし、管理者が被害把握に至るまでの時間を長期化させたともいわれています。なお、これが犯罪者による狙い通りであったのかは、定かではありません。

国内外での被害が報告された「Darkleech Apache Module」

　コンテンツの書き換えを伴わずリダイレクタ化する方法は、上記で説明した、悪意ある設定ファイルをロードさせる方法だけではありません。

　コンテンツの書き換えを伴わない改ざんでは、2013年3月中旬以降、複数のWebサイトで、Apacheに不正なモジュール「Darkleech Apache Module」（検出名「ELF_CHAPRO」ファミリ」、以下 Darkleechモジュール）が設置される事例が報告されました。

【関連記事】

おさまらぬWeb改ざん被害、Apacheモジュールの確認を

http://www.atmarkit.co.jp/ait/articles/1303/25/news122.html

　その当時の様子を思い出しながら、DarkleechモジュールがこれまでのDBD攻撃とどのように異なるのか紹介したいと思います。

　当時、当社に複数の顧客から「改ざんが疑われるため調査してほしい」との依頼を受けました。また、社内でリサーチャーが使用しているシステムからは、許容値を超える異常傾向を知らせる警告が上がってきました。

　当社では、最新の脅威を特定するクラウド型セキュリティ基盤を構築しています。それは「Trend Micro Smart Protection Network（SPN）」と呼ばれています。SPNは、世界中から1日当たり約10TBのデータを収集し、処理しています。我々リサーチャーはそこに寄せられている未評価の脅威情報の中から実害の可能性が高いものだけを抽出し、疑わしき異常傾向の発生をいち早く知らせるシステムを構築することで、日々の監視に役立てています。

　Darkleechモジュールに対する分析は、アラートシステムによる警告が発せられているという、ただならぬ状況の下で開始することとなりました。

図2　2013年3月の第3週だけでもDarkleechモジュールによるリダイレクタの転送をブロックした件数は国内だけで4万1983件に上った

見つからぬ改ざん個所、その理由は……

　多くの日本人管理者は「Gumblar」インシデントで培ったノウハウを持っています。そして、我々の監視システムからはリアルタイムに数々のブラックリストURLが報告されています。これさえあれば全容解明もあっという間……とは、いきませんでした。

　今回のインシデントでは、犯罪者は同時期に多数のリダイレクタを用意したものと思われます。このため、1つの踏み台を他のDBD攻撃で使い回すことは希でした。

　それ以前の攻撃では、リダイレクタの使い回し傾向が確認されています。この傾向を逆手にとることで、仮に正規のWebサイトが改ざんされた場合でも、続く攻撃の連鎖先はすでにブラックリストに登録済みで、実害が生じるまでの連鎖に至らなかった事例もありました。しかし、今回はそうした先回りのブロックが困難な状況になっていたのです。

　これまでのDBD攻撃で見られた、悪意あるIFRAME／JavaScriptの注入はありません。セキュリティ対策ソフトの検出を回避するために難読化を施しているのではないかと推測し、提供を受けたコンテンツファイルとバックアップファイルのDIFFを取っても（差分を比較しても）、変化なしの状態です。従って、改ざんされた内容を見落としていることはなさそうです。

　コンテンツファイルの調査結果だけでみると「変化なし」で、被害はすでに沈静化したかにも思えます。一方で、「今なおアクセスすると不審なサイトへ転送される」という報告と「すでに転送されなくなっている」という報告が入り乱れるようになってきました。