macOS TCC Bypasses
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)
これはバイパスではなく、TCCの動作方法です：書き込みから保護されていません。ターミナルがユーザーのデスクトップを読み取るアクセス権を持っていなくても、そこに書き込むことができます：
The extended attribute com.apple.macl は新しい file に追加され、creators app がそれを読み取るアクセスを得るためのものです。
TCCプロンプトの上にウィンドウを置く ことで、ユーザーがそれを 受け入れる ようにすることが可能です。PoCは TCC-ClickJacking** で見つけることができます。**
攻撃者は 任意の名前 (例: Finder, Google Chrome...) のアプリを Info.plist に作成し、TCCで保護された場所へのアクセスを要求させることができます。ユーザーは、正当なアプリケーションがこのアクセスを要求していると思うでしょう。
さらに、正当なアプリをDockから削除し、偽のアプリをその上に置く ことが可能です。ユーザーが偽のアプリ（同じアイコンを使用できる）をクリックすると、正当なアプリを呼び出し、TCCの権限を要求し、マルウェアを実行させることができ、ユーザーは正当なアプリがアクセスを要求したと信じることになります。
詳細情報とPoCは以下にあります：
デフォルトでは、SSH経由のアクセスは「フルディスクアクセス」を持っていました。これを無効にするには、リストに載せておく必要がありますが、無効にすること（リストから削除すること）はその権限を取り除くことにはなりません：
ここでは、いくつかの マルウェアがこの保護を回避できた例 を見つけることができます：
現在、SSHを有効にするには フルディスクアクセス が必要です。
属性 com.apple.macl はファイルに与えられ、特定のアプリケーションにそれを読む権限を与えます。 この属性は、ドラッグ＆ドロップ でファイルをアプリに移動したとき、またはユーザーが ダブルクリック して デフォルトアプリケーション でファイルを開くときに設定されます。
したがって、ユーザーは 悪意のあるアプリを登録 してすべての拡張子を処理させ、Launch Servicesを呼び出して 任意のファイルを開く ことができます（そのため、悪意のあるファイルはそれを読むアクセスを得ることになります）。
権限 com.apple.private.icloud-account-access により、com.apple.iCloudHelper XPCサービスと通信することが可能で、iCloudトークン を提供します。
iMovie と Garageband はこの権限を持っており、他のアプリも許可されていました。
この権限から iCloudトークンを取得するためのエクスプロイト に関する詳細情報は、トークをチェックしてください: #OBTS v5.0: "What Happens on your Mac, Stays on Apple's iCloud?!" - Wojciech Regula
kTCCServiceAppleEvents 権限を持つアプリは、他のアプリを制御する ことができます。これは、他のアプリに付与された権限を 悪用する 可能性があることを意味します。
Apple Scriptsに関する詳細情報は以下を確認してください：
例えば、アプリが iTerm に対して Automation権限 を持っている場合、この例では Terminal がiTermにアクセスしています：
FDAを持たないTerminalは、iTermを呼び出し、それを使用してアクションを実行できます：
または、アプリがFinderにアクセスできる場合、次のようなスクリプトを使用できます:
ユーザーランドの tccd デーモン は HOME env 変数を使用して、TCC ユーザーデータベースにアクセスしています: $HOME/Library/Application Support/com.apple.TCC/TCC.db
この Stack Exchange の投稿 によると、TCC デーモンは現在のユーザーのドメイン内で launchd を介して実行されているため、すべての環境変数を制御することが可能です。
したがって、攻撃者は $HOME 環境 変数を launchctl で 制御された ディレクトリを指すように設定し、TCC デーモンを再起動し、その後 TCC データベースを直接変更して、エンドユーザーにプロンプトを表示することなく すべての TCC 権限を取得することができます。
PoC:
ノートはTCC保護された場所にアクセスできましたが、ノートが作成されると、これは保護されていない場所に作成されます。したがって、ノートに保護されたファイルをノートにコピーするように依頼し（つまり、保護されていない場所に）、そのファイルにアクセスすることができます：
バイナリ/usr/libexec/lsdは、ライブラリlibsecurity_translocateを持ち、com.apple.private.nullfs_allowという権限があり、nullfsマウントを作成でき、**kTCCServiceSystemPolicyAllFiles**を持つcom.apple.private.tcc.allowの権限があり、すべてのファイルにアクセスできました。
「Library」にクアランティン属性を追加し、com.apple.security.translocation XPCサービスを呼び出すことが可能で、その後、Libraryは**$TMPDIR/AppTranslocation/d/d/Libraryにマッピングされ、Library内のすべてのドキュメントにアクセス**できました。
Musicには興味深い機能があります：実行中に、~/Music/Music/Media.localized/Automatically Add to Music.localizedにドロップされたファイルをユーザーの「メディアライブラリ」にインポートします。さらに、次のような呼び出しを行います：rename(a, b); ここで、aとbは：
a = "~/Music/Music/Media.localized/Automatically Add to Music.localized/myfile.mp3"
b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3
この**rename(a, b);の動作はレースコンディションに脆弱であり、Automatically Add to Music.localizedフォルダ内に偽のTCC.dbファイルを置き、新しいフォルダ(b)が作成されるときにファイルをコピーし、それを削除し、~/Library/Application Support/com.apple.TCC**にポイントすることが可能です。
SQLITE_SQLLOG_DIR="path/folder"は基本的に開いている任意のデータベースがそのパスにコピーされることを意味します。このCVEでは、この制御が悪用され、SQLiteデータベース内に書き込まれ、そのデータベースがTCCデータベースを持つプロセスによって開かれることになり、SQLITE_SQLLOG_DIRがファイル名にシンボリックリンクを使用して悪用されるため、そのデータベースが開かれると、ユーザーのTCC.dbが上書きされます。
詳細情報 こちらの解説 および こちらのトーク。
環境変数**SQLITE_AUTO_TRACEが設定されている場合、ライブラリlibsqlite3.dylibはすべてのSQLクエリをログ**記録し始めます。多くのアプリケーションがこのライブラリを使用していたため、すべてのSQLiteクエリをログに記録することが可能でした。
いくつかのAppleアプリケーションは、このライブラリを使用してTCC保護情報にアクセスしていました。
このenv変数はMetalフレームワークによって使用され、これは様々なプログラムの依存関係であり、特にMusicがFDAを持っています。
次のように設定します: MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name"。pathが有効なディレクトリであれば、バグがトリガーされ、fs_usageを使用してプログラム内で何が起こっているかを見ることができます：
path/.dat.nosyncXXXX.XXXXXX（Xはランダム）という名前のファイルがopen()されます
1つ以上のwrite()がファイルに内容を書き込みます（これを制御することはできません）
path/.dat.nosyncXXXX.XXXXXXがpath/nameにrenamed()されます
これは一時ファイルの書き込みであり、その後に**rename(old, new)が安全ではありません。**
安全ではない理由は、古いパスと新しいパスを別々に解決する必要があるため、これには時間がかかる可能性があり、レースコンディションに対して脆弱です。詳細については、xnu関数renameat_internal()を確認できます。
基本的に、特権プロセスがあなたが制御するフォルダから名前を変更している場合、RCEを獲得し、特権アプリが作成したファイルにアクセスさせたり、このCVEのようにファイルディスクリプタを保存させたりすることができます。
名前変更があなたが制御するフォルダにアクセスする場合、ソースファイルを変更したり、そのファイルにFDを持っている間に、宛先ファイル（またはフォルダ）をシンボリックリンクを指すように変更することで、いつでも書き込むことができます。
これがCVEでの攻撃でした：例えば、ユーザーのTCC.dbを上書きするために、次のことができます：
/Users/hacker/ourlinkを作成して/Users/hacker/Library/Application Support/com.apple.TCC/を指すようにします
ディレクトリ/Users/hacker/tmp/を作成します
MTL_DUMP_PIPELINES_TO_JSON_FILE=/Users/hacker/tmp/TCC.dbを設定します
このenv変数でMusicを実行してバグをトリガーします
/Users/hacker/tmp/.dat.nosyncXXXX.XXXXXXのopen()をキャッチします（Xはランダム）
ここでこのファイルをopen()して書き込み用に保持します
/Users/hacker/tmpを/Users/hacker/ourlinkとループ内で原子的に切り替えます
レースウィンドウが非常に狭いため、成功の可能性を最大化するためにこれを行いますが、レースに負けることのデメリットはほとんどありません
少し待ちます
運が良かったかテストします
そうでなければ、最初から再実行します
詳細はhttps://gergelykalman.com/lateralus-CVE-2023-32407-a-macos-tcc-bypass.htmlで確認できます。
今、env変数MTL_DUMP_PIPELINES_TO_JSON_FILEを使用しようとすると、アプリは起動しません
rootとしてこのサービスを有効にすると、ARDエージェントはフルディスクアクセスを持ち、これを悪用してユーザーが新しいTCCユーザーデータベースをコピーさせることができます。
TCCはユーザーのHOMEフォルダ内にあるデータベースを使用して、ユーザーに特有のリソースへのアクセスを制御します**$HOME/Library/Application Support/com.apple.TCC/TCC.db**。 したがって、ユーザーが$HOME env変数を異なるフォルダを指すように再起動できれば、ユーザーは**/Library/Application Support/com.apple.TCC/TCC.db**に新しいTCCデータベースを作成し、TCCを騙して任意のアプリに任意のTCC権限を付与させることができます。
Appleは、NFSHomeDirectory属性内のユーザープロファイルに保存された設定を$HOMEの値として使用しているため、この値を変更する権限を持つアプリケーションを侵害すると、TCCバイパスを使用してこのオプションを武器化できます。
最初のPOCはdsexportとdsimportを使用してユーザーのHOMEフォルダを変更します。
対象アプリの_csreq_ブロブを取得します。
必要なアクセス権と_csreq_ブロブを持つ偽の_TCC.db_ファイルを植え付けます。
dsexportを使用してユーザーのディレクトリサービスエントリをエクスポートします。
ユーザーのホームディレクトリを変更するためにディレクトリサービスエントリを修正します。
dsimportを使用して修正されたディレクトリサービスエントリをインポートします。
ユーザーの_tccd_を停止し、プロセスを再起動します。
2番目のPOCは、/usr/libexec/configdを使用し、com.apple.private.tcc.allowにkTCCServiceSystemPolicySysAdminFilesの値がありました。
-tオプションでconfigdを実行することが可能で、攻撃者はカスタムバンドルをロードすることができました。したがって、エクスプロイトはユーザーのホームディレクトリを変更するための**dsexportおよびdsimportメソッドをconfigdコードインジェクション**に置き換えます。
詳細については、元の報告を確認してください。
プロセス内にコードを注入し、そのTCC権限を悪用するための異なる技術があります：
さらに、TCCをバイパスするために見つかった最も一般的なプロセスインジェクションは**プラグイン（ライブラリをロード）**を介しています。 プラグインは通常、ライブラリやplistの形で追加のコードであり、メインアプリケーションによってロードされ、そのコンテキストで実行されます。したがって、メインアプリケーションがTCC制限ファイルへのアクセス権を持っている場合（付与された権限または権利によって）、カスタムコードもそれを持つことになります。
アプリケーション/System/Library/CoreServices/Applications/Directory Utility.appは権限**kTCCServiceSystemPolicySysAdminFilesを持ち、.daplug**拡張子のプラグインをロードし、ハードンされたランタイムを持っていませんでした。
このCVEを武器化するために、NFSHomeDirectoryが変更され（前述の権限を悪用して）、ユーザーのTCCデータベースを引き継ぐことができるようにします。
詳細については、元の報告を確認してください。
バイナリ**/usr/sbin/coreaudiodは権限com.apple.security.cs.disable-library-validationとcom.apple.private.tcc.managerを持っていました。最初のものはコードインジェクションを許可し、2番目はTCCを管理する**アクセスを与えました。
このバイナリは、フォルダ/Library/Audio/Plug-Ins/HALからサードパーティプラグインをロードすることを許可しました。したがって、次のPoCを使用してプラグインをロードし、TCC権限を悪用することが可能でした：
For more info check the original report.
Core Media I/O を介してカメラストリームを開くシステムアプリケーション（kTCCServiceCamera を持つアプリ）は、/Library/CoreMediaIO/Plug-Ins/DAL にある これらのプラグインをプロセス内で読み込みます（SIP 制限なし）。
そこに一般的な コンストラクタ を持つライブラリを保存するだけで コードを注入 することができます。
いくつかの Apple アプリケーションがこれに対して脆弱でした。
Firefox アプリケーションは com.apple.security.cs.disable-library-validation と com.apple.security.cs.allow-dyld-environment-variables の権限を持っていました：
Fore more info about how to easily exploit this check the original report.
バイナリ /system/Library/Filesystems/acfs.fs/Contents/bin/xsanctl は com.apple.private.tcc.allow と com.apple.security.get-task-allow の権限を持っており、プロセス内にコードを注入し、TCCの権限を使用することが可能でした。
Telegram は com.apple.security.cs.allow-dyld-environment-variables と com.apple.security.cs.disable-library-validation の権限を持っていたため、カメラでの録画などの権限にアクセスするために悪用することが可能でした。ペイロードはwriteupで見つけることができます。
環境変数を使用してライブラリをロードする方法に注意してください。カスタムplistが作成され、このライブラリを注入するために**launchctl**が使用されました：
サンドボックス化されていても**open**を呼び出すことが可能です。
技術者が使用するコンピュータでは、ターミナルに**フルディスクアクセス (FDA)を与えることが一般的です。そして、それを使用して.terminal**スクリプトを呼び出すことが可能です。
**.terminalスクリプトは、CommandString**キーに実行するコマンドを含むplistファイルです：
アプリケーションは、/tmp のような場所にターミナルスクリプトを書き込み、次のようなコマンドで起動することができます:
任意のユーザー（特権のないユーザーも含む）は、タイムマシンのスナップショットを作成してマウントし、そのスナップショットのすべてのファイルにアクセスできます。
必要な唯一の特権は、使用するアプリケーション（Terminalなど）がフルディスクアクセス（FDA）アクセス（kTCCServiceSystemPolicyAllfiles）を持つことであり、これは管理者によって付与される必要があります。
より詳細な説明は元のレポートで見つけることができます。
TCC DBファイルが保護されていても、新しいTCC.dbファイルをディレクトリの上にマウントすることが可能でした：
Check the full exploit in the original writeup.
ツール /usr/sbin/asr は、TCC保護を回避してディスク全体をコピーし、別の場所にマウントすることを可能にしました。
/var/db/locationd/clients.plist に第三のTCCデータベースがあり、位置情報サービスにアクセスすることを許可されたクライアントを示します。
フォルダー /var/db/locationd/ はDMGマウントから保護されていなかったため、自分のplistをマウントすることが可能でした。
いくつかの場面で、ファイルはメール、電話番号、メッセージなどの機密情報を保護されていない場所に保存します（これはAppleの脆弱性と見なされます）。
これはもう機能しませんが、過去には機能していました:
別の方法としてCoreGraphicsイベントを使用します：
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
