macOS xpc_connection_get_audit_token 攻撃

Reading time: 17 minutes

詳細については元の投稿を確認してください: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/。これは要約です：

Mach メッセージの基本情報

Mach メッセージが何か知らない場合は、このページを確認してください：

macOS IPC - Inter Process Communication

現時点では、(こちらの定義)を覚えておいてください：
Mach メッセージは mach ポート を介して送信され、これは mach カーネルに組み込まれた 単一受信者、複数送信者通信 チャンネルです。複数のプロセスがメッセージを送信できますが、いつでも 単一のプロセスのみがそれを読み取ることができます。ファイルディスクリプタやソケットと同様に、mach ポートはカーネルによって割り当てられ、管理され、プロセスは整数を見て、それを使用してカーネルにどの mach ポートを使用したいかを示します。

XPC 接続

XPC 接続がどのように確立されるか知らない場合は、確認してください：

macOS XPC

脆弱性の概要

知っておくべき興味深い点は、**XPC の抽象化は一対一の接続ですが、**複数の送信者を持つ技術の上に構築されているため、以下のようになります：

• Mach ポートは単一受信者、複数送信者です。
• XPC 接続の監査トークンは、最近受信したメッセージからコピーされた監査トークンです。
• XPC 接続の 監査トークン を取得することは、多くの セキュリティチェック にとって重要です。

前述の状況は有望に聞こえますが、これが問題を引き起こさないシナリオもいくつかあります（こちらから）：

• 監査トークンは、接続を受け入れるかどうかを決定するための認証チェックにしばしば使用されます。これはサービスポートへのメッセージを使用して行われるため、接続はまだ確立されていません。このポートへの追加のメッセージは、単に追加の接続要求として処理されます。したがって、接続を受け入れる前の チェックは脆弱ではありません（これは -listener:shouldAcceptNewConnection: 内で監査トークンが安全であることも意味します）。したがって、私たちは 特定のアクションを検証する XPC 接続を探しています。
• XPC イベントハンドラは同期的に処理されます。これは、1 つのメッセージのイベントハンドラが完了する前に次のメッセージのために呼び出される必要があることを意味します。したがって、XPC イベントハンドラ内では監査トークンは他の通常の（非応答！）メッセージによって上書きされることはありません。

この脆弱性を悪用できる 2 つの異なる方法があります：

1. バリアント 1:

• 攻撃はサービス A とサービス B に 接続します。
• サービス B は、ユーザーができないサービス A の 特権機能 を呼び出すことができます。
• サービス A は、dispatch_async の イベントハンドラ内ではなく、xpc_connection_get_audit_token を呼び出します。
• したがって、異なる メッセージが 監査トークンを上書き する可能性があります。なぜなら、それはイベントハンドラの外で非同期にディスパッチされているからです。
• 攻撃は サービス B にサービス A への送信権を渡します。
• したがって、svc B は実際にサービス A に メッセージを送信します。
• 攻撃は 特権アクションを呼び出そうとします。RC で svc A はこの アクションの 認証を チェック し、svc B が監査トークンを上書きしました（攻撃に特権アクションを呼び出すアクセスを与えます）。

2. バリアント 2:

• サービス B は、ユーザーができないサービス A の 特権機能 を呼び出すことができます。
• 攻撃は サービス A に接続し、サービス A は攻撃に 応答を期待するメッセージ を送信します。特定の 応答 ポート で。
• 攻撃は サービス B に その応答ポート を渡すメッセージを送信します。
• サービス B が応答すると、サービス A にメッセージを 送信し、攻撃 は異なる メッセージをサービス A に送信し、特権機能に 到達しようとし、サービス B からの応答が監査トークンを完璧なタイミングで上書きすることを期待します（競合条件）。

バリアント 1: イベントハンドラの外で xpc_connection_get_audit_token を呼び出す

シナリオ：

• 接続できる 2 つの mach サービス A と B（サンドボックスプロファイルと接続を受け入れる前の認証チェックに基づく）。
• A は、B が渡すことができる特定のアクションの 認証チェック を持っている必要があります（しかし、私たちのアプリはできません）。
• たとえば、B がいくつかの 権限 を持っているか、root として実行されている場合、A に特権アクションを実行するように要求できるかもしれません。
• この認証チェックのために、A は非同期的に監査トークンを取得します。たとえば、dispatch_async から xpc_connection_get_audit_token を呼び出すことによって。

これは A が smd として、B が diagnosticd として発生しました。関数 SMJobBless は、新しい特権ヘルパーツールをインストールするために使用できます（root として）。root として実行されているプロセスが smd に接触すると、他のチェックは実行されません。

したがって、サービス B は diagnosticd であり、root として実行され、プロセスを 監視 するために使用できます。監視が開始されると、毎秒複数のメッセージを送信します。

攻撃を実行するには：

1. 標準 XPC プロトコルを使用して smd という名前のサービスに 接続 を開始します。
2. diagnosticd に二次的な 接続 を形成します。通常の手順とは異なり、2 つの新しい mach ポートを作成して送信するのではなく、クライアントポートの送信権が smd 接続に関連付けられた 送信権 の複製に置き換えられます。
3. 結果として、XPC メッセージは diagnosticd にディスパッチできますが、diagnosticd からの応答は smd にリダイレクトされます。smd にとっては、ユーザーと diagnosticd の両方からのメッセージが同じ接続から発信されているように見えます。

4. 次のステップは、diagnosticd に選択したプロセス（ユーザー自身のプロセスの可能性があります）の監視を開始するように指示することです。同時に、smd に対して通常の 1004 メッセージの洪水が送信されます。ここでの意図は、特権のあるツールをインストールすることです。
5. このアクションは、handle_bless 関数内で競合条件を引き起こします。タイミングが重要です：xpc_connection_get_pid 関数呼び出しは、ユーザーのプロセスの PID を返さなければなりません（特権ツールはユーザーのアプリバンドルに存在します）。ただし、xpc_connection_get_audit_token 関数は、特に connection_is_authorized サブルーチン内で、diagnosticd に属する監査トークンを参照する必要があります。

バリアント 2: 応答の転送

XPC（プロセス間通信）環境では、イベントハンドラは同時に実行されませんが、応答メッセージの処理には独自の動作があります。具体的には、応答を期待するメッセージを送信するための 2 つの異なる方法があります：

1. xpc_connection_send_message_with_reply: ここでは、XPC メッセージが受信され、指定されたキューで処理されます。
2. xpc_connection_send_message_with_reply_sync: 逆に、この方法では、XPC メッセージが現在のディスパッチキューで受信され、処理されます。

この区別は重要です。なぜなら、応答パケットが XPC イベントハンドラの実行と同時に解析される可能性があるからです。特に、_xpc_connection_set_creds は監査トークンの部分的な上書きを防ぐためにロックを実装していますが、接続オブジェクト全体に対してこの保護を拡張していません。したがって、パケットの解析とそのイベントハンドラの実行の間の間隔で監査トークンが置き換えられる脆弱性が生じます。

この脆弱性を悪用するには、次のセットアップが必要です：

• A と B と呼ばれる 2 つの mach サービスで、どちらも接続を確立できます。
• サービス A は、B のみが実行できる特定のアクションのための認証チェックを含む必要があります（ユーザーのアプリケーションはできません）。
• サービス A は、応答を期待するメッセージを送信する必要があります。
• ユーザーは B にメッセージを送信し、それに応答します。

悪用プロセスは次のステップを含みます：

1. サービス A が応答を期待するメッセージを送信するのを待ちます。
2. A に直接応答するのではなく、応答ポートをハイジャックしてサービス B にメッセージを送信します。
3. 次に、禁止されたアクションに関するメッセージをディスパッチし、B からの応答と同時に処理されることを期待します。

以下は、説明された攻撃シナリオの視覚的表現です：

 (1) (1) (1) (1) (1) (1).png)

発見の問題

• インスタンスの特定の困難: xpc_connection_get_audit_token の使用例を静的および動的に検索するのは困難でした。
• 方法論: Frida を使用して xpc_connection_get_audit_token 関数をフックし、イベントハンドラから発信されない呼び出しをフィルタリングしました。ただし、この方法はフックされたプロセスに限定され、アクティブな使用が必要でした。
• 分析ツール: IDA/Ghidra などのツールを使用して到達可能な mach サービスを調査しましたが、プロセスは時間がかかり、dyld 共有キャッシュに関与する呼び出しによって複雑化しました。
• スクリプトの制限: dispatch_async ブロックからの xpc_connection_get_audit_token への呼び出しの分析をスクリプト化しようとしましたが、ブロックの解析と dyld 共有キャッシュとの相互作用の複雑さによって妨げられました。

修正

• 報告された問題: smd 内で見つかった一般的および特定の問題を詳細に記載した報告書が Apple に提出されました。
• Apple の対応: Apple は smd 内の問題に対処し、xpc_connection_get_audit_token を xpc_dictionary_get_audit_token に置き換えました。
• 修正の性質: xpc_dictionary_get_audit_token 関数は、受信した XPC メッセージに関連付けられた mach メッセージから直接監査トークンを取得するため、安全と見なされています。ただし、xpc_connection_get_audit_token と同様に、公開 API の一部ではありません。
• より広範な修正の不在: Apple が接続の保存された監査トークンと一致しないメッセージを破棄するなど、より包括的な修正を実装しなかった理由は不明です。特定のシナリオ（例：setuid の使用）での正当な監査トークンの変更の可能性が要因かもしれません。
• 現在の状況: この問題は iOS 17 と macOS 14 に残っており、それを特定し理解しようとする人々にとって課題となっています。