オペレーション・トライアンギュレーション：研究者たちのiPhoneを攻撃して得られるもの
(securelist.com)- Kasperskyの研究チームは37C3で Operation Triangulation の iPhone 0-click iMessage 攻撃チェーンを公開し、これまで見てきた中で最も精巧なチェーンだと評価した
- 攻撃はiOS 16.2までで動作するよう設計されており、4つのゼロデイ を組み合わせて、リモートコード実行、権限昇格、PPL回避、Safari段階の実行へとつながる
- 中核となる謎は CVE-2023-38606 で緩和された区間で、攻撃者はApple A12–A16 Bionic SoCの未知のMMIOレジスタを利用して、ハードウェアベースのカーネルメモリ保護を回避した
- 分析の結果、これらのレジスタは GPU補助プロセッサ に関連しているように見え、一部はDeviceTreeやファームウェアから参照されておらず、攻撃者がどうやって使い方を知ったのかは確認されていない
- 2024年1月9日のアップデートでは、「カスタムハッシュ」に見えていた値が Hamming codeベースのECC であることが確認され、この機能はメモリではなくキャッシュに直接アクセスするデバッグ機能である可能性が高まった
公開された攻撃チェーン
- 2023年12月27日の37C3発表で、Operation Triangulationの長期分析結果が公開された
- この発表で、攻撃に使われたエクスプロイトと脆弱性の詳細が初めて公開された
- 研究チームはAdobe、Apple、Google、Microsoft製品で30件以上の実際に悪用されたゼロデイを発見・報告してきたが、この攻撃チェーンはその中でも最も精巧なレベルだと評価している
iMessage 0-clickからスパイウェアの読み込みまで
- 攻撃者は悪意ある iMessage添付ファイル を送り、アプリケーションはこれをユーザーに表示しないまま処理する
- 添付ファイルは、Apple専用の文書化されていないADJUST TrueTypeフォント命令にあるリモートコード実行脆弱性 CVE-2023-41990 を悪用する
- この命令は1990年代初頭から存在し、パッチで削除された
- その後、return/jump oriented programmingとNSExpression/NSPredicateクエリ言語で書かれた複数段階が続く
- JavaScriptCore環境にパッチを当てて、JavaScriptで書かれた権限昇格エクスプロイトを実行する
- JavaScriptエクスプロイトはサイズ削減のため完全に読みにくく難読化されているが、約 11,000行 規模である
- 大半はJavaScriptCoreとカーネルメモリの解析・操作に使われる
- JavaScriptCoreのデバッグ機能 DollarVM($vm) を悪用して、スクリプトからJavaScriptCoreメモリを操作し、ネイティブAPI関数を実行する
- 旧型・新型iPhoneの両方をサポートするよう設計されており、最新モデルを悪用するための PAC回避 も含まれている
カーネルメモリアクセスとPPL回避
- エクスプロイトは、XNUのメモリマッピングsyscallである
mach_make_memory_entryとvm_mapの整数オーバーフロー脆弱性 CVE-2023-32434 を使用する- ユーザーレベルからデバイスの全物理メモリに対する読み書きアクセスを得る
- その後、ハードウェア MMIOレジスタ によってPage Protection Layer(PPL)を回避する
- この区間は CVE-2023-38606 で緩和された
- すべての脆弱性悪用の後、JavaScriptエクスプロイトはデバイス上で任意の動作を実行できた
- 攻撃者はIMAgentプロセスを実行してペイロードを注入し、エクスプロイトの痕跡を消す
- Safariプロセスを見えないモードで実行し、次段階のWebページへ渡す
- Webページは被害者を確認した後、条件を満たせばSafariエクスプロイトを配信する
- Safariエクスプロイトは CVE-2023-32435 を使ってシェルコードを実行する
- シェルコードは、Mach objectファイル形式の別のカーネルエクスプロイトを実行する
- このエクスプロイトも CVE-2023-32434 と CVE-2023-38606 を使う
- JavaScriptカーネルエクスプロイトとは大部分が異なるが、同じ脆弱性悪用に関わる一部コードだけを共有している
- 最終的にroot権限を取得し、別の段階を実行してスパイウェアを読み込む
CVE-2023-38606のハードウェア上の謎
- 最新のiPhoneモデルは、機密性の高いカーネルメモリ領域を保護するためのハードウェアベース保護機能を備えている
- この保護は、攻撃者がカーネルメモリを読み書きできても、デバイス全体を完全には制御できないようにするために設計されている
- Operation Triangulationの攻撃者は、Apple設計SoCの別の ハードウェア機能 を使ってこの保護を回避した
- 確認された動作は次の通り
- データ、宛先アドレス、データハッシュをチップ上の未知のハードウェアレジスタに書き込む
- これらのレジスタはファームウェアでは使われていないように見える
- その結果、ハードウェアベースのメモリ保護を回避して特定の物理アドレスにデータを書き込める
- この機能はAppleエンジニア向け、または工場テスト用のデバッグ機能だったか、あるいは誤って含まれた可能性がある
- ファームウェアで使われていない機能であるため、攻撃者がどうやって使い方を知ったのかは確認されていない
MMIOとDeviceTreeの分析
- SoCの周辺デバイスは、CPUがデバイスを制御できるように特別なハードウェアレジスタを提供することがある
- これらのレジスタはCPUがアクセス可能なメモリにマッピングされ、memory-mapped I/O(MMIO) と呼ばれる
- Apple製品の周辺デバイスMMIOアドレス範囲は DeviceTree 形式で保存されている
- DeviceTreeファイルはファームウェアから抽出できる
- dt ユーティリティで内容を確認できる
- 攻撃者がPPL回避に使用したMMIOの大半は、DeviceTreeで定義されたどのMMIO範囲にも属していなかった
- エクスプロイトはApple A12–A16 Bionic SoC を対象とし、次の未知のMMIOブロックを使用する
0x2060400000x2061400000x206150000
- 複数のデバイスとファームウェアのDeviceTree、公開ソースコード、カーネルイメージ、カーネル拡張、iBoot、補助プロセッサファームウェアから、これらのアドレス参照は見つかっていない
GPU補助プロセッサとの関連
- 周辺の既知のMMIOを確認すると、未知のアドレスは gfx-asc、つまりGPU補助プロセッサの近くに位置していた
gfx-ascには2つのMMIO範囲がある0x206400000–0x20646C0000x206050000–0x206050008
- エクスプロイトが実際に使った未知のアドレスは次の通り
0x2060400000x2061400080x2061401080x2061500200x2061500400x206150048
- その大半は2つの
gfx-asc領域の間にあり、残る1つは最初のgfx-asc領域の開始地点付近にある - これらのレジスタはGPU補助プロセッサに属する可能性が高いと判断された
- エクスプロイト初期化の過程では、SoCごとに異なるアドレスのGFX電源マネージャレジスタを操作するコードも確認された
- pmgr ユーティリティで、これらのアドレスが電源マネージャMMIO範囲のGFXレジスタに対応することが確認された
- 未知領域のレジスタにアクセスすると、GPU補助プロセッサが「GFX SERROR Exception」というメッセージでパニックを起こした
- この結果も、当該レジスタがGPU補助プロセッサに属するという判断を裏付けている
CoreSightとApple独自のUTT領域
0x206040000レジスタは、エクスプロイトの初期化と終了段階でのみ使用される- 初期化で最初に設定され、終了で最後に処理される
- このレジスタは、ハードウェア機能の有効化・無効化や割り込み制御を担うものと分析されている
- エクスプロイトの動作は、XNUソースコード
dbgwrap.cのml_dbgwrap_halt_cpu関数と対応している dbgwrap.cは、メインCPUのARM CoreSight MMIOデバッグレジスタを扱うコードである- XNUソースコードは、CoreSight関連MMIO領域としてED、CTI、PMU、UTTの4領域に言及している
- 各領域は
0x10000バイトを占める - 4領域は互いに隣接している
- 各領域は
- UTT領域はARM由来ではなく、便宜のために追加されたApple独自機能だとソースコードに記されている
ARM_DBG_LOCK_ACCESS_KEYをその位置に書き込むことで、0x206000000–0x206050000がGPU補助プロセッサのCoreSight MMIOデバッグレジスタブロックであることが確認できる- メインCPUの各コアも独自のCoreSight MMIOデバッグレジスタブロックを持つが、GPU補助プロセッサと違ってそのアドレスはDeviceTreeで見つけられる
- エクスプロイト作者は、Apple独自のUTT領域を使ってCPU haltを解除する方法も知っていた
- このコードはXNUソースコードには含まれていない
DMAのように動作する未確認機能
0x206140008と0x206140108レジスタは、エクスプロイトが利用するハードウェア機能の有効化・無効化と実行を制御する0x206150020はApple A15/A16 Bionic SoCでのみ使用される- 初期化段階で1に設定され、終了段階で元の値に戻される
0x206150040はフラグと宛先物理アドレスの下位半分を保存するために使われる0x206150048は、書き込むデータ、宛先物理アドレスの上位半分、データハッシュ、別の1つの値をまとめて保存するために使われる- ハードウェア機能は、アラインされた
0x40バイトブロック単位でデータを書き込む 0x206150048レジスタには9回連続で書き込む必要がある
- ハードウェア機能は、アラインされた
- すべての手順が正しければ、ハードウェアは DMA 動作を実行して要求された位置にデータを書き込む
- エクスプロイトはこの機能をPPL回避に使い、主にページテーブルエントリをパッチする
- 保護された
__PPLDATAセグメント内のデータパッチにも使える - カーネルコードのパッチにはこの機能を使っていなかった
- テスト中、一度
__TEXT_EXECセグメントのカーネル命令を上書きし、想定したアドレスと値で「Undefined Kernel Instruction」パニックを得た - 別の試行ではAMCCパニックが発生した
- テスト中、一度
ハッシュ、ECC、そしてキャッシュアクセスの可能性
- 初期分析では、この機能はユーザー定義ハッシュを要求するように見えていた
- ハッシュは事前定義された
sboxテーブルを使って計算される - 大規模なバイナリコレクションからこのテーブルを検索したが見つからなかった
- ハッシュは事前定義された
- ハッシュは20ビット、つまり10ビット値を2回計算する形に見えた
- 攻撃者が計算方法と使い方を知らなければ、この構造は security by obscurity に近い
- 2024年1月9日のアップデートで、Hector Martinはこの値が単なるカスタムハッシュではなく誤り訂正コード(ECC)だと確認した
- より正確には、カスタムlookup tableを使う Hamming code である
- この発見は、未確認ハードウェア機能の本来の目的を理解する手がかりになった
- 当初は、直接メモリアクセスを提供するデバッグ機能に「ダミー」ハッシュが付いているように見えた
- ECCが使われていることと、カーネルコードパッチ時に不安定な動作が観察されたことから、この機能は キャッシュに直接アクセス する機能である可能性が高まった
M1実験とiOS 16.6での緩和
- Macの M1チップ にもこの未知のハードウェア機能が存在することが確認された
- m1n1 ツールの
trace_range機能で0x206110000–0x206400000範囲のMMIOアクセスを追跡した- macOSがこれらのレジスタを使用した痕跡は報告されていない
- iOS 16.6でAppleは、エクスプロイトが使ったMMIO範囲をDeviceTreeの
pmap-io-rangesに追加することで脆弱性を緩和した- 追加された範囲は
0x206000000–0x206050000と0x206110000–0x206400000である
- 追加された範囲は
- XNUは
pmap-io-ranges情報を使って、特定の物理アドレスのマッピングを許可するかどうかを決定する - 一般的な
pmap-io-rangesエントリにはPCIe、DART、DAPFのような意味のあるタグ名が付くが、この脆弱性関連領域のタグ名は他のエントリと比べて目立つ形式だった
残された疑問とセキュリティ上の含意
- 攻撃者がこの未知のハードウェア機能の使い方をどうやって知ったのかは確認されていない
- この機能の本来の目的も依然として不明である
- Appleが開発した機能なのか、ARM CoreSightのようなサードパーティ製コンポーネントなのかも分かっていない
- アップデート後もなお謎は残る
- 攻撃者が実験だけでカスタムlookup tableの値をbrute forceできる可能性はある
- しかし、そのためには強力なキャッシュデバッグ機能の存在、Hamming codeの使用、関連MMIOレジスタの位置と目的、相互作用の順序まで把握している必要がある
- ハードウェアベース保護があっても、それを回避できるハードウェア機能が存在すれば、精巧な攻撃者の前では無力化され得る
- ハードウェアセキュリティはソフトウェアよりはるかにリバースエンジニアリングが難しいが、“security through obscurity” に依存するシステムは、その秘密が明らかになった瞬間に安全ではなくなる
1件のコメント
Hacker News のコメント
発表動画も今は上がっている: https://www.youtube.com/watch?v=7VWNUUldBEE
かなり驚くべき内容。MMIO の悪用は、攻撃者たちが本当に途方もない研究能力を持っていたか、Apple をハッキングして内部のハードウェア文書を入手したかのどちらかだが、後者のほうがもっともらしく見える。
カスタムハッシュ関数の S-box が出てくるまでは、NSA 級の大規模研究チームなら可能かもしれないと思っていたが、そこから先は、Apple がその機能が危険だと知っていて意図的に隠し、それが何であれ、さらに一種の弱いデジタル署名機能で保護までしていたように見える。
ブログ記事が指摘しているように、シリコン全体を剥がしてリバースエンジニアリングする以外に、この機能を作動させる正しい「マジックノック」を見つける明確な方法はない。このようなプロセスノードでは事実上非現実的なので、開発者をハッキングして内部文書を盗んだという線が残る。
高コストのゼロデイチェーンを長々と使って見えない Safari を起動し、その後まったく別のエクスプロイトチェーンでウェブページを読み込ませてデバイスを再びハッキングするやり方も、内部サイロが深刻な巨大組織の匂いがする。
研究者たちが Kaspersky のロシア人であることを考えると、これはほぼ NSA、あるいはもしかすると GCHQ の作戦である可能性が高い。
発表のほかの興味深い点として、マルウェアは広告トラッキングを有効にでき、セキュリティ研究者がよく使うクラウド iPhone ホスティングも検知できる。iOS/macOS マルウェアプラットフォームは10年以上開発されてきたようで、写真のバイト列をアップロードしないように、デバイス上で物体認識と OCR を行う機械学習まで動かし、生成されたラベルだけをアップロードする。本当に多大な労力を注いでいたが、結局、賢いロシアの学生たちの前では十分ではなかった。
ただし、発表者が言った「曖昧さによるセキュリティは機能しない」には完全には同意しない。このプラットフォームは10年間実環境に存在しており、隠されたハードウェア「機能」をどれほど長く悪用していたのかは誰にも分からない。そのハードウェア機能が公開文書化されていたなら、はるかに、はるかに早く発見されていただろう。
素早い適応のためのモジュール設計かもしれず、つまり標的をあまり限定しない構造である可能性もある。
[1] https://social.treehouse.systems/@marcan/111655847458820583
Steve Weis が Twitter で最もうまく要約していた:
「この iMessage エクスプロイトは狂っている。90年代から存在する TrueType 脆弱性、2つのカーネルエクスプロイト、ブラウザエクスプロイト、そしてリリースされたソフトウェアでは使われていない文書化されていないハードウェア機能まである」
https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...
Kaspersky 研究者たちの発表が気になるなら、整理された動画はまだ上がっていないが、配信のアーカイブはここで見られる:
https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
発表は 26:20 から始まる。
37c3 の発表については、ドイツ語の Fefe¹ の記事もある: https://blog.fefe.de/?ts=9b729398
それによると、このエクスプロイトチェーンの価値は8桁ドル規模だった可能性が高い。
¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
誰かがクビになりそうだ。
Coresight はバックドアではなく、すべての ARM CPU にあるデバッグ機能だ。これは Apple のメモリ保護機能と連携するために必要な Coresight 拡張のように見える。
公開文書はなくても、何千人もの Apple エンジニアが、それを利用できる改造版 gdb や他のツールにアクセスできるはずだ。
監督対象デバイスであれば、macOS App Store の無料の Apple Configurator を通じてローカル MDM で iMessage を無効化できる: https://support.apple.com/guide/deployment/restrictions-for-...
Wi-Fi 専用デバイスでは Messages アプリが非表示になる
Wi-Fi とセルラーの両方を備えたデバイスでは Messages アプリは引き続き表示されるが、SMS/MMS サービスだけが利用できる
たとえばデバイスを長期間 Wi-Fi のみで使う場合は、SIM PIN で SMS/MMS メッセージと緊急時以外のセルラー無線トラフィックを無効化できる
ところが、セルラー iPad は SIM カードの通信事業者から送られたものではない SMS を実質的に表示しないことが分かった
すべて 0 のデータ書き込みのハッシュ値が 0 である点が目を引く
そして単一ビットの場合、ハッシュ値は S-box テーブルの単一の値になる。つまり、この ハッシュアルゴリズムは内部文書がなくても十分にリバースエンジニアリングできた可能性がある
実際、誰かが「バグで任意書き込みが起きてはいけない」と言ったのなら、私ならこう実装しただろう。この実装は、バッファのアドレスは分かっているが内容は分からない状態でこの機能を使うことも効果的に防ぐ
ハッシュ値が間違うたびにシステムを再起動するなら、10ビットの安全性でもその用途にはおそらく十分だ。Coresight のデバッグ機能は、望めばシステムを完全に再起動できる
この MMIO レジスタを、すべてのレジスタアドレスに対して ブルートフォース探索して発見した可能性はどの程度あるだろうか?
タイミング差だけでも、そのアドレスが有効なアドレスだと分かった可能性があるし、ハッシュも実質的に 20ビットハッシュなのでブルートフォースできたかもしれない
それほど簡単には説明できないのは、デバッグコードを実行するためにカスタム S-box テーブルをどう復元したかという点だ。ここで 内部者脅威を示唆するニュアンスが最も強くなるが、個人的には他のもっともらしい説明を排除するものだとは思わない
たとえば攻撃者は、古いファームウェア、OTA アップデートのパッチ、発売前の開発用デバイス（ある時点では eBay で買えた可能性が高い）、iOS ベータリリース、その他さまざまな流出経路から S-box を抽出した可能性がある
研究者は基本的に「調べた他のどのバイナリにもこの S-box テーブルは見つからなかった」と述べている。しかし Apple 専用のものに見えるため、登場し得るバイナリの数が限られていることを考えると、必ずしも驚くことではない。研究者も述べているように、ここには現在は公開されていない、誤って配布された可能性のあるバイナリも含まれる。攻撃者たちがこうした流出を体系的に探しているうちに、どこかの時点で運よく入手し、研究者がすぐ同じ幸運に恵まれるとは限らない、というのは十分にあり得る
攻撃者たちがそのブール式を知らなかったという事実は、文書を持っていたというより、リバースエンジニアリングしたという方向を示唆している
https://streaming.media.ccc.de/37c3/relive/11859
発表内容とあわせて時系列で整理すると次のようになる
2018年9月: 文書化されていない MMIO を持つ最初の CPU である Apple A12 Bionic SOC が発売
2021年12月: 初期のエクスプロイトチェーン基盤 backuprabbit.com は 2021-12-15T18:33:19Z に、cloudsponcer.com は 2021-12-17T16:33:50Z に作成
2022年4月: その後のエクスプロイトチェーン基盤 snoweeanalytics.com が 2022-04-20T15:09:17Z に作成され、この日までにはエクスプロイトが兵器化されていたことを示唆
2023年12月: おおよその捕捉時期と見られる。「半年」という分析期間と 2023年半ばの Apple への報告から逆算したもの
発表者たちは、コード内部の痕跡から、元の出所である APT グループが同じ攻撃コードベースを「10年」にわたり、つまり 2013年ごろから使っており、macOS ノートブック攻撃にも使っていると述べている。ウイルス対策の回避も含まれる
発表者たちは、非常に「バックドアのような」署名済みデバッグ機能が、Apple の知らないところで、たとえば GPU 開発者によってチップに組み込まれた可能性にも触れている
つまり、最初の脆弱なチップが市場に出てから 3.5年もたたないうちに、長い秘密値の知識を必要とする Apple Coresight GPU の文書化されていないデバッグ MMIO シリーズが、10年以上の履歴を持つ既存の APT グループによって成功裏に兵器化され、悪用されたということだ。Kaspersky は「推測しない」としているが、個人的には主要な 国家主体以外では可能性が低そうに見える
推測するなら、Apple が APT 関連の Apple ID 約40件が自ら身元を露呈した十分な証拠を受け取っているはずなので、今後の米国の国家安全保障関連の発表の有無で正体を判断できそうだ。静かなら、おそらく NSA だろう
https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...