macOSでパスワードが漏えいする可能性があったNetAuthAgent脆弱性
(wts.dev)- Appleは2024年10月28日に配布したmacOS Sequoia 15.1、Sonoma 14.7.1、Ventura 13.7.1でCVE-2024-54471を修正し、アップデート前の環境ではNetAuthAgentを通じて保存された認証情報が露出する可能性があった
- 問題の核心は、NetAuthAgentのMIGサーバーがメッセージ送信元を確認せず、ファイルサーバー認証情報の参照・作成・一部上書きルーチンを開放していた点にある
- 攻撃者は
com.apple.netauth.user.guiMachサービスへメッセージを送り、Keychainのinternet password項目を代理で参照させ、ユーザー名とパスワードを受け取ることができた - 影響はFinderの「サーバへ接続」で保存したFTP、Samba、WebDAV、プリントサーバー認証情報にとどまらず、別のチェーンを通じてiCloudアカウント情報とAPIトークンの露出にもつながり得た
- 修正後のNetAuthAgentはMachメッセージのaudit tokenで送信元プロセスのentitlementを検査し、
com.apple.private.netauth.useragent.allow=trueがなければ応答しない
CVE-2024-54471の修正対象範囲
- CVE-2024-54471はAppleのセキュリティアップデートに含まれて修正されたmacOS脆弱性
- パッチを含むバージョンはいずれも2024年10月28日にリリースされた
- macOS Sequoia 15.1
- macOS Sonoma 14.7.1
- macOS Ventura 13.7.1
- 該当バージョンへ更新していないmacOSデバイスは、直ちにアップデートが必要
macOS IPCとMachベースの構造
- macOSと大半のApple OSカーネルはXNUであり、BSD系要素と大きく改変されたMachカーネル派生を含むハイブリッドカーネル
- Machは現代のmacOSでも4つの抽象化を基盤としている
- task: スレッドが実行される実行環境で、リソース割り当ての基本単位
- thread: CPU利用の基本単位
- port: カーネルが保護するメッセージキューに相当する通信チャネル
- message: スレッド間通信に使われる型付きデータオブジェクトの集合
- Machのポートはユーザー空間に直接露出するキューではなく、各taskのポート名空間内にあるport rightの形で扱われる
- 主な権限は2つ
- send right: 複数のtaskが同じポートに対して持てる
- receive right: 1つのtaskだけが持てる
- この構造により、1つのサーバーtaskが複数のクライアントtaskからのメッセージを受け取るクライアント・サーバーモデルが成り立つ
- macOSのbootstrap serverは、すべてのtaskがsend rightを持つポートを受け取り、クライアントが文字列名で登録されたMach serviceのsend rightを要求できるようにする
MIGサーバーで生じた認証の空白
- MIGは、Machメッセージの送受信を関数型インターフェースで包むツール
- MIGは擬似CのIDLとコンパイラで構成され、IDLファイルから次のファイルを生成する
- クライアント向けCソース
- サーバー向けCソース
- 双方で使うCヘッダー
- 各関数はroutine、ルーチン群はsubsystemと呼ばれ、subsystem番号とroutineインデックスがメッセージIDに反映される
- macOSのユーザー空間通信ではMIGは概ねXPC APIに置き換えられてきたが、XPCもMachメッセージ上に構築されている
- MIGサーバー自体には強制的な認証メカニズムがないため、サーバーが送信元を検証しなければ、send rightを持つ任意のtaskがリモートルーチンを呼び出せる
- MIGサーバー探索にはblacktopのipsw CLIが有用で、
NDR_recordシンボルをimportするバイナリを探す方法が使われる- この方法ではMIGサーバーだけでなくMIGクライアントも見つかる
- サーバーコードとクライアントコードは逆アセンブラやデコンパイラ上で比較的容易に見分けられる
NetAuthAgentが扱う認証情報
- NetAuthAgentはmacOSでFTP、Samba、WebDAVなどのファイルサーバー認証情報を処理するユーザーエージェント
- Finderの「移動 → サーバへ接続」でファイルサーバーに接続すると表示される認証ダイアログは、NetAuthAgentまたは関連プロセスが提供する
- ユーザーがパスワード保存チェックボックスを選ぶと、認証情報はmacOS Keychainに保存される
- NetAuthAgentがパスワードを直接保存するわけではなく、中央の秘密保管庫のようにKeychainを利用する
- Keychain項目は独自のアクセス制御リストを持ち、通常はアプリケーションがアクセスすべきでない秘密に到達できないようになっている
- ただし、特定プロセスが他プロセスのためにKeychain参照を代理実行する仕組みを公開すると、全体のセキュリティモデルが弱くなり得る
脆弱だったNetAuthAgentのMIGサービス
- NetAuthAgentはbootstrap serverで参照可能なMIGサーバーを公開していた
- サービス名は
com.apple.netauth.user.gui - このサーバーはファイルサーバー認証情報を読み取り、作成し、一部のケースでは上書きするルーチンを提供していた
- 修正前は、これらのルーチンがメッセージ送信元を検証していなかった
- Routine 19、メッセージID 40219は、Keychainの
internet passwordクラス項目の参照をプロキシできた - このルーチンはシリアライズされたオプション辞書をout-of-lineデータdescriptorで受け取り、ユーザー名とパスワードを2つのout-of-lineデータdescriptorで返した
攻撃フローとPoCの構成
- PoCはSwiftで書かれたセキュリティ研究ツールKassを使ってMachメッセージとMIGクライアントを扱う
- NetAuthAgentクライアントは次の値で定義される
- サービス名:
com.apple.netauth.user.gui - subsystem基準のroutine ID: 40200
- サービス名:
- 参照オプションはProperty List形式でシリアライズされ、
Scheme、Host、AlternatePort、Pathなどのフィールドを含められる - macOS Keychain APIの
SecItemCopyMatchingは、秘密値を要求しない場合、権限のないプロセスでもKeychain項目のメタデータ取得に使えることがある - アクセス制御リストもメタデータとして参照できるため、項目のtrusted application一覧に
/System/Library/CoreServices/NetAuthAgent.appが含まれているか確認できた - 攻撃コードはNetAuthAgentがアクセス可能な
internet password項目を走査し、次の情報を抽出できた- 表示名
- プロトコル
- ホスト
- ポート
- パス
- ユーザー名
- パスワード
ファイルサーバー認証情報漏えいの影響
- 修正前は、NetAuthAgentへのsend rightを得た悪意あるプロセスがファイルサーバー認証情報全体を漏えいさせることができた
- 企業環境では、その認証情報がSSO認証情報である可能性があり、攻撃者が社内システムの複数リソースへアクセスできる恐れがあった
- Finderの「サーバへ接続」機能の利用規模は不明だが、複数の大学や教育機関のヘルプ文書が学生や教職員にこの機能の利用を案内し、一部ではKeychain保存チェックボックスの選択を推奨していた
- プリントサーバーベンダーのプリンター接続案内も見つかっており、NetAuthAgentはプリントサーバー認証情報も扱う
- 少なくとも1つの文書では、保存済みパスワード更新時にKeychain Accessアプリは一般ユーザーに扱いづらいとして、保存チェックボックスを選ばないよう案内していた
- 管理対象デバイスで同じ認証情報がsuperuser認証情報としても使われている場合、権限昇格につながる可能性があるが、管理対象デバイスでのテストがなく確認はされていない
- 個人ユーザーがFinder経由でNASに接続し認証情報を保存していた場合でも、NAS認証情報が攻撃者に露出する可能性があった
- 同じ認証情報を他のインターネットアカウントで使い回していた場合、それらのアカウントも侵害され得た
- FTP、Samba、WebDAVはインターフェースがよく定義されているため、認証情報漏えい後にサーバーファイルの探索や持ち出しを自動化しやすい
Keychainを使った追加悪用
- NetAuthAgentはKeychain項目を作成するルーチンも公開していたため、悪意あるプロセスが任意のデータを
passwordフィールドに入れて隠すことができた - この方法はディスクへの直接書き込みを避けられるため、セキュリティソフトを回避するデータ隠匿手段になり得た
- Keychain内の不審項目を明示的に検査するセキュリティソフトについては知られていない
- 悪意あるプロセスが正当な認証情報をKeychainに保存することも可能だった
- この動作は単独では効果が限定的かもしれないが、攻撃者が制御するファイルサーバー認証情報を保存したうえで、ユーザーをソーシャルエンジニアリングで誘導する複合攻撃に使われる可能性があった
iCloud APIトークンへ至るエクスプロイトチェーン
- 「サーバへ接続」を使わないユーザーも、この脆弱性の影響外ではなかった
- 大半のmacOSデバイスには、NetAuthAgentがアクセスできるほど広いACLを持つKeychain項目が存在する
- そのKeychain項目には、ディスク上の特定ファイルを復号するための復号鍵が含まれている
- そのファイルにはユーザーのiCloudアカウント情報とAPIトークンが入っている
- 攻撃者はKeychain項目と既知の場所にあるファイルを使って、次の情報を取得できた
- 名
- 姓
- メールアドレス
- メールエイリアス
- 有効化された機能とendpoint
- 複数の長期有効APIトークン
iCloudトークンで可能な操作
- Wojciech Regułaの以前の研究では、同じAPIトークンを別の方法で見つけて次のデータを漏えいできることが示されていた
- Contacts
- Calendars
- Reminders
- Find My経由のユーザー位置
- その結果のうち、Remindersを除く項目は再現された
- 新規アカウントと移行済みアカウントのRemindersは、Appleがより安全なCloudKitへ移し、暗号化された形でのみアクセス可能になっていた
- 追加で可能だった操作は次のとおり
- 連絡先写真の漏えい
- CloudKitの参照。ただし復号は不可
- iCloud key-value storeデータの漏えい
- iCloudバックアップメタデータの漏えい（デバイスのシリアル番号を含む）
- Find Myによるユーザーの他デバイス位置の漏えい
- Find Myによるユーザーの友人位置の漏えい
- Find Myを通じたロック、消去、サウンド再生の実行
- CloudKitデータの復号も調査されたが、完了には至らなかった
- 商用フォレンジック企業が、このAPIトークンと必要に応じてiOSデバイスのPINを併用し、CloudKitデータやiCloudバックアップ内のCloudKitデータを復号できる可能性は否定されていない
Appleの修正方法
- 修正後のNetAuthAgentは、メッセージを受け取るとまず送信元のentitlementを確認する
- entitlementはコード署名時にバイナリへ付与されるキー・バリューの組
- 標準セキュリティ設定のmacOSでは、Apple Mobile File Integrityがプロセス実行時にrestricted entitlementを検査し、適切なprovisioning profileがなければプロセスを終了させる
- provisioning profileはAppleの署名が必要なため、この検査は回避しにくいよう設計されている
- NetAuthAgentが要求するentitlementは次のとおり
- キー:
com.apple.private.netauth.useragent.allow - 値: boolean
true
- キー:
- このentitlementがない送信元に対して、NetAuthAgentは応答しない
- Machメッセージの受信時にカーネルが付加するtrailerにはaudit tokenが含まれる
- 受信taskはaudit tokenで送信taskを識別し、カーネルにそのtaskのentitlement辞書を要求したうえで値を検査できる
セキュリティ構造の弱い連結部
- ファイルサーバー認証情報は特定アプリケーションだけがアクセスできるよう保存されていても、そのアプリケーションが他アプリケーションからの参照命令を受け入れるなら、そのアプリケーションが弱い連結部になる
- iCloud APIトークンがディスク上の暗号化ファイルに保存されていても、復号鍵が広いACLを持つKeychain項目にあるなら、そのACLが弱い連結部になる
- macOSはプロセス注入を難しくするセキュリティ機構を備え、全体的なセキュリティ基盤は強いと評価される
- しかし、この脆弱性のように単純な送信元検証漏れ1つで、ファイルサーバー認証情報やiCloud APIトークンの露出につながり得る
ユーザーへの推奨対応
- まだ可能ならAdvanced Data Protectionを有効化することが推奨される
- iCloudをWebブラウザで使わないなら、iCloudデータのWebアクセス無効化も選択肢
- iCloud WebサイトはAppleのiCloudアプリと異なるAPI endpointを使う場合がある
- この脆弱性ではもはやトークンへアクセスできないが、過去の脆弱性で露出したことがあり、今後別の脆弱性で露出する可能性もある
- このエクスプロイトが悪意ある行為者に利用または発見された証拠はない
- それでも認証情報悪用が特に懸念されるなら、パスワードを変更すべき
- 2024年10月以降macOSを更新していないデバイスは、直ちにアップデートする必要がある
1件のコメント
Hacker News のコメント
よく書かれた記事で、Apple がある程度隠そうとしていた、空のパスワードを2回試すと root ログインを迂回できたゼロデイを思い出した。2017年ごろ、もしかすると2018年だったかもしれない
root ログインの入力欄ならどこでも管理者ユーザー名を入れ、パスワードを空のままログインすると、1回目はパスワードが間違っていると表示されるが、警告を閉じて2回目に押すとそのユーザーとしてログインできた
その日は100%再現でき、ソーシャルメディアで広まった後すぐにパッチが出たが、それでもとんでもない見落としに見えた。Mac の認証メカニズム周辺にはまだ古い残骸が残っているようで、Mach カーネルの port システムが言及されているのも興味深い
ユーザー名バッファが任意文字256文字に達すると XDM がクラッシュし、root シェルを起動した。ただしこれは、誰もがセキュリティについてずっと無邪気だった90年代初頭の話
grep一発で抜き出せて、100%動作していた“ACLs don't”: https://waterken.sourceforge.net/aclsdont/current.pdf
記事に小さな修正が入った: entitlement チェックはカーネルの Mach 層にはない
https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3
XNU の挙動を説明していた部分の事実誤認を直す、1語だけの変更
「プロセスが、別のプロセスに keychain クエリを事実上プロキシさせる仕組みを公開すると、システム全体のセキュリティを弱める可能性がある」という部分は、混乱した代理人問題のように見える: https://en.wikipedia.org/wiki/Confused_deputy_problem
capability ベースの設計なら、この種の問題を体系的に防げるはず
著者が実際の PoC コードをどこで提供しているのか気になる。緩和策のテストを少ししてみたいが、サンプルコードは見えるものの不完全に見える
現実的なリスクはどの程度なのか？
リスク面では、NetAuthAgent への send right を取得できるアプリ、実質的にはほぼすべての非サンドボックスアプリが、FTP、WebDAV、Samba のようなファイルドライブの保存済み認証情報を NetAuthAgent にこっそり要求できる。これにより iCloud の連絡先とカレンダー全体の流出、そのほかの iCloud 関連データの流出にもつながり得る
サンドボックス化はこれを難しくするが、不可能にはしない。最新状態ならリスクは0で、パッチは昨年10月に入っているので、正直もうアップデート済みであるべきだ。アップデートしておらず、今後もするつもりがないなら、デバイス上で動くすべてのプロセスを漏れなく確認しない限り、リスクははるかに大きい
とても詳しい記事で、複数のカーネルの歴史まで扱っていてよかった。ただ、深刻なセキュリティ問題に関する記事なら、冒頭に影響範囲、攻撃条件、論理バグなのかメモリ破壊なのかといった、ごく短い説明があるとよい
残りを読むか判断できる程度に簡潔で十分
本当に興味深い記事だ。Mach と Darwin カーネルが作られる過程に、これほど多くの裏話があるとは知らなかった
今となっては Mach が macOS バグの安定供給源のように感じる。Apple が懸命にロックダウンしているのは分かるが、Mach から完全に抜け出す道はあるのだろうか？
デーモンが entitlement を確認しなければ安全ではない。メッセージング機構を責めるより、その使い方を責めるべきだ
実際、どんなロックダウンされたメッセージングシステムでも、単純なメッセージ配送以上のもの、たとえば送信者の検証のようなものが必要になる。Mach のような低レベル通信プロトコルからそのまま得られるものではない。Apple が MIG コンパイラを改修して entitlement チェックを追加しない限りはそうだ
Mach は entitlement チェックと一緒に使えば素晴らしい
技術的には、異なるコンポーネントがより多く共存することになり、潜在的な攻撃対象領域が増える可能性もある。しかし、より特化した領域は制御を単純化し、結果としてその領域をより適切に保護できるようにする可能性がある