diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md index e82769821..3eea8ed4d 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-dirty-nib.md @@ -2,72 +2,146 @@ {{#include ../../../banners/hacktricks-training.md}} -**この技術の詳細については、次の元の投稿を確認してください:** [**https://blog.xpnsec.com/dirtynib/**](https://blog.xpnsec.com/dirtynib/) および次の投稿 [**https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/**](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/)**.** ここに要約があります: +Dirty NIBは、署名されたmacOSアプリバンドル内のInterface Builderファイル（.xib/.nib）を悪用して、ターゲットプロセス内で攻撃者が制御するロジックを実行させ、そのentitlementsやTCC権限を継承する手法を指します。この手法は元々xpn (MDSec)によって文書化され、その後Sector7が一般化・大幅に拡張し、macOS 13 VenturaおよびmacOS 14 SonomaでのAppleの緩和策についても解説しました。背景や詳細な解説は末尾の参考文献を参照してください。 -### Nibファイルとは +> TL;DR +> • macOS 13 Ventura以前: バンドルのMainMenu.nib（または起動時に読み込まれる他のnib）を置き換えることで、プロセスインジェクションを確実に達成でき、しばしばprivilege escalationを引き起こせました。 +> • macOS 13 (Ventura)以降、macOS 14 (Sonoma)でさらに強化: first‑launch deep verification、bundle protection、Launch Constraints、および新しいTCC “App Management” permissionにより、非関連アプリによるpost‑launch nib tamperingは概ね防止されます。攻撃は一部のニッチなケース（例: same‑developer toolingが自社アプリを変更する場合、またはユーザが端末にApp Management/Full Disk Accessを付与している場合）では依然として可能な場合があります。 -Nib（NeXT Interface Builderの略）ファイルは、Appleの開発エコシステムの一部であり、アプリケーション内の**UI要素**とその相互作用を定義するために使用されます。これらはウィンドウやボタンなどのシリアライズされたオブジェクトを含み、ランタイムで読み込まれます。現在も使用されていますが、Appleはより包括的なUIフローの視覚化のためにStoryboardを推奨しています。 +## What are NIB/XIB files -主要なNibファイルは、アプリケーションの`Info.plist`ファイル内の**`NSMainNibFile`**の値で参照され、アプリケーションの`main`関数で実行される**`NSApplicationMain`**関数によって読み込まれます。 +Nib（NeXT Interface Builderの略）ファイルは、AppKitアプリで使用されるシリアライズされたUIオブジェクトグラフです。現代のXcodeは編集可能なXMLの .xib ファイルを保存し、ビルド時に .nib にコンパイルします。典型的なアプリは `NSApplicationMain()` を通じてメインUIを読み込み、アプリの `Info.plist` 内の `NSMainNibFile` キーを読み取って実行時にオブジェクトグラフをインスタンス化します。 -### Dirty Nib注入プロセス +キーとなる点（攻撃を可能にする要因）: +- NIBの読み込みは、NSSecureCodingに準拠させる必要なく任意のObjective‑Cクラスをインスタンス化します（Appleのnibローダは `initWithCoder:` が利用できない場合に `init`/`initWithFrame:` にフォールバックします）。 +- Cocoa Bindingsは、nibがインスタンス化される際にメソッドを呼び出すために悪用でき、ユーザ操作を必要としないチェイン呼び出しも可能です。 -#### NIBファイルの作成と設定 +## Dirty NIB injection process (attacker view) -1. **初期設定**: -- XCodeを使用して新しいNIBファイルを作成します。 -- インターフェースにオブジェクトを追加し、そのクラスを`NSAppleScript`に設定します。 -- ユーザー定義のランタイム属性を介して初期の`source`プロパティを設定します。 -2. **コード実行ガジェット**: -- この設定により、必要に応じてAppleScriptを実行できます。 -- `Apple Script`オブジェクトをアクティブにするボタンを統合し、特に`executeAndReturnError:`セレクタをトリガーします。 -3. **テスト**: +古典的なVentura以前のフロー: +1) Create a malicious .xib +- Add an `NSAppleScript` object (or other “gadget” classes such as `NSTask`). +- Add an `NSTextField` whose title contains the payload (e.g., AppleScript or command arguments). +- Add one or more `NSMenuItem` objects wired via bindings to call methods on the target object. -- テスト用のシンプルなApple Script: +2) Auto‑trigger without user clicks +- Use bindings to set a menu item’s target/selector and then invoke the private `_corePerformAction` method so the action fires automatically when the nib loads. This removes the need for a user to click a button. -```bash +Minimal example of an auto‑trigger chain inside a .xib (abridged for clarity): +```xml + + + + + + + + + + + + + + + + + + + + + + +``` +これにより、nib のロード時に対象プロセス内で任意の AppleScript を実行できます。高度なチェーンでは以下が可能です： +- 任意の AppKit クラス（例: `NSTask`）をインスタンス化し、`-launch` のような引数なしメソッドを呼び出す。 +- 上述の binding trick を使って、オブジェクト引数付きの任意の selectors を呼び出す。 +- `AppleScriptObjC.framework` をロードして Objective‑C にブリッジし、選択した C APIs を呼び出すことも可能。 +- まだ `Python.framework` を含む古いシステムでは、Python にブリッジし、`ctypes` を使って任意の C 関数を呼び出す（Sector7 の研究）。 + +3) アプリの nib を置き換える +- `target.app` を書き込み可能な場所にコピーし、例えば `Contents/Resources/MainMenu.nib` を悪意ある nib に置き換えて `target.app` を実行する。Pre‑Ventura では一度だけ Gatekeeper による評価が行われた後、以降の起動では簡易的な署名チェックしか行われなかったため、.nib のような非実行リソースは再検証されなかった。 + +目に見えるテスト用の AppleScript payload の例: +```applescript set theDialogText to "PWND" display dialog theDialogText ``` +## Modern macOS protections (Ventura/Monterey/Sonoma/Sequoia) -- XCodeデバッガーで実行し、ボタンをクリックしてテストします。 +Apple は Dirty NIB の有効性を大幅に低下させる複数のシステム的緩和策を導入しました: +- First‑launch deep verification and bundle protection (macOS 13 Ventura) +- 任意のアプリを初回実行した際（quarantined か否かにかかわらず）、バンドル内の全リソースに対して深い署名チェックが行われます。その後、バンドルは保護され、同一の開発者（またはアプリが明示的に許可したもの）からのアプリだけがその内容を変更できます。他のアプリが別アプリのバンドルに書き込むには、新しい TCC “App Management” 権限が必要になります。 +- Launch Constraints (macOS 13 Ventura) +- System/Apple‑bundled apps を別の場所にコピーして起動することができなくなり、OS アプリに対する「/tmp にコピーしてパッチを当てて実行する」方法が無効化されます。 +- Improvements in macOS 14 Sonoma +- Apple は App Management を強化し、Sector7 が指摘した既知のバイパス（例: CVE‑2023‑40450）を修正しました。Python.framework は以前に削除されており（macOS 12.3）、一部の権限昇格チェーンが断たれています。 +- Gatekeeper/Quarantine changes +- この手法に影響した Gatekeeper、provenance、assessment の変更については下記の参照ページを参照してください。 -#### アプリケーションのターゲット（例：Pages） +> Practical implication +> • On Ventura+ you generally cannot modify a third‑party app’s .nib unless your process has App Management or is signed by the same Team ID as the target (e.g., developer tooling). +> • Granting App Management or Full Disk Access to shells/terminals effectively re‑opens this attack surface for anything that can execute code inside that terminal’s context. -1. **準備**: -- ターゲットアプリ（例：Pages）を別のディレクトリ（例：`/tmp/`）にコピーします。 -- Gatekeeperの問題を回避し、アプリをキャッシュするためにアプリを起動します。 -2. **NIBファイルの上書き**: -- 既存のNIBファイル（例：About Panel NIB）を作成したDirtyNIBファイルで置き換えます。 -3. **実行**: -- アプリと対話して実行をトリガーします（例：`About`メニュー項目を選択）。 -#### 概念実証：ユーザーデータへのアクセス +### Addressing Launch Constraints -- ユーザーの同意なしに、AppleScriptを修正してユーザーデータ（写真など）にアクセスし、抽出します。 +Launch Constraints は Ventura 以降、非標準の場所から多くの Apple アプリを実行することを防ぎます。もし Apple アプリを一時ディレクトリにコピーして `MainMenu.nib` を変更し起動する、というような pre‑Ventura のワークフローに依存していた場合、>= 13.0 では失敗することを想定してください。 -### コードサンプル：悪意のある .xib ファイル -- 任意のコードを実行することを示す[**悪意のある .xib ファイルのサンプル**](https://gist.github.com/xpn/16bfbe5a3f64fedfcc1822d0562636b4)にアクセスして確認します。 +## Enumerating targets and nibs (useful for research / legacy systems) -### その他の例 +- Locate apps whose UI is nib‑driven: +```bash +find /Applications -maxdepth 2 -name Info.plist -exec sh -c \ +'for p; do if /usr/libexec/PlistBuddy -c "Print :NSMainNibFile" "$p" >/dev/null 2>&1; \ +then echo "[+] $(dirname "$p") uses NSMainNibFile=$( /usr/libexec/PlistBuddy -c "Print :NSMainNibFile" "$p" )"; fi; done' sh {} + +``` +- バンドル内の候補となる nib リソースを見つける： +```bash +find target.app -type f \( -name "*.nib" -o -name "*.xib" \) -print +``` +- コード署名を厳密に検証する（リソースを改ざんして再署名していない場合は失敗する）: +```bash +codesign --verify --deep --strict --verbose=4 target.app +``` +> 注: 現代の macOS では、正当な認可なしに別のアプリのバンドルに書き込もうとすると、bundle protection/TCC によってブロックされます。 -投稿[https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/](https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/)では、ダーティニブの作成方法に関するチュートリアルを見つけることができます。 -### 起動制約への対処 +## 検出と DFIR のヒント -- 起動制約は、予期しない場所（例：`/tmp`）からのアプリの実行を妨げます。 -- 起動制約によって保護されていないアプリを特定し、NIBファイル注入のターゲットにすることが可能です。 +- バンドルリソースのファイル整合性監視 +- インストール済みアプリの `Contents/Resources/*.nib` やその他の非実行可能なリソースの mtime/ctime 変更を監視する。 +- Unified logs とプロセス挙動の監視 +- GUI アプリ内での予期しない AppleScript の実行や、AppleScriptObjC または Python.framework をロードするプロセスを監視する。例: +```bash +log stream --info --predicate 'processImagePath CONTAINS[cd] ".app/Contents/MacOS/" AND (eventMessage CONTAINS[cd] "AppleScript" OR eventMessage CONTAINS[cd] "loadAppleScriptObjectiveCScripts")' +``` +- プロアクティブな評価 +- 重要なアプリに対して定期的に `codesign --verify --deep` を実行し、リソースが改変されていないことを確認する。 +- 権限コンテキスト +- 誰が／何が TCC の “App Management” や Full Disk Access を持っているかを監査する（特に端末や管理エージェント）。これらを汎用シェルから除外することで、容易に Dirty NIB‑style の改ざんを再有効化されるのを防げる。 -### 追加のmacOS保護 -macOS Sonoma以降、アプリバンドル内の変更が制限されています。ただし、以前の方法には以下が含まれていました： +## 防御的強化（開発者と防御者向け） -1. アプリを別の場所（例：`/tmp/`）にコピーします。 -2. 初期の保護を回避するためにアプリバンドル内のディレクトリの名前を変更します。 -3. Gatekeeperに登録するためにアプリを実行した後、アプリバンドルを変更します（例：MainMenu.nibをDirty.nibに置き換えます）。 -4. ディレクトリの名前を元に戻し、アプリを再実行して注入されたNIBファイルを実行します。 +- プログラム的な UI を優先するか、nib からインスタンス化される内容を制限する。nib グラフに強力なクラス（例: `NSTask`）を含めないこと、任意のオブジェクト上で間接的にセレクタを呼ぶバインディングを避けること。 +- Library Validation を有効にした hardened runtime を採用する（現代のアプリでは既に標準）。これだけで nib 注入を完全に防げるわけではないが、容易なネイティブコードの読み込みを阻止し、攻撃者をスクリプトのみのペイロードに追い込む。 +- 汎用ツールで広範な App Management 権限を要求・依存しないこと。MDM が App Management を必要とする場合は、そのコンテキストをユーザ駆動のシェルから分離する。 +- アプリバンドルの整合性を定期的に検証し、アップデート機構がバンドルリソースを自己修復するようにする。 -**注意**: 最近のmacOSのアップデートにより、Gatekeeperキャッシュ後にアプリバンドル内のファイル変更が防止され、この脆弱性は無効化されました。 + +## HackTricks の関連資料 + +この手法に影響する Gatekeeper、quarantine、provenance の変更について詳しくは: + +{{#ref}} +../macos-security-protections/macos-gatekeeper.md +{{#endref}} + + +## 参考文献 + +- xpn – DirtyNIB（元の解説、Pages の例付き）: https://blog.xpnsec.com/dirtynib/ +- Sector7 – Bringing process injection into view(s): exploiting all macOS apps using nib files (April 5, 2024): https://sector7.computest.nl/post/2024-04-bringing-process-injection-into-view-exploiting-all-macos-apps-using-nib-files/ {{#include ../../../banners/hacktricks-training.md}}