 |
 |
記事検索 |
バックナンバー |
 |
||
|
||
【 2008/10/08 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/24 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/17 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/03 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/08/27 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/30 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/23 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/16 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/09 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/02 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/06/25 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/06/18 】 |
||
|
||
|
||
|
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
| あなたの身近なセキュリティ | ||||||||||||||||||||||||||||
|
第4回：WWW編（3） |
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
JavaScriptが危険な理由
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
● Ajaxは当然JavaScript必須。なぜ切る必要があるのか？
前回では、ブラウザの脆弱性とJavaScriptを用いることによって、Webを閲覧しただけで不正なプログラムを実行される恐れがあることを説明した。ここでは、「通常のサイトにどのようにして不正コードを埋め込んでいるか」を見てみよう。 この手の不正処理は、本来のサーバー上では行なわれず、他のサイトに迂回しているのが一般的だ。これは攻撃側にとって、攻撃手段の変更などのメンテナンスが容易であること、さらに解析・対応を難しくすることができるためだ。 攻撃手法としてはまず、正規のサイトに「他のサイト1」のJavaScriptを埋め込む。ここではさらにWindow.location文を使って「他のサイト2」を呼び出す。ところが、このURLは「他のサイト3」へ転送しており、その中身はIFRAMEでさらに「他のサイト4」を呼び出している。他のサイト4へのアクセスは、サーバーがCookieを読み込ませた上で「他のサイト5」へジャンプさせており、他のサイト5では暗号化JavaScriptを読み込ませる。この暗号化されたJavaScriptが、同じサーバーのEXEファイルを呼び出している。 本来ならばEXEファイルを呼び出すのは1回で済むはずなのが、サーバーも手法も異なる手段で延々と引きずり回しているというのがわかるだろうか？ この一連の攻撃を手動で解析する作業を考えてみよう。まず、元となるHTMLソースコードだけを取得し、これを人手で読む。その中には本来のコードも含まれているが、処理を簡単にするためには本来のサーバー内のデータは除外してもよいかもしれない。すると、他のサーバーから取得するJavaScriptを見つけるので、怪しいと解析を進めると、あちこちのサイトをフラフラと移動した挙句に難読化処理の行なわれたHTML（中身はJavaScript）を取得するので、これを手動で暗号化解除し、さらに読むという作業が必要になる。 現在、（子供を）誘拐して身代金を取るという犯罪は、あまり行なわれてように思えるが、ドラマでは身代金を持った捜査員を公衆電話に呼び出し、次々と場所を移動させて捜査を混乱させるというシチュエーションをよく見る。これと同様に、目的のプログラムに到達するまで、アチコチのサーバーを飛ばせることによって解析を難しくしている、というのがここから読み取れる。
前回では、ホワイトリスト形式でJavaScriptを許可する方法を紹介したが、このような攻撃に対しては特に有用といえる。というのも、1つのWebページでは、あまりにも多くのサーバーからスクリプトを取得することは少ないからだ。 難読化を行なうのは解析を難しくするためだけではない。実は暗号化のキーを変えることによって、同じソースでも暗号化済コードは無限といってよいほど作成できる。コンピュータウイルスでも難読化を施すことによってアンチウイルスソフトを潜り抜ける亜種を作り出せることが知られているが、HTMLでもこのようにして亜種を作り出せる。また、従来（2007年版）のアンチウイルスソフトのシグネチャ解析の仕組みでは、このような暗号化HTMLの対応は事実上行なえなかった。 なお、難読化といってもレベルがあり、JavaScriptの変数を使って読めなくしている例は通常のサイトでも使われている。また、無効なタグを入れることによってシグネチャ解析を逃れる亜種を作っている例もある（これはスパムメールでよく使われている）。また、マイクロソフトのセキュリティレスポンスチームの小野寺匠氏に尋ねてみたところ、暗号化JavaScriptは、通常でも使われている例があるという。「暗号化≒怪しい」というイメージはあるが、すべてが悪いというわけではない。 ● 手法は次々に開発されるので油断禁物
それでは、この手の攻撃にユーザーは無力なのだろうか？ 連載当初の話を思い出して欲しい。もしも、プラグインを含むブラウザの脆弱性情報を知っていて、問題があれば対策が施された新バージョンをインストールしたり、Webプラグインの無効化やアンインストールを行なっていれば、攻撃をまぬがれることができる。その上で、統合版のセキュリティソフトを使っていれば「不幸な被害者」になる可能性はさらに減るだろう。 この状況で攻撃が成功するとすれば、「まったく確認されていない未知の脆弱性を使い、さらにセキュリティソフト側も対処していない（もしくはアップデートをしていない）」場合だ。 現在の統合セキュリティソフトは「多層防御」に重点を置いているが、そこにソフトウェア上のセキュリティホールをなくす配慮が加われば防御の厚みは格段に増す。さらに、このような攻撃事例があるという知識が加わればよりよいだろう。JavaScriptを常時無効にするのは現実的ではないのだが、前回紹介したWebブラウザ「Firefox」のプラグイン「NoScript」のようなツールを使えば設定はかなり容易になる上、「このサイトはJavaScriptを使っていなかったのに急に『他のサイトのJavaScriptを使用している』警告が出た。何かオカシイ」といったような新たな発見があると思う。 「100％安全な環境」を保証するのは難しいとしても、少なくとも家庭で「相当に安全な環境」を作るのは、それなりの配慮があれば可能だ。セキュリティベンダーも単なる製品販売だけでなく啓蒙活動を行なっている。次回はややWebとは異なると思われそうだが、スパイウェアとアドウェアに関する話題をお届けする予定だ。 ● 先週の気になったセキュリティ関連ニュース（2/11～2/17） ◆Adobe Readerの脆弱性、バナー広告で悪用http://isc.sans.org/diary.html?storyid=3958 「Webからの脅威の変形」が、このバナー広告からの攻撃だ。「広告経由の攻撃」に関しては別途本文で取り上げる予定になっている。 ◆MSが取り下げたパッチは悪用コードが出ているExcelの脆弱性？ http://www.eweek.com/c/a/Security/Excel-ZeroDay-Still-Unpatched/ 2月の月例セキュリティ更新プログラム（パッチ）では「緊急7件」と予告されていたが、土壇場で6件に減らされている。未提供となったパッチは、すでに脆弱性が明らかになっているExcel用パッチではないか？ という記事。 ◆トレンドマイクロがまた「CPU使用率100％の状態が続く」現象を配布パターンで起こす http://internet.watch.impress.co.jp/cda/news/2008/02/13/18438.html http://internet.watch.impress.co.jp/cda/news/2008/02/14/18459.html http://internet.watch.impress.co.jp/cda/news/2008/02/15/18475.html 平日の早朝のパターン配布だったので被害数が少なかったようだが、2005年にパターンファイル障害が発生した時点で、2度とこのような事態を起こさないような体制が作られていたはず。検証体制の不備にどのように対策するのか、アナウンスに注目したい。 ◆マルウェアはグローバルから、エリア、ターゲットに移行 http://internet.watch.impress.co.jp/cda/news/2008/02/12/18424.html この辺はセキュリティベンダーでほぼ共通した認識のようで、シグネチャベースの対策ツールでは対処しにくいことを意味する。今のところ各社とも「振る舞い検知」で対処するようだ。 ◆「Windows Live Hotmail」装う偽サイト、IE7フィッシング対策も検知不能 http://internet.watch.impress.co.jp/cda/news/2008/02/12/18425.html この記事に紹介されている偽サイトに対して、ソフト「A」は警告したが、ソフト「B」はスルーしてしまった。アンチフィッシングソフトに頼り切るのは微妙なところだ。 ◆「Kaspersky 7.0」アップデータが公開停止、適用後に不具合発生で http://internet.watch.impress.co.jp/cda/news/2008/02/15/18478.html アップデータのアンインストール方法が事実上なく、いったんKaspersky自体をアンインストールする必要がある。検証作業が不十分だったのではないだろうか？ セキュリティアップデートと機能強化は別々に対応してほしい。 ◆警視庁、迷惑メール送信の男性を逮捕 http://internet.watch.impress.co.jp/cda/news/2008/02/15/18470.html 成功報酬制でも十分な収入がある限りスパムメールはなくならない。広告業界では広告主が責任を負う原則があるが、メール送信に関わるところで歯止めがかける必要があるのではないかと感じる。 2008/02/20 12:36
- ページの先頭へ-
|
