ファイア・アイは7月1日、Adobe Flash Playerの脆弱性「CVE-2015-3113」を悪用したフィッシング攻撃の詳細を公開した。

アドビは、すでにCVE-2015-3113用のパッチを公開し、Adobe Flash Playerのユーザーには、早急に最新版へアップデートするようにと呼び掛けている。

同社によると、CVE-2015-3113への脆弱性攻撃に関与しているのは、中国の脅威グループ「APT3(別名「UPS)」であることがわかっている。同社がAPT3を特に危険視する脅威グループとしており、日頃から動向を追っている。

近年のAPT3の動向は、大規模で組織的なフィッシング攻撃を展開しており、「航空宇宙・防衛」「建設・土木」「ハイテク」「通信」「運輸」といった業種を標的としている。

Adobe Flash Playerの脆弱性攻撃では、標的とされた組織がフィッシングメールに記載されているURLをクリックすると、JavaScriptのプロファイルスクリプトが仕込まれた感染サーバーへといったんリダイレクトされる。

その後、標的とするホストのプロファイリングが完了すると、悪意のあるSWFファイルとFlash Video(FLV)ファイルがダウンロードされ、専用のバックドアであるSHOTPUTが被害者のシステムに送り込まれる。ペイロードはXORエンコードを用いて難読化されており、有効なGIFファイルに付与される。

APT3が今回の攻撃で使用したフィッシングメールは巧妙に作られており、一見しただけでスパムメールと判断が付かないという。

フィッシングメールのサンプル

今回の攻撃で悪用されているのは、Adobe Flash PlayerがFLVファイルを解析する際のゼロデイ脆弱性。脆弱性を悪用した攻撃は、一般的なベクトル破壊手法を用いてアドレス空間配置のランダム化(ASLR)機能を迂回し、リターン指向プログラミング(ROP)を用いてデータ実行防止(DEP)機能を迂回するというもの。ROP手法の巧妙なトリックにより、脆弱性の攻撃は容易になっており、一定のROP検知手法も回避できるという。

シェルコードは、復号時に使用する鍵と一緒にパックされたAdobe Flash Playerのエクスプロイト内に保存されており、ペイロードはXORで暗号化され、画像内に隠されているという。

Adobe Flash Playerのエクスプロイトは、シンプルなRC4パッカーでパックされている。RC4の鍵と暗号データは、BinaryDataブロブに格納されており、パッカーがレイヤー2のAdobe Flash Playerファイルを復号するのに使用する。復号が完了すると「loader.loadBytes」によってレイヤー2が実行される。

レイヤー2は、Adobe Flash Playerのベクトル破壊手法を用い、ヒープ破壊の脆弱性を利用し、ActionScript3のメモリ空間を読み書きする。この手法は、攻撃者がAdobe Flash Playerのベクトルにヒープ・スプレー攻撃を行い、ActionScript3に書き込み可能な脆弱性を利用することで、ベクトルの1つについてサイズの変更を行う。次に、破壊したベクトル・オブジェクトに対して当初割り当てられていたメモリの境界外に、ActionScript3経由でその後の読み書きを行う。

攻撃者は、メモリへの制限付き読み書きアクセスを得ると、第2ベクトルを破壊しアクセスする範囲を「0x3fffffff」バイトへ拡張させる。この第2ベクトルは、その後のエクスプロイトで使用されている。

攻撃者はROPチェーンを用いてkernel32!VirtualAllocを呼び出し、自らのシェルコードを実行可能にした後、シェルコードにジャンプする。その際、シェルコードやペイロードと一緒にROPチェーンをヒープに書き込むのではなく、別の手法が用いられているという。

エクスプロイトの開発者は、これまでSoundオブジェクトなどAdobe Flash Playerの組み込みオブジェクトを破壊させるのが一般的であったが、最近ではByteArrayオブジェクトを用いControl Flow Guard (CFG) をバイパスすることもあるという。しかし、今回の攻撃者は、以下のように多数の引数を持つ関数を使用し、ActionScript3内で自らのクラスを定義する方法を選んでいる。

スタック・ポインタを加算し、ROPへとリターンするガジェットにより、攻撃者は関数ポインタを簡単に上書きできるようになる。その際、ROPチェーンの絶対アドレスを特定し、一般的なxchg reg32, espピボット用にレジスタに保存する必要はないという。さらに、スタック上にROPチェーンを保存することで、スタック・ポインタがスレッドのスタック領域外を指定する際の検知に関するROPの検知メカニズムを回避できる。

VirtualAlloc呼び出し後のROPチェーンにはROPsledが含まれている。同社は、開発時の中間生産物の可能性もあれば、VirtualAllocの呼び出しときに、限られた深さでリターンアドレスの有効性を検証する検知メカニズムを迂回するために作られた可能性もあると指摘している。