macOS Gatekeeper / Quarantine / XProtect
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Gatekeeper
Gatekeeperは、Macオペレーティングシステム向けに開発されたセキュリティ機能で、ユーザーが信頼できるソフトウェアのみを実行することを保証するために設計されています。これは、ユーザーがApp Store以外のソースからダウンロードして開こうとするソフトウェア（アプリ、プラグイン、インストーラーパッケージなど）を検証することによって機能します。
Gatekeeperの主要なメカニズムは、その検証プロセスにあります。ダウンロードされたソフトウェアが認識された開発者によって署名されているかを確認し、ソフトウェアの真正性を保証します。さらに、ソフトウェアがAppleによって公証されているかを確認し、既知の悪意のあるコンテンツが含まれておらず、公証後に改ざんされていないことを確認します。
加えて、Gatekeeperは、ダウンロードしたソフトウェアを初めて開く際にユーザーに承認を促すことで、ユーザーの制御とセキュリティを強化します。この保護機能は、ユーザーが無害なデータファイルと誤解して実行してしまう可能性のある有害な実行可能コードを誤って実行するのを防ぐのに役立ちます。
Application Signatures
アプリケーション署名、またはコード署名は、Appleのセキュリティインフラストラクチャの重要な要素です。これらは、ソフトウェアの著者（開発者）の身元を確認するために使用され、コードが最後に署名されて以来改ざんされていないことを保証します。
以下はその仕組みです：
アプリケーションの署名： 開発者がアプリケーションを配布する準備が整ったとき、彼らはプライベートキーを使用してアプリケーションに署名します。このプライベートキーは、Apple Developer Programに登録した際にAppleが開発者に発行する証明書に関連付けられています。署名プロセスは、アプリのすべての部分の暗号ハッシュを作成し、このハッシュを開発者のプライベートキーで暗号化することを含みます。
アプリケーションの配布： 署名されたアプリケーションは、開発者の証明書と共にユーザーに配布されます。この証明書には、対応する公開鍵が含まれています。
アプリケーションの検証： ユーザーがアプリケーションをダウンロードして実行しようとすると、彼らのMacオペレーティングシステムは、開発者の証明書から公開鍵を使用してハッシュを復号化します。その後、アプリケーションの現在の状態に基づいてハッシュを再計算し、これを復号化されたハッシュと比較します。一致すれば、アプリケーションは開発者によって署名されて以来変更されていないことを意味し、システムはアプリケーションの実行を許可します。
アプリケーション署名は、AppleのGatekeeper技術の重要な部分です。ユーザーがインターネットからダウンロードしたアプリケーションを開こうとすると、Gatekeeperはアプリケーション署名を検証します。Appleが知られた開発者に発行した証明書で署名されており、コードが改ざんされていない場合、Gatekeeperはアプリケーションの実行を許可します。そうでない場合、アプリケーションをブロックし、ユーザーに警告します。
macOS Catalina以降、GatekeeperはアプリケーションがAppleによって公証されているかどうかも確認します。これにより、セキュリティの追加層が加わります。公証プロセスは、アプリケーションに既知のセキュリティ問題や悪意のあるコードがないかをチェックし、これらのチェックが通過すると、AppleはGatekeeperが検証できるチケットをアプリケーションに追加します。
Check Signatures
いくつかのマルウェアサンプルをチェックする際は、署名を確認することが常に重要です。署名した開発者がすでにマルウェアに関連している可能性があるためです。
Notarization
Appleのノータリゼーションプロセスは、ユーザーを潜在的に有害なソフトウェアから保護するための追加の安全策として機能します。これは、開発者が自分のアプリケーションを Appleのノータリーサービスに審査のために提出することを含み、App Reviewと混同しないでください。このサービスは、自動化されたシステムであり、提出されたソフトウェアに悪意のあるコンテンツやコード署名に関する潜在的な問題がないかを精査します。
ソフトウェアがこの検査を問題なく通過すると、ノータリーサービスはノータリゼーションチケットを生成します。開発者はその後、このチケットを自分のソフトウェアに添付する必要があり、このプロセスは「ステイプル」と呼ばれます。さらに、ノータリゼーションチケットはオンラインでも公開され、Gatekeeper（Appleのセキュリティ技術）がアクセスできるようになります。
ユーザーがソフトウェアを初めてインストールまたは実行する際、ノータリゼーションチケットの存在 - 実行可能ファイルにステイプルされているか、オンラインで見つかるかにかかわらず - Gatekeeperに対してそのソフトウェアがAppleによってノータリゼーションされたことを通知します。その結果、Gatekeeperは初回起動ダイアログに説明的なメッセージを表示し、そのソフトウェアがAppleによって悪意のあるコンテンツのチェックを受けたことを示します。このプロセスにより、ユーザーは自分のシステムにインストールまたは実行するソフトウェアのセキュリティに対する信頼が高まります。
spctl & syspolicyd
Sequoiaバージョンから、**spctl**はもはやGatekeeperの設定を変更することを許可しませんので注意してください。
spctlは、Gatekeeperと対話し、列挙するためのCLIツールです（XPCメッセージを介してsyspolicydデーモンと）。例えば、次のコマンドでGateKeeperのステータスを確認することができます:
GateKeeperの署名チェックは、Quarantine属性を持つファイルに対してのみ実行され、すべてのファイルに対して行われるわけではありません。
GateKeeperは、設定と署名に基づいてバイナリが実行可能かどうかを確認します：
**syspolicyd**は、Gatekeeperを強制するための主要なデーモンです。これは/var/db/SystemPolicyにあるデータベースを維持しており、データベースをサポートするコードはこちらとSQLテンプレートはこちらで見つけることができます。データベースはSIPによって制限されておらず、rootによって書き込み可能で、データベース/var/db/.SystemPolicy-defaultは、他のデータベースが破損した場合の元のバックアップとして使用されます。
さらに、バンドル**/var/db/gke.bundleと/var/db/gkopaque.bundle**には、データベースに挿入されるルールを含むファイルがあります。このデータベースはrootとして次のコマンドで確認できます：
syspolicyd は、assess、update、record、cancel などの異なる操作を持つ XPC サーバーも公開しており、これらは Security.framework の SecAssessment* API を使用してアクセス可能です。また、xpctl は実際に syspolicyd と XPC 経由で通信します。
最初のルールが "App Store" で終わり、2 番目のルールが "Developer ID" で終わることに注意してください。また、前の画像では App Store と認識された開発者からアプリを実行することが有効になっていました。 その設定を App Store に 変更すると、"Notarized Developer ID" ルールは消えます。
type GKE のルールも数千あります：
これらは次の場所からのハッシュです：
/var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gke.auth/var/db/gke.bundle/Contents/Resources/gk.db/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db
または、次のコマンドで前の情報をリストすることができます：
The options --master-disable and --global-disable of spctl will completely 無効にします these signature checks:
完全に有効にすると、新しいオプションが表示されます：
アプリがGateKeeperによって許可されるかどうかを確認することができます：
新しいルールをGateKeeperに追加して、特定のアプリの実行を許可することが可能です：
Regarding kernel extensions, the folder /var/db/SystemPolicyConfiguration contains files with lists of kexts allowed to be loaded. Moreover, spctl has the entitlement com.apple.private.iokit.nvram-csr because it's capable of adding new pre-approved kernel extensions which need to be saved also in NVRAM in a kext-allowed-teams key.
Quarantine Files
Upon downloading an application or file, specific macOS applications such as web browsers or email clients attach an extended file attribute, commonly known as the "quarantine flag," to the downloaded file. This attribute acts as a security measure to mark the file as coming from an untrusted source (the internet), and potentially carrying risks. However, not all applications attach this attribute, for instance, common BitTorrent client software usually bypasses this process.
The presence of a quarantine flag signals macOS's Gatekeeper security feature when a user attempts to execute the file.
In the case where the quarantine flag is not present (as with files downloaded via some BitTorrent clients), Gatekeeper's checks may not be performed. Thus, users should exercise caution when opening files downloaded from less secure or unknown sources.
コード署名の 有効性を確認することは、コードとそのバンドルされたリソースの暗号学的ハッシュを生成することを含むリソース集約的なプロセスです。さらに、証明書の有効性を確認するには、発行後に取り消されていないかを確認するためにAppleのサーバーにオンラインチェックを行う必要があります。このため、アプリが起動するたびに完全なコード署名と公証のチェックを実行することは非現実的です。
したがって、これらのチェックは隔離属性を持つアプリを実行する際にのみ実行されます。
この属性はファイルを作成/ダウンロードするアプリケーションによって設定される必要があります。
ただし、サンドボックス化されたファイルは、作成するすべてのファイルにこの属性が設定されます。サンドボックス化されていないアプリは、自分で設定するか、Info.plistにLSFileQuarantineEnabledキーを指定することで、作成されたファイルにcom.apple.quarantineの拡張属性を設定させることができます。
Moreover, all files created by a process calling qtn_proc_apply_to_self are quarantined. Or the API qtn_file_apply_to_path adds the quarantine attribute to a specified file path.
It's possible to check it's status and enable/disable (root required) with:
ファイルが隔離拡張属性を持っているかどうかを確認することもできます:
拡張属性の値を確認し、次のコマンドで隔離属性を書き込んだアプリを特定します:
実際、プロセスは「作成したファイルに対して隔離フラグを設定できる」（作成したファイルにUSER_APPROVEDフラグを適用しようとしましたが、適用されませんでした）：
ソースコード 隔離フラグを適用
```c #include #include
enum qtn_flags { QTN_FLAG_DOWNLOAD = 0x0001, QTN_FLAG_SANDBOX = 0x0002, QTN_FLAG_HARD = 0x0004, QTN_FLAG_USER_APPROVED = 0x0040, };
#define qtn_proc_alloc _qtn_proc_alloc #define qtn_proc_apply_to_self _qtn_proc_apply_to_self #define qtn_proc_free _qtn_proc_free #define qtn_proc_init _qtn_proc_init #define qtn_proc_init_with_self _qtn_proc_init_with_self #define qtn_proc_set_flags _qtn_proc_set_flags #define qtn_file_alloc _qtn_file_alloc #define qtn_file_init_with_path _qtn_file_init_with_path #define qtn_file_free _qtn_file_free #define qtn_file_apply_to_path _qtn_file_apply_to_path #define qtn_file_set_flags _qtn_file_set_flags #define qtn_file_get_flags _qtn_file_get_flags #define qtn_proc_set_identifier _qtn_proc_set_identifier
typedef struct _qtn_proc *qtn_proc_t; typedef struct _qtn_file *qtn_file_t;
int qtn_proc_apply_to_self(qtn_proc_t); void qtn_proc_init(qtn_proc_t); int qtn_proc_init_with_self(qtn_proc_t); int qtn_proc_set_flags(qtn_proc_t, uint32_t flags); qtn_proc_t qtn_proc_alloc(); void qtn_proc_free(qtn_proc_t); qtn_file_t qtn_file_alloc(void); void qtn_file_free(qtn_file_t qf); int qtn_file_set_flags(qtn_file_t qf, uint32_t flags); uint32_t qtn_file_get_flags(qtn_file_t qf); int qtn_file_apply_to_path(qtn_file_t qf, const char *path); int qtn_file_init_with_path(qtn_file_t qf, const char path); int qtn_proc_set_identifier(qtn_proc_t qp, const char bundleid);
int main() {
qtn_proc_t qp = qtn_proc_alloc(); qtn_proc_set_identifier(qp, "xyz.hacktricks.qa"); qtn_proc_set_flags(qp, QTN_FLAG_DOWNLOAD | QTN_FLAG_USER_APPROVED); qtn_proc_apply_to_self(qp); qtn_proc_free(qp);
FILE *fp; fp = fopen("thisisquarantined.txt", "w+"); fprintf(fp, "Hello Quarantine\n"); fclose(fp);
return 0;
}
そして、次のコマンドで隔離されたファイルをすべて見つけます：
隔離情報は、~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 にあるLaunchServicesによって管理される中央データベースに保存されており、GUIがファイルの起源に関するデータを取得できるようにします。さらに、これは起源を隠そうとするアプリケーションによって上書きされる可能性があります。さらに、これはLaunchServices APIから行うことができます。
libquarantine.dylb
このライブラリは、拡張属性フィールドを操作するためのいくつかの関数をエクスポートします。
qtn_file_* APIはファイルの隔離ポリシーを扱い、qtn_proc_* APIはプロセス（プロセスによって作成されたファイル）に適用されます。エクスポートされていない__qtn_syscall_quarantine*関数は、ポリシーを適用するもので、最初の引数として「Quarantine」を指定してmac_syscallを呼び出し、Quarantine.kextにリクエストを送信します。
Quarantine.kext
カーネル拡張は、システムのカーネルキャッシュを通じてのみ利用可能ですが、Kernel Debug Kitを https://developer.apple.com/ からダウンロードすることができ、拡張のシンボリケートされたバージョンが含まれています。
このKextは、MACFを介していくつかの呼び出しをフックし、すべてのファイルライフサイクルイベントをトラップします：作成、オープン、リネーム、ハードリンク... さらにはsetxattrを使用してcom.apple.quarantine拡張属性の設定を防ぎます。
いくつかのMIBも使用します：
security.mac.qtn.sandbox_enforce: サンドボックスに沿った隔離を強制security.mac.qtn.user_approved_exec: 隔離されたプロセスは承認されたファイルのみを実行可能
XProtect
XProtectはmacOSに組み込まれたアンチマルウェア機能です。XProtectは、アプリケーションが初めて起動または変更されたときに、既知のマルウェアおよび安全でないファイルタイプのデータベースに対してチェックを行います。Safari、Mail、Messagesなどの特定のアプリを通じてファイルをダウンロードすると、XProtectは自動的にファイルをスキャンします。ファイルがデータベース内の既知のマルウェアと一致する場合、XProtectはファイルの実行を防ぎ、脅威を警告します。
XProtectデータベースは、Appleによって定期的に更新され、新しいマルウェア定義が追加されます。これらの更新は自動的にダウンロードされ、Macにインストールされます。これにより、XProtectは常に最新の既知の脅威に対して最新の状態を保ちます。
ただし、XProtectはフル機能のアンチウイルスソリューションではないことに注意する価値があります。特定の既知の脅威のリストのみをチェックし、ほとんどのアンチウイルスソフトウェアのようにオンアクセススキャンを実行しません。
最新のXProtect更新に関する情報を取得するには、次のコマンドを実行します：
XProtectは、/Library/Apple/System/Library/CoreServices/XProtect.bundleのSIP保護された場所にあり、バンドル内にはXProtectが使用する情報があります：
XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist: これらのcdhashesを持つコードがレガシー権限を使用することを許可します。XProtect.bundle/Contents/Resources/XProtect.meta.plist: BundleIDおよびTeamIDを介して読み込むことが禁止されているプラグインと拡張機能のリスト、または最小バージョンを示します。XProtect.bundle/Contents/Resources/XProtect.yara: マルウェアを検出するためのYaraルール。XProtect.bundle/Contents/Resources/gk.db: ブロックされたアプリケーションとTeamIDのハッシュを含むSQLite3データベース。
**/Library/Apple/System/Library/CoreServices/XProtect.app**には、Gatekeeperプロセスに関与しないXProtectに関連する別のアプリがあります。
Not Gatekeeper
Gatekeeperは、アプリケーションを実行するたびに実行されるわけではありません。実際には、AppleMobileFileIntegrity (AMFI)は、Gatekeeperによってすでに実行され、検証されたアプリを実行する際にのみ実行可能コードの署名を検証します。
したがって、以前はアプリを実行してGatekeeperでキャッシュし、その後アプリケーションの実行可能でないファイルを変更する（ElectronのasarやNIBファイルなど）ことが可能でしたが、他の保護がなければ、アプリケーションは悪意のある追加とともに実行されました。
しかし、現在はmacOSがアプリケーションバンドル内のファイルの変更を防ぐため、これは不可能です。したがって、Dirty NIB攻撃を試みると、Gatekeeperでキャッシュするためにアプリを実行した後、バンドルを変更できなくなるため、もはや悪用できないことがわかります。たとえば、Contentsディレクトリの名前をNotConに変更し（エクスプロイトで示されているように）、その後アプリのメインバイナリを実行してGatekeeperでキャッシュしようとすると、エラーが発生し、実行されません。
Gatekeeper Bypasses
Gatekeeperをバイパスする方法（ユーザーに何かをダウンロードさせ、Gatekeeperがそれを拒否すべきときに実行させること）は、macOSの脆弱性と見なされます。以下は、過去にGatekeeperをバイパスすることを可能にした技術に割り当てられたCVEのいくつかです：
Archive Utilityを使用して抽出すると、886文字を超えるパスを持つファイルがcom.apple.quarantine拡張属性を受け取らないことが観察されました。この状況は、意図せずにこれらのファイルがGatekeeperのセキュリティチェックを回避することを可能にします。
詳細については、元の報告を確認してください。
Automatorで作成されたアプリケーションでは、実行に必要な情報がapplication.app/Contents/document.wflow内にあり、実行可能ファイルにはありません。実行可能ファイルは、Automator Application Stubと呼ばれる一般的なAutomatorバイナリです。
したがって、application.app/Contents/MacOS/Automator\ Application\ Stubをシンボリックリンクでシステム内の別のAutomator Application Stubにポイントさせることができ、document.wflow（あなたのスクリプト）内の内容をGatekeeperをトリガーせずに実行します。実際の実行可能ファイルにはquarantine xattrがないためです。
期待される場所の例：/System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub
詳細については、元の報告を確認してください。
このバイパスでは、application.app/Contentsから圧縮を開始するアプリケーションを含むzipファイルが作成されました。したがって、quarantine attrは**application.app/Contentsのすべてのファイルに適用されましたが、application.appには適用されませんでした。これがGatekeeperがチェックしていたものであり、application.appがトリガーされたときにquarantine属性を持っていなかったため、Gatekeeperはバイパスされました。
Check the original report for more information.
コンポーネントが異なっていても、この脆弱性の悪用は前のものと非常に似ています。この場合、application.app/Contents からApple Archiveを生成するので、application.app はArchive Utilityによって解凍されたときに隔離属性を取得しません。
Check the original report for more information.
ACL writeextattr は、ファイルに属性を書き込むことを誰からも防ぐために使用できます：
さらに、AppleDoubleファイル形式は、ファイルをそのACEを含めてコピーします。
ソースコードでは、com.apple.acl.textというxattr内に保存されたACLのテキスト表現が、解凍されたファイルのACLとして設定されることがわかります。したがって、他のxattrsが書き込まれるのを防ぐACLを持つアプリケーションをAppleDoubleファイル形式でzipファイルに圧縮した場合... 検疫xattrはアプリケーションに設定されませんでした：
オリジナルレポートをチェックして、詳細情報を確認してください。
これがAppleArchivesでも悪用される可能性があることに注意してください:
Google Chromeがダウンロードしたファイルにクアランティン属性を設定していなかったことが、macOSの内部問題によって発見されました。
AppleDoubleファイル形式は、ファイルの属性を._で始まる別のファイルに保存します。これにより、macOSマシン間でファイル属性をコピーすることができます。しかし、AppleDoubleファイルを解凍した後、._で始まるファイルにクアランティン属性が与えられなかったことが確認されました。
ファイルを作成できることで、Gatekeeperをバイパスすることが可能でした。 トリックは、AppleDouble名付け規則を使用してDMGファイルアプリケーションを作成することでした（._で始める）そして、この隠しファイルへのシンボリックリンクとして可視ファイルを作成することです。
dmgファイルが実行されると、それにはクアランティン属性がないため、Gatekeeperをバイパスします。
uchg (from this talk)
アプリを含むディレクトリを作成します。
アプリにuchgを追加します。
アプリをtar.gzファイルに圧縮します。
tar.gzファイルを被害者に送信します。
被害者はtar.gzファイルを開き、アプリを実行します。
Gatekeeperはアプリをチェックしません。
Quarantine xattrの防止
".app"バンドルにquarantine xattrが追加されていない場合、実行時にGatekeeperはトリガーされません。
