ヒープスプレー ひーぷすぷれー
簡単に言うとこんな感じ!
メモリ(ヒープ領域)に悪意あるコードをバラまいて、「どこかに当たればOK!」って狙う攻撃手法だよ。的をひとつに絞れないなら、的ごとペンキで塗り潰しちゃえ!って発想なんだ。ブラウザやPDFリーダーの脆弱性を利用して乗っ取るときによく使われる古典的かつ強力な手口だよ!
ヒープスプレーとは
ヒープスプレー(Heap Spray)とは、コンピューターのメモリ上の「ヒープ領域」と呼ばれる動的メモリ空間に、悪意あるコード(シェルコード)をスプレー缶のように大量にばらまくことで、攻撃の命中精度を意図的に上げる手法です。通常の脆弱性攻撃では「正確にどのアドレスにジャンプすれば悪意あるコードが実行されるか」を特定する必要がありますが、ヒープスプレーはその必要をなくします。
攻撃者はJavaScriptやActionScriptなどのスクリプトを使ってヒープに同じパターンのデータを繰り返し書き込み、メモリ空間の大部分を悪意あるコードで埋め尽くします。その後、別の脆弱性(バッファオーバーフロー、use-after-freeなど)を使ってプログラムの実行制御を奪い、「どこに飛んでもシェルコードに当たる」状態を作り出すのです。
この手法は2001年頃から登場し、特にブラウザやプラグイン(Flash、Java、PDF)の攻撃で広く悪用されました。現代のOSには対策機能が組み込まれていますが、それを回避する進化版の技術も生まれており、今なお研究・対策が続いている重要なセキュリティトピックです。
ヒープスプレーの仕組み
攻撃が成立するまでには「準備→散布→トリガー→実行」の4ステップがあります。
| ステップ | 内容 | 具体例 |
|---|---|---|
| ① 準備 | 悪意あるコードをペイロードとして用意 | シェルコード+NOP sledを組み合わせる |
| ② 散布(Spray) | スクリプトでヒープに大量書き込み | JavaScriptで数十MBの文字列を繰り返しアロケート |
| ③ トリガー | 別の脆弱性で実行ポインタを書き換え | use-after-free・型混乱バグを悪用 |
| ④ 実行 | 書き換えたポインタがヒープ内に着地→悪意あるコードが実行される | 任意コード実行・OS乗っ取り |
NOP sledとは
NOP sled(ノップスレッド)とは「何もしない命令(NOP命令)」を大量に並べたものです。雪山のスキーのそり台(sled)のように、どこに着地しても「すべって」最終的に本物のシェルコードへ滑り込んでくれます。これにより着地アドレスがずれても攻撃が成立しやすくなります。
[NOP][NOP][NOP]...[NOP][NOP][シェルコード]
↑ここに飛んでも ↑ここでも ↑ここが本命
全部最終的にシェルコードへ到達する
ヒープスプレーが狙うメモリ領域
| 領域 | 役割 | 攻撃者が注目する理由 |
|---|---|---|
| ヒープ(Heap) | 実行時に動的確保されるメモリ | スクリプトから自由にアロケートできる |
| スタック(Stack) | 関数呼び出し管理 | サイズ制限があり大量散布には不向き |
| コードセグメント | プログラム本体 | 通常は書き込み禁止 |
歴史と背景
- 2001年ごろ — SkyLined(研究者)がInternet Explorerの脆弱性を攻撃するためにヒープスプレーを体系化。初期のエクスプロイトコードに登場
- 2004〜2008年 — FlashやJava、QuickTimeなどブラウザプラグインの全盛期と重なり、ヒープスプレーを使った攻撃が急増。一般ユーザーがWebサイトを閲覧しただけで感染するドライブバイダウンロード攻撃に多用される
- 2007年 — WindowsがASLR(Address Space Layout Randomization)を本格導入。メモリアドレスをランダム化することでヒープスプレーの命中率を下げる対策が始まる
- 2008〜2010年 — ASLRを回避する「JIT Spraying(Just-In-Time Spray)」が登場。JavaScriptのJITコンパイラを逆用してコードセグメントにシェルコードを紛れ込ませる高度化が進む
- 2012年以降 — Flashの衰退・ブラウザのサンドボックス強化・CFG(Control Flow Guard)の導入などにより古典的なヒープスプレーは成立しにくくなる
- 現在 — 完全には消えておらず、ゼロデイ脆弱性と組み合わせた高度な標的型攻撃(APT)で今も使われ続けている
関連する防御技術との比較
ヒープスプレーへの対策は「どこにいるか分からなくする」「そもそも実行させない」の2方向で進化してきました。
| 防御技術 | 略称 | 対策の考え方 | ヒープスプレーへの効果 |
|---|---|---|---|
| アドレス空間配置ランダム化 | ASLR | メモリアドレスを毎回ランダム化 | 着地先を予測しにくくする(完全ではない) |
| データ実行防止 | DEP / NX | ヒープ・スタックのコードを実行不可に | シェルコードの直接実行を防ぐ |
| 制御フローガード | CFG | 間接呼び出し先を制限 | ポインタ改ざん後の実行を防ぐ |
| ヒープメタデータ保護 | SafeHeap等 | ヒープ管理構造を保護 | ヒープ操作による情報漏洩を防ぐ |
| サンドボックス | — | プロセスの権限・アクセスを隔離 | 攻撃が成立しても被害を限定 |
攻撃と防御の進化を図に示します。
実務担当者が知っておくべきポイント
ヒープスプレー攻撃への対策として、システム発注・選定の際に確認すべき項目は以下の通りです。
- ブラウザ・プラグインを最新に保つ:脆弱性がなければトリガーを引けない
- Flash・Java等のレガシープラグインを排除:攻撃対象そのものをなくす
- EDR(Endpoint Detection & Response)ツールの導入:異常なメモリアロケーションを検知
- OSのASLR/DEPが有効か確認:Windowsのシステム設定・グループポリシーで確認可能
関連する規格・RFC
| 規格・文書 | 内容 |
|---|---|
| NIST SP 800-83 | マルウェア・インシデント対応のガイドライン(ヒープスプレーを含むメモリ攻撃に言及) |
| CWE-122 | ヒープベースのバッファオーバーフロー(ヒープスプレーのトリガーとなる脆弱性分類) |
| CVE Database | ヒープスプレーを利用した具体的な脆弱性事例が多数登録されている |
関連用語
- バッファオーバーフロー — メモリ境界を越えてデータを書き込む古典的な脆弱性。ヒープスプレーのトリガーとして使われる
- ASLR — アドレス空間配置ランダム化。ヒープスプレーへの主要な対抗手段
- DEP / NX — データ実行防止。ヒープ上のコードを実行不可にする保護技術
- シェルコード — 攻撃者がメモリに埋め込む悪意ある実行コードの総称
- エクスプロイト — 脆弱性を実際に突いて攻撃を成立させるコード・手法
- use-after-free — 解放済みメモリを再利用する脆弱性。ヒープスプレーのトリガーとして頻用される
- ドライブバイダウンロード — Webページ閲覧だけでマルウェアに感染させる攻撃。ヒープスプレーが中核技術として使われる
- EDR — エンドポイント検知・対応。異常なメモリ操作をリアルタイム検知する防御ツール