Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Security Response

W32.Stuxnet の亜種

Created: 12 Nov 2010 03:43:24 GMT • Translations available: English
Liam O Murchu's picture
0 0 Votes
Login to vote

以前のブログでお伝えしたように、W32.Stuxnet には複雑なネスト構造のファイルとコンポーネントが含まれています。シマンテックでは、流行が確認されている各種のサンプルが亜種なのか、それとも同じコンポーネントを組み込んでラッパーを変更しただけなのか、それを判定することが有意義であると考えました。W32.Stuxnet に亜種が存在するかどうかを確認するために、各サンプルを解析し、それを構成しているペイロードを調べました。その解析の結果を以下に示します。

調査したサンプルから(今のところ、対象はサンプル全体の一部だけです)、インストーラコンポーネントには以下の表のとおり 4 種類のファイルサイズがあることが確認されました。ご覧のように、4 種類のインストーラがあると言っても、最初の 3 つはジャンクまたはヌルが追加されているだけで実質的には同じです。ただ、4 つ目は他の 3 種類と大きく異なっています。

<タイプ 1 ~3 は同一で、タイプ 4 のみが異なる>

このことは、インストーラからペイロードの .dll ファイルを抽出して比較してみれば検証できます。以下の表でわかるように、タイプ 1 から 3 に含まれるペイロード .dll ファイルはサイズが同じであり、事実上同一のものです。タイプ 4 は他のペイロードより 100KB ほど大きくなっています。

<タイプ 4 のインストーラに含まれるペイロードのみ異なる>

タイプ 1 と 4 に含まれるペイロード .dll ファイルはかなり異なりますが、どちらにも 1 つのリソースセクションがあります。このリソースの差異を解析すれば、2 つのタイプにおける変化を特定するうえで有効なはずです。ペイロードのコンパイル時間における日付からは、タイプ 4 の方が古いサンプルであり、タイプ 1 の方が新しいと推測されます。コンパイル時間は確実な判断基準ではありませんが、これを裏付ける他の情報についても以下に説明します。一般的に、脅威は時間が経つほど大きくなるので、新しい方のサンプルでリソース数が増える(以下の表では、タイプ 4 のリソース数 11 個に対してタイプ 1 のリソース数は 14 個)のは当然なのですが、新しいサンプルのサイズが古いサンプルより小さくなるというのは普通ではありません。

<タイプ 1 が最新のバージョン>

つまり、新しい方のサンプルはリソースが増えているにもかかわらずサイズが小さくなっているのです。そこで、リソースをさらに詳しく調べて、この理由を探ってみることにします。以下の表では、2 つのタイプのリソースを並べて比較しています。最新バージョンでは緑色で示したバージョンが追加され、古いバージョンにあった赤のリソースが削除されました。それ以外のリソースは、両サンプル間で変わっていません。

サイズが変わった理由は、新しいバージョンでリソース ID 207 がなくなっていることです。リソース 207 はサイズが 520 KB ありますが、新しいバージョンの W32.Stuxnet で多くのリソースが追加されているにもかかわらず、新しいリソースの合計は 520 KB より少なくなっています。

機能上どのような変更があったかは、各リソースの使用目的を調べて最新バージョンでそのうちどれが不要になったのか確認し、新しいリソースを調べてどんな機能が追加されたのかを把握すればわかります。

<赤の欄 = 削除されたリソース、緑色の欄 = 追加されたリソース>

この結果からわかるとおり、コンポーネントの多くは事実上まったく同一あるいはほぼ同一であり、コードがわずかに異なるだけで同じ機能を持っています。たとえば、タイプ 1 のリソースに含まれる文字列は暗号化されていますが、コンポーネントの機能は変わっていません。このことは、タイプ 1 のサンプルの方が新しいという確実な根拠になります。脅威は、後になるほど保護機能が強化されるのが一般的だからです。

リソース 201 の変更点も注目に値します。タイプ 4 のサンプルには署名がなく、タイプ 1 は署名されるようになったという違いしかありません。これも、タイプ 1 の方が新しいという確実な証拠です。

リソース 207 と 231 は、新しいバージョンの W32.Stuxnet で削除されています。リソース 231 はコントロールサーバーとの通信に使われていたもので、コマンド & コントロールサーバーの名前が平文でファイル内に格納されていました。新しいバージョンの Stuxnet では、インターネット接続の機能をメインのペイロード .dll 内に移し、URL もリソース 231 内からインストーラコンポーネントに移動したうえで、URL を暗号化(XOR FF を暗号化と考える場合)しています。攻撃者にとってこれは、新しいリソースを追加してパッケージ全体を再ビルドすることなく各サンプルの設定を更新できるという大きなメリットになります。

リソース 207 も削除されましたが、少なくともその機能の一部は維持されています。リソース 250 に、従来リソース 207 にあったコードが含まれています。ただし、サイズを見ればわかるように、リソース 250 の方がはるかに小さくなっており、リソース 207 の機能の一部が削除されています。

では、何が追加されたのでしょうか。リソース 240、241、242 は実質的にすべて同じ機能に関係するもので、これが 2 タイプのサンプルの大きな違いになっている可能性があります。

リソース 240 は、「Microsoft Windows Shortcut 'LNK' Files Automatic File Execution Vulnerability(Microsoft Windows のショートカット 'LNK' ファイルに存在するファイル自動実行の脆弱性)(BID 41732)」を悪用するリンクファイルの生成に使われる、リンクファイルテンプレートです。リソース 241 は、同じ悪用の第 2 段階として Stuxnet インストーラのロードと実行に使われ、「~WTR*.tmp」という名前のファイルを隠蔽するユーザーモードのルートキットコードも含まれています。リソース 242 は、~WTR ファイルを隠蔽するときに使われるカーネルモードのルートキットコンポーネントです。このように、3 つのリソースはすべて新しいコンポーネントであり、いずれも前述した .lnk ファイルの悪用に関係しています。

タイプ 4 のサンプルの解析では、~WTR ファイルを作成または隠蔽するコード、あるいは悪質な .lnk ファイルを作成するコードは確認されませんでした。古いサンプルの解析は現在も継続中ですが、これが新旧サンプル間の大きな相違であると考えられます。Stuxnet が利用する拡散方法は種類によって異なりますが、SCADA 関連の設計プランを盗み出し、SCADA 関連の特定の機能をフックして悪質なタスクを実行するという機能は変わっていません。タイプ 1 とタイプ 4 のサンプルでも、これが最大の目的です。どちらもほぼ同じように動作しますが、新しいタイプでは .lnk の脆弱性をついて脅威を拡散できるリソースが追加されているという点だけが異なります。実際には、.lnk の脆弱性を利用するサンプルが、「W32.Stuxnet」と命名された最初のサンプルです。タイプ 4 のサンプルは「W32.Stuxnet」と最初に命名したサンプルよりも前のものですが、シマンテックではどちらのタイプも W32.Stuxnet のサンプルとして識別しています。この脅威に利用される悪質な .lnk ファイルの識別には、W32.Stuxnet!lnk という名前が使われます。

各種のサンプルの解析から、この脅威がいつ頃から開発されてきたか、また悪用されてきたかが、現在までに少しずつ解明されてきました。開発は少なくとも 2009 年の 6 月までさかのぼり、それ以来、開発者たちが新しいコンポーネントや暗号化、悪用の機能を追加して開発を続けています。利用されているコンポーネントとコードは膨大な量にのぼります。しかも、パッチ修正前の脆弱性を利用してリムーバブルドライブ経由で拡散できるように脅威を進化させている能力を考えると、この脅威の開発者たちはかなり多くのリソースを使うことができ、これほどの大仕事に必要な時間もとれることがわかります。「10 代のハッカーが自室にこもってコーディング」している類の行為ではありません。

 

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。