Mpack以外の事例

Webサイト経由の攻撃はMpackが初めてではない。

記憶に新しいところでは、ドルフィンスタジアムの公式WebサイトにJavaScriptコードが仕込まれた事例がある。この事例ではiframeタグではなく、scriptタグが挿入されていた。scriptタグで読み込まれたJavaScriptコードでは、Microsoft Data Access Components (MDAC)の脆弱性(前述)、Vector Markup Languageの脆弱性(CVE-2007-0024)を悪用する。ドルフィンスタジアムの事例、今回のMpackの事例により、公式Webサイトにも攻撃コードが挿入されることを示唆している。

では、Mpackが優れた管理機能を持つ、新しい攻撃ツールかというと、そんなことはない。Mpackの事例がある以前にも、Web Attacker Toolkitといった商用Web Exploitキットが販売されていた。Web Attacker ToolkitもMpack同様、Webサイトにiframe タグ(またはscriptタグ)を挿入し、ユーザがそのWebサイトを閲覧することで攻撃が成功する。ユーザのブラウザ、OS情報を特定し、攻撃コードを実行する点もMpackと同じである。

WebAttacker、Mpack共にロシアのWebサイトで売買が確認されている。

ロシアではこのような商用Web Exploitキットを売買する市場がすでに出来上がっていると推測される。

Webサイト経由の攻撃に対する防御方法

Webサイト経由の攻撃の特徴、そしてMpackの事例が新しいものではないことをお伝えした。最後にWebサイト経由の攻撃をどうすれば防御できるのか、この点について触れてみたい。

Webサイト経由の攻撃に対する防御方法として提案されるのは、「JavaScriptを無効にする」(最近ではJavaApplet、Flash といった他のWebコンテンツを無効にするという対策も耳にする)ということである。この対策は確かに有効ではある。ただし、最近のWebアプリケーションはJavaScriptを多用しているため、JavaScriptを無効にすることは現実的な対策とは言えない。

では既存のセキュリティ対策で効果がありそうなものを考えてみよう。

ウイルス対策ソフト △ Webスキャン機能を持つ、ウイルス対策ソフトであれば、既知のexploitコードは検知できそうだ
IDS/IPS × 難読化により、検出が困難である
URLフィルタリング △ ドルフィンスタジアムの事例、Mpackの事例から公式サイトにもexploitコードが仕込まれる可能性がある。そうなると、URL フィルタリングでも完全に防御することはできない

このように、既存の境界防御を基本としたセキュリティ対策では、大きな効果が期待できないこととなる。Webサイト経由の攻撃はクライアント側で対策せざるを得ないのが現状である。

ここでWebサイト経由の攻撃の「特徴 3」を再度考えてみると、Webサイト経由の攻撃ではブラウザ関連の脆弱性を悪用する。ブラウザそのものの脆弱性だけではなく、ActiveXコンポーネントの脆弱性を悪用するのがポイントではないだろうか。ActiveXコンポーネントをインストールするアプリケーションでは、プログラムの自動更新機能が実装されていないことが多い。こういったアプリケーションが攻撃成功のポイントになると考えられる。Webサイト経由の攻撃の防御としては、「すべてのアプリケーションを最新の状態にアップデートしておく」ことが最善の防御策と言える。