検索
連載

クライアントが狙われる――受動的攻撃を見抜くインシデントの見抜きかた(2)(2/3 ページ)

第1回ではクロスサイトスクリプティングやSQLインジェクションなど、Webサーバへの攻撃を見抜く方法を解説しました。しかし狙われているのはサーバだけではありません。今回はクライアントを攻撃対象とする「受動的攻撃」を見抜くためのスキルを解説します(編集部)

Share
Tweet
LINE
Hatena

アニメーションカーソル脆弱性を利用した攻撃パターンの例

 今回もIDSのアラート例を基に解説するが、受動的攻撃のアラートは誤検知の率が高い。最近のものから選別して紹介する。

【参考記事】

Windowsに深刻な脆弱性、ゼロデイ攻撃も発生

http://www.atmarkit.co.jp/news/200703/30/ms.html


 以下は、「MS05-002:カーソルおよびアイコンのフォーマットの処理の脆弱性により、リモートでコードが実行される(現:MS07-017)」の脆弱性を狙った不正なデータである。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***


 まず末尾のURLが「.exe」を指定していることがすでに怪しい。さらに「cmd」「h32」「user」の文字が確認できる。これらの要素を組み合わせるとWindowsの脆弱性を狙っているのではないかと推測できる。あとは、このデータがアニメーションカーソルのデータであるということを「anih」の文字から読み取れればMS05-002の脆弱性にたどり着ける。

 もう1つ同様の脆弱性を狙った不正なデータを紹介する。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***


 前例よりさらに可読範囲が少なくなっている。なんとなく怪しいように見えるが、確証は得られないだろう。なお、上記例での文字はすべてASCIIコードで表示されている、印字不可の文字は“.”(ドット)で表現されている。

 ここでは「jvvr<11」の文字に注目する。ASCIIコード表を見ながら、各文字の2バイト前に割り当てられている文字に変換してほしい。すると以下のようになる。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***


 では、該当の文字以降を変換してみる。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***


 ここまでくれば、前例と同じように攻撃と判断できるだろう。両者のペイロードはかなり異なるが、同じような方法を利用しているのである。

 とはいえ、上記の文字に注目するには経験と知識が必要になる。ほかに注目できる点があるとすれば、「anih」が2回指定されていることが挙げられる。また、通常のアニメーションカーソルにあるrateやseqといったヘッダが指定されていないのもポイントだ【注】

【注】

初見でこのデータがアニメーションカーソルファイル(.ani)であることは、マジックナンバーから判断できる。マジックナンバーとはバイナリデータ(ファイル)を特定するための識別子で、データの先頭に表記されることが多い(例えばGIFデータなら“GIF89a”など)。


この例では、データの先頭が「RIFF」から始まっている。RIFF(Resource Interchange File Format)は、音声や画像の共通フォーマットで、その後に続く「ACON」や「anih」というキーワードから、このデータがアニメーションカーソルファイルであることが特定できる。


 通常のアニメーションカーソルデータと異なっているという事象からMS05-002の脆弱性との関連性を見つけるのは難しいが、アニメーションカーソルはWindowsで使用されるものであることを知っていれば導き出せるかもしれない。

 管理者として最善の状態は、アニメーションカーソルのデータ形式を知っていて、かつ本脆弱性がどのようなものであるかを知っていることである。いずれにせよ、インシデントハンドリングでは怪しいと思った時点で次の行動に移る方がよい。

JavaScriptを利用した攻撃パターンの例

 次は、JavaScriptを利用したものである。最近よく見られる攻撃パターンの1つである。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***


 上記のJavaScriptから攻撃かどうかの判断はすぐにはできないと思うが、普段JavaScriptのコードを見慣れている人なら怪しいと思うだろう。

 「unescape」関数に渡されている文字はURLエンコードされたものであるが、このように人が目で見てすぐに判断できないような対処がされていると、「何かを隠そうとしているのではないか?」と疑うべきである。

 実際にこれらの文字をデコードすると、不正なファイルを強制的にダウンロード、インストールするJavaScriptのコードが現れる。

 なお、インシデントハンドリングにおいては、この時点での「何がインストールされたのか?」の調査は推奨されない。重要なのは「攻撃が成功したか?」であり、「クライアントホストのWebブラウザはJavaScriptを実行するように設定されていたか?」の調査である。

ヘルプファイルの脆弱性を利用した攻撃パターンの例

 次は、ヘルプファイルの脆弱性を狙ったものを紹介する。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***


 まず、正常なヘルプファイルと見比べてみよう。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***


 両者の違いは明らかである。前者は可読できる部分が極端に少ない。後者の可読できる部分はファイルの構造で、chm形式のヘルプファイルに見られる一般的なデータ配列である。

 ここで、前者の内容を見てみると、ヘルプファイルの一般的な形と合わないうえに何かしらの.exeファイルが記述されている。攻撃として調査を進めるには十分な怪しさである。上記例には記載していないが、実際のデータ配列を見ると複数の非印字文字が連続しているなど、バッファオーバーフローの特徴が見られる。

 このように、Webクライアントを狙う不正なファイルはさまざまな形式で存在するのが現状である。

Index

クライアントが狙われる――受動的攻撃を見抜く

Page1

受動的攻撃――影響を受けるのはクライアント

仕掛けへ誘導する巧みな手法

受動的攻撃は大きな脅威になりつつある

「ファイアウォールがあれば安心」は通用しない

受動的攻撃の分析、判断のポイント


Page2

アニメーションカーソル脆弱性を利用した攻撃パターンの例

JavaScriptを利用した攻撃パターンの例

ヘルプファイルの脆弱性を利用した攻撃パターンの例


Page3

何が起きたのかよりも「起きてしまったのか?」を判断する

では、どう対策するか?


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る