標的型攻撃に用いられたマルチCOMロード法

はじめに

先月、iSightPartnersはロシアのサイバー・スパイ・チームによる標的型攻撃で使用されたMicrosoft Officeのゼロデイのことを明らかにしました。この脆弱性は、Microsoftのセキュリティ情報MS15-070で修正されています。この脆弱性にはCVE-2015-2424という番号が割り当てられました。今回のブログ記事では、このWordの脆弱性の実態について解説をし、これを理解し、検出する上で他の研究者たちに役に立つような情報を提供したいと思います。

複数のディレクトリ・エントリをつなぐ

私たちはまず、OfficeMalScannerのRTFScanを使ってエクスプロイトが仕込まれた文書(sha1: e7f7f6caaede6cc29c2e7e4888019f2d1be37cef)に埋め込まれたオブジェクトを抽出しました。表1は、これによって得られた埋め込みOLEオブジェクトの一覧です。このエクスプロイトは特定のワークステーションで実行されるよう設計されたもののようです。おそらく、OLEオブジェクトの1つに明記されているハードコードされたアドレス0x7c809ae1を持つ、DEP/ASLR保護が有効になっていないマシンを標的としたものだと思われます。ですが私たちのテスト環境では、今回の攻撃で使用されたこのRTF文書を確実に活用することができません。

抽出されたOLEファイル名 目的
OLE_DOCUMENT__9e5fbd__1.bin ペイロードをトリガーするのに使われるシェルコードを内包
OLE_DOCUMENT__9e5fbd__2.bin エクスプロイトが使用する、意図したものではないControl.TaskSymbol.1を内包
OLE_DOCUMENT__9e5fbd__3.bin エクスプロイトの実行過程で使われている可能性があるForms.Image.1を内包
OLE_DOCUMENT__9e5fbd__4.bin 中途打切データを持つMsxml2.SAXXMLReader.5.0を内包。その目的はまだ明確になっていない。

表1. エクスプロイトが仕込まれたRTF文書にある埋め込みOLEオブジェクト

ここでは、2つ目の埋め込みOLE文書を見ていきましょう。OLE文書は構造化ストレージ複合ファイルあるいは複合ファイル・バイナリ形式とも言われています。簡単に言うとこの文書は、複合ファイルのデータ・ストリームが、データ・ストリームのサイズに応じてFATセクタあるいはMini Fatセクタに格納されるよう、FATファイル・システムに似たファイル階層構造を使用します。一般的に、ディレクトリ・セクタは常に、チェーン内の次のセクタのセクタ番号を格納するのに使われるFATセクタ・アロケータの後のセクタに位置しています。このサンプルの場合、FATセクタ・アロケータはセクタ#0にあります。ディレクトリ・セクタは、セクタ#1に位置しています。これも複合ファイルのヘッダで定義されています。図1は、OffVisで見ることができる複合ファイルのヘッダとFATセクタ・アロケータです。


図1: 復号ファイル・ヘッダへのオフセットとセクタ#0にあるFATセクタ・アロケータ

基本的に、ディレクトリ・セクタには一連のディレクトリ・エントリという構造体が含まれています。これは複合ファイルのストリーム・オブジェクトとストレージ・オブジェクトに関する情報を内包するのに使われています。このサンプルには、2つのセクタに2つのディレクトリ・エントリが含まれており、一連のディレクトリ・エントリをトラバースする際にいくつかのOLEパーサーを混乱させます。例えば、図1に見られるように、このサンプルはセクタ#5で1つ目のディレクトリ・エントリと2つ目のディレクトリ・エントリをつなげようとしていますが、これがOffVisを混乱させています。


図2. ディレクトリ・エントリをつなげることで、OffVisを混乱させている

RTFで予想外のActiveXをロード

図2を見ると、ストレージ・オブジェクトが1つ、ストリーム・オブジェクトが3つあることがわかります。そのオブジェクトのいくつかは、正規のDOCファイルによく見られるものです。ですが、OffVisを使っても他のストリーム・オブジェクトは判断がつきません。ディレクトリ・エントリがつながっているからです。上のセクションで言及したように、2つ目のディレクトリ・エントリは、他のストリーム・オブジェクトも入っているセクタ#5にあるからです。表2に、複合ファイルに格納されているストレージ・オブジェクトとストリーム・オブジェクトをまとめました。これらのオブジェクトの概要は、Wordバイナリ・ファイル形式の仕様書にあります。

オブジェクトタイプ オブジェクト名 概要
Rootストレージ・オブジェクト Root Entry 他のストレージ・オブジェクトおよびストリーム・オブジェクトの親ノード
ストリーム・オブジェクト PRINT MFPF構造体を内包。そのすぐ後にはメタファイル・データがくる
ストリーム・オブジェクト CompObj 複合ファイルのProgIDの概要を内包
ストリーム・オブジェクト ObjInfo 埋め込みOLEオブジェクトに関する情報を明記するODT構造体を内包
ストリーム・オブジェクト OCXDATA OLEコントロールのデータを内包

表2. 複合ファイルで定義されているストリーム・オブジェクト

OffVis下で見てみたいオブジェクトをよりわかりやすく示せるよう、無関係のストリーム・オブジェクトをいくつか除外して、ディレクトリ・エントリを再構成してみました。ストリーム・オブジェクトPRINTと2つ目のディレクトリ・エントリを取り除き、他のストリーム・オブジェクトは残しました。結果として、1つのディレクトリ・セクタ(512バイト)で十分、すべてのオブジェクトの情報を保持できるでしょう。元の複合ファイルと修正を行った複合ファイルの違いに関しては、図5をご覧ください。再びOffVisを使って、結果として得られた複合ファイルを見てみると、TaskSymbol コントロールのCLSID{44f9a03b-a3ec-4f3b-9364-08e0007f21df} で構成されているストリームOCXDATAを突き止めることができました。ストリームObjInfoはODT構造体で表すことができますが、ODT構造体の1つ目のフィールドは16ビット値、0xB200になっています。これはOLEに関する情報を示しています。この値はODTPersist1構造体で表すことができます。このODTPersist1データは、この複合ファイルがOLEコントロールであり、そのデータがOCXDATAで参照されていることを明記しています。要するに、ストリーム・オブジェクトObjInfoとOCXDATAは、いかなるActiveXコントロールのロードも可能にするものであるため、この脆弱性を誘発するのに重要な役割を果たしているということになります。無関係なデータはすべて取り除いたので、今度は結果として得られた複合ファイルのバイナリを16進数の文字列へと変換し、下に示すシンプルなPythonスクリプトを使ってRTFファイルに入れ込まなければなりません。後ほど、WINWORDバージョン12.0.6720.5000で最終的なRTFファイルを開きます。

>>> data = open('handcraft-poc.doc', 'rb').read()
>>> i = 0
>>> while (1):
... try:
... _causedexcept = data.encode('hex')[i]
... print data.encode('hex')[i:i+200]
... i += 200
... except:
... break


図3.ストリームOCXDATAはControl.TaskSymbol.1 CLSIDを内包


図4.関連のあるストリーム・オブジェクの入った修正済みRTF、それらが脆弱性を誘発する


図5. 元のOLE文書と修正を加えたOLE文書を比較

Ole32!CoCreateInstance APIにブレークポイント設定して、WinDBGをWINWORDにアタッチし、Control.TaskSymbol.1の初期化を実際に行ってみます。図6に示すように、結果として得られたRTFファイルをロードする際、私たちが設定したブレークポイントは予期した通りのTaskSymbol CLSIDでヒットします。Ole32!CoCreateInstanceにヒットする前に、いくつかロードされたDLLがあります。気づいていない方のために言っておきますが、%SYSTEM32%mmcndmgr.dllはControl.TaskSymbol.1と関連付けられています。そのため、TaskSymbolの初期化の前にこれもロードされます。これはつまり、特別に細工されたRTFファイルを使えば、付随するDLLと関連付けられた、自分が狙うCOMをロードすることができることを意味しています。このテクニックは新しいものではありませんが、エクスプロイト作成者がASLR緩和技術を回避するためによく用いていたものです。そのいくつか(MSCOMCTL.OCXやOTKLOADR.DLLなど)はMicrosoftによって修正されています。ですが、このケースに関しては、これがアタッカーによってリモート・コード実行エクスプロイトを誘発するのに使われました。こうしたタイプの攻撃ベクトルは、 McAfee Labs のHaifei Li 氏がBlackHat USA 2015で取り上げています。


図6. TaskSymbol COMの初期化

その他のActiveXコントロール

その他のActiveXオブジェクトを見ていると、もう1つ、同じ脆弱性を誘発する可能性のある興味深いコンポーネントがあることに気づきました。図7で示すように、私たちが見つけた、ProgIDがMMC.IconControl.1となっているこのActiveXオブジェクトには、同じmmcndmgr.dllが関連付けられています。私たちの行った実験の結果から、パッチが適用されていないOffice 2010やそれ以降のバージョンでMMC.IconControl.1をロードした際、同じ脆弱性が誘発されたのはほぼ間違いないでしょう。なぜ同じ脆弱性がOffice 2007に影響を及ぼさないのかという理由については検証しませんでしたが、とにかく、Officeに対して発行された最新の(このブログを書いている時点で)Microsoftセキュリティ情報MS15-081を私たちが検証している間に、この問題はMicrosoftによって修正されました。


図7. %SYSTEM32%mmcndmgr.dllと結び付けられているMMC IconControlクラス

同じ脆弱性、異なるCVE

この脆弱性の根本的な問題を理解しようとするなか、私たちはCVE-2015-2424とCVE-2015-1612に、そっくりな不完全コードパスを発見しました。どちらもDOCファイルを使ってTaskSymbolコントロールのロードを試みます。さらに調査を進めると、CVE-2015-1612はOpen XML形式を使ってActiveXコントロールのロードを試みることが判明しました。そのため、この2つには異なるCVE番号が割り当てられているのでしょう。

Microsoft Officeユーザーの皆さんは、これらの脆弱性を操るアタッカーの犠牲にならないよう、Officeを最新バージョンにアップデートするようにしてください。

いつものことですが、これらの脅威からフォーティネットのお客様を保護するため、当社ではすでにAVシグネチャ(MSWord/CVE_2015_2424!exploitとMSWord/CVE_2015_1642!exploit)およびIPSシグネチャ(MS.Office.RTF.Control.TaskSymbol.Remote.Code.Execution)がリリースしています。

貴重な情報を提供してくれたPeixue Liと、IPSシグネチャを提供してくれたTien Phanに感謝です。