macOS Launch/Environment Constraints & Trust Cache
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
macOSの起動制約は、プロセスがどのように、誰が、どこから開始できるかを規制することによってセキュリティを強化するために導入されました。macOS Venturaで開始され、各システムバイナリを異なる制約カテゴリに分類するフレームワークを提供します。これらは、システムバイナリとそのハッシュを含むリストである信頼キャッシュ内に定義されています。これらの制約は、システム内のすべての実行可能バイナリに拡張され、特定のバイナリを起動するための要件を定義する一連のルール**を含みます。ルールには、バイナリが満たすべき自己制約、親プロセスが満たすべき親制約、関連する他のエンティティが遵守すべき責任制約が含まれます。
このメカニズムは、macOS Sonoma以降、環境制約を通じてサードパーティアプリにも拡張され、開発者が環境制約のためのキーと値のセットを指定することによってアプリを保護できるようにします。
起動環境およびライブラリ制約は、launchd
プロパティリストファイルに保存するか、コード署名で使用する別のプロパティリストファイルに保存する制約辞書で定義します。
制約には4つのタイプがあります:
自己制約:実行中のバイナリに適用される制約。
親プロセス:プロセスの親に適用される制約(例えば、**launchd
**がXPサービスを実行している場合)。
責任制約:XPC通信でサービスを呼び出すプロセスに適用される制約。
ライブラリロード制約:ロードできるコードを選択的に記述するためにライブラリロード制約を使用します。
したがって、プロセスが別のプロセスを起動しようとするとき — execve(_:_:_:)
またはposix_spawn(_:_:_:_:_:_:)
を呼び出すことによって — オペレーティングシステムは、実行可能ファイルが自身の自己制約を満たしているかどうかを確認します。また、親プロセスの実行可能ファイルが実行可能ファイの親制約を満たしているかどうか、および責任プロセスの実行可能ファイルが実行可能ファイルの責任プロセス制約を満たしているかどうかも確認します。これらの起動制約のいずれかが満たされない場合、オペレーティングシステムはプログラムを実行しません。
ライブラリをロードする際にライブラリ制約の一部が真でない場合、プロセスはライブラリをロードしません。
LCは、事実と論理演算(and、or..)で構成され、事実を組み合わせます。
LCが使用できる事実は文書化されています。例えば:
is-init-proc:実行可能ファイルがオペレーティングシステムの初期化プロセス(launchd
)である必要があるかどうかを示すブール値。
is-sip-protected:実行可能ファイルがシステム整合性保護(SIP)によって保護されているファイルである必要があるかどうかを示すブール値。
on-authorized-authapfs-volume:
オペレーティングシステムが認可された、認証されたAPFSボリュームから実行可能ファイルをロードしたかどうかを示すブール値。
on-authorized-authapfs-volume
:オペレーティングシステムが認可された、認証されたAPFSボリュームから実行可能ファイルをロードしたかどうかを示すブール値。
Cryptexesボリューム
on-system-volume:
オペレーティングシステムが現在起動しているシステムボリュームから実行可能ファイルをロードしたかどうかを示すブール値。
/System内...
...
Appleのバイナリが署名されると、それは信頼キャッシュ内のLCカテゴリに割り当てられます。
iOS 16 LCカテゴリはここで逆引きされ、文書化されています。
現在の**LCカテゴリ(macOS 14 - Sonoma)**は逆引きされ、その説明はここにあります。
例えば、カテゴリ1は:
(on-authorized-authapfs-volume || on-system-volume)
: システムまたはCryptexesボリューム内である必要があります。
launch-type == 1
: システムサービスである必要があります(LaunchDaemons内のplist)。
validation-category == 1
: オペレーティングシステムの実行可能ファイル。
is-init-proc
: Launchd
詳細についてはこちらにありますが、基本的には、これらはAMFI (AppleMobileFileIntegrity)で定義されているため、KEXTを取得するにはカーネル開発キットをダウンロードする必要があります。kConstraintCategory
で始まるシンボルが興味深いものです。これらを抽出すると、DER (ASN.1) エンコードされたストリームが得られ、ASN.1 Decoderまたはpython-asn1ライブラリとそのdump.py
スクリプト、andrivet/python-asn1を使用してデコードする必要があります。これにより、より理解しやすい文字列が得られます。
これらはサードパーティアプリケーションで設定されたLaunch Constraintsです。開発者は、アプリケーション内で使用する事実と論理演算子を選択して、自身へのアクセスを制限できます。
アプリケーションの環境制約を列挙することが可能です:
macOS にはいくつかの信頼キャッシュがあります:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
iOS では /usr/standalone/firmware/FUD/StaticTrustCache.img4
にあるようです。
Apple Silicon デバイス上の macOS では、Apple 署名のバイナリが信頼キャッシュにない場合、AMFI はそれを読み込むことを拒否します。
前述の信頼キャッシュファイルは IMG4 および IM4P 形式であり、IM4P は IMG4 形式のペイロードセクションです。
データベースのペイロードを抽出するには、pyimg4 を使用できます:
(別のオプションは、ツール img4tool を使用することで、リリースが古くてもM1で実行でき、適切な場所にインストールすればx86_64でも実行できます)。
今、ツール trustcache を使用して、情報を読みやすい形式で取得できます:
信頼キャッシュは以下の構造に従いますので、LCカテゴリは4番目の列です
Then, you could use a script such as this one to extract data.
From that data you can check the Apps with a launch constraints value of 0
, which are the ones that aren't constrained (check here for what each value is).
Launch Constrainsは、プロセスが予期しない条件で実行されないことを確認することによって、いくつかの古い攻撃を緩和しました: たとえば、予期しない場所からの実行や、予期しない親プロセスによって呼び出されること(launchdのみが起動するべき場合)です。
さらに、Launch Constraintsはダウングレード攻撃も緩和します。
しかし、彼らは一般的なXPCの悪用、Electronコードの注入、またはライブラリ検証なしのdylib注入を緩和しません(ライブラリをロードできるチームIDが知られていない限り)。
Sonomaリリースでは、デーモンXPCサービスの責任構成が注目されるポイントです。XPCサービスは自分自身に対して責任を持ち、接続クライアントが責任を持つのではありません。これはフィードバックレポートFB13206884に文書化されています。この設定は欠陥があるように見えるかもしれませんが、特定のXPCサービスとの相互作用を許可します:
XPCサービスの起動:バグと見なされる場合、この設定は攻撃者のコードを通じてXPCサービスを起動することを許可しません。
アクティブサービスへの接続:XPCサービスがすでに実行中である場合(元のアプリケーションによって起動された可能性があります)、接続するための障壁はありません。
XPCサービスに制約を実装することは、**潜在的な攻撃のウィンドウを狭めることによって有益かもしれませんが、**主な懸念には対処していません。XPCサービスのセキュリティを確保するためには、接続クライアントを効果的に検証することが根本的に必要です。 これがサービスのセキュリティを強化する唯一の方法です。また、言及された責任構成は現在機能していることに注意する価値がありますが、意図された設計とは一致しないかもしれません。
アプリケーションがLaunchServiceによって開かれる必要がある場合(親の制約内)。これは、open
を使用することで達成できます(環境変数を設定できます)またはLaunch Services APIを使用することで達成できます(環境変数を指定できます)。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)