「Shrootless」の脆弱性の発見に続いて、Microsoft は、攻撃者がオペレーティング システムの透明性、同意、および制御 (TCC) テクノロジをバイパスできる新しい macOS の脆弱性「powerdir」を発見しました。データ。 Microsoft Security Vulnerability Research (MSVR) による共同脆弱性開示(CVD) を通じて、調査結果を Apple と共有しました。 Apple は、2021 年 12 月 13 日にリリースされたセキュリティ更新プログラムの一部として、現在CVE-2021-30970として特定されているこの脆弱性に対する修正プログラムをリリースしました。macOS ユーザーには、これらのセキュリティ更新プログラムをできるだけ早く適用することをお勧めします。
Apple が 2012 年に macOS Mountain Lion に導入した TCC は、基本的に、デバイスのカメラ、マイク、位置情報へのアクセス、およびユーザーのカレンダーや iCloud アカウントへのアクセスなど、ユーザーがアプリのプライバシー設定を構成できるように設計されています。とりわけ。 TCC を保護するために、Apple は不正なコードの実行を防止する機能を導入し、TCC へのアクセスをディスク全体にアクセスできるアプリのみに制限するポリシーを適用しました。ターゲット ユーザーのホーム ディレクトリをプログラムで変更し、アプリ リクエストの同意履歴を保存する偽の TCC データベースを作成できることを発見しました。パッチが適用されていないシステムで悪用された場合、この脆弱性により、悪意のあるアクターがユーザーの保護された個人データに基づいて攻撃を調整できる可能性があります。たとえば、攻撃者はデバイスにインストールされているアプリを乗っ取ったり、独自の悪意のあるアプリをインストールしたりして、マイクにアクセスしてプライベートな会話を録音したり、ユーザーの画面に表示される機密情報のスクリーンショットをキャプチャしたりできます。
他の TCC 脆弱性は以前に報告されており、発見前にパッチが適用されたことに注意してください。このバグに遭遇したのは、最新の修正プログラムの 1 つを調査した結果でもありました。実際、この調査中に、概念実証 (POC) エクスプロイトを更新する必要がありました。これは、最初のバージョンが最新の macOS バージョンである Monterey で機能しなくなったためです。これは、macOS やその他のオペレーティング システムやアプリケーションがリリースごとに強化されていても、Apple などのソフトウェア ベンダー、セキュリティ研究者、およびより大きなセキュリティ コミュニティが継続的に協力して、攻撃者が脆弱性を悪用する前に脆弱性を特定して修正する必要があることを示しています。 .
マイクロソフトのセキュリティ研究者は、macOS やその他の Windows 以外のデバイスに影響を与える可能性のある新しい脆弱性と攻撃者の手法を発見するために、脅威の状況を監視し続けています。 Microsoft の調査から得られた発見と洞察は、 Microsoft Defender for Endpointなどの保護テクノロジとソリューションを強化します。これにより、組織は、ますます異種化が進んでいるネットワークを可視化できます。たとえば、この調査では、この脆弱性に関連する動作の一般的な検出が報告されており、Defender for Endpoint は、パッチが適用される前であっても、エクスプロイトに対する可視性と保護を即座に提供できます。このような可視性により、組織は脆弱性やクロスプラットフォームの脅威をより迅速に検出、管理、対応、修正することもできます。
このブログ投稿では、TCC に関する情報を共有し、以前に報告された脆弱性について説明し、独自の調査結果を紹介します。
TCC の概要
前述のように、TCC はアプリが事前の同意と知識なしにユーザーの個人情報にアクセスするのを防ぐ技術です。ユーザーは通常、macOS のシステム環境設定 ([システム環境設定] > [セキュリティとプライバシー] > [プライバシー]) で管理します。
![macOS の [セキュリティとプライバシー] ペインのスクリーンショット](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2022/01/Fig1-macOS-TCC-Security-and-Privacy-Pane-1024x893.png)
TCC は、アプリ リクエストの同意履歴を含むデータベースを維持しています。一般に、アプリが保護されたユーザー データへのアクセスを要求すると、次の 2 つのいずれかが発生する可能性があります。
- アプリとリクエストのタイプが TCC データベースに記録されている場合、データベース エントリのフラグは、自動的にユーザーの操作なしでリクエストを許可するか拒否するかを決定します。
- アプリとリクエストのタイプが TCC データベースに記録されていない場合は、ユーザーにプロンプトが表示され、アクセスを許可するか拒否するかを決定します。上記の決定はデータベースに戻されるため、後続の同様のリクエストは最初のシナリオに分類されます。
内部には、2 種類の TCC データベースがあります。各種類は、リクエスト タイプのサブセットのみを維持します。
- ユーザー固有のデータベース:特定のユーザー プロファイルにのみ適用される保存されたアクセス許可の種類が含まれています。 ~ /Library/Application Support/com.apple.TCC/TCC.dbに保存され、上記のプロファイルを所有するユーザーがアクセスできます
- システム全体のデータベース:システム レベルで適用される保存されたアクセス許可の種類が含まれます。 /Library/Application Support/com.apple.TCC/TCC.dbに保存され、root またはフル ディスク アクセスを持つユーザーがアクセスできます。
macOS は、 tccdと呼ばれる特別なデーモンを使用して TCC ロジックを実装します。実際、tccd には少なくとも 2 つのインスタンスがあります。1 つはユーザーによって実行され、もう 1 つは root によって実行されます。
リクエストの各タイプは、 kTCCServiceプレフィックスで始まります。完全なリストではありませんが、以下にいくつかの例を示します。
| リクエストの種類 | 説明 | 担当 |
|---|---|---|
| kTCCサービスリバプール | 位置情報サービスへのアクセス | ユーザー固有の TCC データベース |
| kTCCServiceユビキタス | iCloud アクセス | ユーザー固有の TCC データベース |
| kTCCServiceSystemPolicyDesktopFolder | デスクトップ フォルダへのアクセス | ユーザー固有の TCC データベース |
| kTCCServiceCalendar | カレンダーへのアクセス | ユーザー固有の TCC データベース |
| kTCCServiceReminders | リマインダーへのアクセス | ユーザー固有の TCC データベース |
| kTCCServiceMicrophone | マイクへのアクセス | ユーザー固有の TCC データベース |
| kTCCサービスカメラ | カメラへのアクセス | ユーザー固有の TCC データベース |
| kTCCServiceSystemPolicyAllFiles | フルディスクアクセス機能 | システム全体の TCC データベース |
| kTCCServiceScreenCapture | 画面キャプチャ機能 | システム全体の TCC データベース |
また、 TCC.dbファイルは SQLITE データベースであるため、ユーザーにフル ディスク アクセスが許可されている場合、ユーザーはデータベースを表示したり編集したりできることにも注意してください。
データベースの列は、 csreq列を除けば一目瞭然です。 csreq値には、アプリのコード署名要件をエンコードする 16 進数の blob が含まれています。これらの値は、以下の図 4 に示すように、 codesignおよびcsreqユーティリティを使用して簡単に計算できます。
これらを考慮して、悪意のあるアクターが TCC データベースへのフル ディスク アクセスを取得した場合、それを編集して、自分の悪意のあるアプリを含め、選択した任意のアプリに任意のアクセス許可を付与することができます。影響を受けるユーザーは、上記のアクセス許可を許可または拒否するように求められることもないため、ユーザーが認識していない、または同意していない構成でアプリを実行できます。
TCC の保護 (およびバイパス): 手法と以前に報告された脆弱性
以前は、アプリは TCC データベースに直接アクセスして、コンテンツを表示したり変更したりすることができました。前述のバイパスのリスクを考慮して、Apple は 2 つの変更を行いました。まず、Apple はシステム全体のTCC.dbをSystem Integrity Protection (SIP) によって保護しました。これは、不正なコードの実行を防止する macOS の機能です。次に、Apple は、フル ディスク アクセスを持つアプリのみがTCC.dbファイルにアクセスできるという TCC ポリシーを適用しました。ただし、一部のアプリでは適切に機能するためにそのようなアクセスが必要だったため、このポリシーもその後悪用されたことに注意してください (たとえば、SSH デーモンsshd )。
興味深いことに、攻撃者は/Library/Application Support/com.apple.TCCの下にあるファイルを一覧表示しようとするだけで、ユーザーのターミナルがフル ディスク アクセスを持っているかどうかを知ることができます。この試みが成功したということは、ターミナルが完全なディスク アクセス機能を備えていることを意味し、したがって、攻撃者はユーザーのTCC.dbを自由に変更することができます。
さらに、TCC バイパスに関連するいくつかの脆弱性が以前に報告されています。これらには次のものが含まれます。
- Time Machine マウント( CVE-2020-9771 ): macOS は、 Time Machineと呼ばれる組み込みのバックアップおよび復元ソリューションを提供します。 Time Machine バックアップは、「 noowners 」フラグを使用して ( apfs_mountユーティリティを使用して) マウントできることが判明しました。これらのバックアップにはTCC.dbファイルが含まれているため、攻撃者はこれらのバックアップをマウントし、ディスク全体にアクセスすることなくデバイスの TCC ポリシーを特定することができます。
- 環境変数ポイズニング( CVE-2020-9934 ): $HOME/Library/Application Support/com.apple.TCC/TCC.dbを展開することで、ユーザーのtccdがTCC.dbファイルへのパスを構築できることが発見されました。ユーザーは$HOME環境変数を操作できるため ( launchdによってtccdに導入されたように)、攻撃者は選択したTCC.dbファイルを任意のパスに配置し、 $HOME環境変数を汚染し、代わりにTCC.dbにそのファイルを消費させることができます。 .
- バンドル結論の問題( CVE-2021-30713 ): XCSSET マルウェア ファミリに関するブログ投稿でJamf によって最初に開示されたこのバグは、macOS がアプリ バンドル情報を推測する方法を悪用していました。たとえば、一般的にマイクにアクセスできる特定のアプリを攻撃者が知っているとします。その場合、アプリケーション コードをターゲット アプリのバンドルに組み込み、その TCC 機能を「継承」することができます。
その後、Apple はこれらの脆弱性にパッチを適用しました。ただし、当社の調査によると、 TCC.dbへの潜在的なバイパスが引き続き発生する可能性があります。次のセクションでは、発見した脆弱性と、その脆弱性を証明するために開発した POC エクスプロイトの詳細について説明します。
ホーム ディレクトリの変更: 「powerdir」の脆弱性
以前の TCC の脆弱性を評価する際に、Apple が各問題をどのように修正したかを評価しました。私たちの注目を集めた 1 つの修正は、CVE-2020-9934 ( $HOME環境変数ポイズニングの脆弱性) に対するものでした。修正はtccdの_db_open関数で見ることができます:
$HOME環境変数を展開する代わりに、Apple は現在のユーザー ( getuid()で取得) に対してgetpwuid()を呼び出すことにしたことに注意してください。最初に、 getpwuid関数は、特定のユーザーに関する情報を含むメモリ内の構造体 ( struct password* ) を取得します。次に、 tccdはそこからpwdirメンバーを抽出します。このpwdirメンバーにはユーザーのホーム ディレクトリが含まれ、その値は$HOME環境変数が変更された後も保持されます。
このソリューションは確かに環境変数ポイズニングによる攻撃を防ぎますが、コアの問題を防ぐことはできません。アプリはユーザーのホーム ディレクトリをプログラムで変更し、偽のTCC.dbファイルを植えることができるでしょうか?
最初の POC エクスプロイト
上記の質問に答える最初の試みは単純でした。偽のTCC.dbファイルを作成し、ディレクトリ サービス コマンドライン ユーティリティ ( dscl ) を使用してホーム ディレクトリを変更します。
root アクセスが必要ですが、ローカルまたはユーザー固有のTCC.dbが維持する TCC ポリシーkTCCServiceSystemPolicySysAdminFilesがアプリに付与されている場合にのみ、これが機能することがわかりました。これはフル ディスク アクセスよりも弱いですが、 dsexportおよびdsimportユーティリティを使用してその制限を回避することができました。
次に、ユーザーのディレクトリ サービス エントリをエクスポートし、出力ファイルを操作して、ファイルを再度インポートするだけで、 dscl TCC ポリシーの制限を回避することができました。
したがって、最初の POC エクスプロイトは次のことを行います。
- ターゲット アプリのcsreq BLOB を取得します。
- 必要なアクセス権とcsreq BLOB を含む偽のTCC.dbファイルを作成します。
- dsexportを使用して、ユーザーのディレクトリ サービス エントリをエクスポートします。
- ディレクトリ サービス エントリを変更して、ユーザーのホーム ディレクトリを変更します。
- dsimportを使用して、変更されたディレクトリ サービス エントリをインポートします。
- ユーザーのtccdを停止し、プロセスを再起動します。
このエクスプロイトを使用すると、攻撃者は任意のアプリケーションの設定を変更できます。以下のスクリーンショットでは、このエクスプロイトにより、攻撃者が Teams などの任意のアプリでマイクとカメラへのアクセスを有効にする方法を示しています。
2021 年 7 月 15 日に最初の調査結果を Apple 製品セキュリティ チームに報告した後、8 月に開催された BlackHat USA 2021 で Wojciech Reguła と Csaba Fitzl によって提示された同様のバイパスに気づきました。ただし、Apple が前述の同様の調査結果を修正した後も、エクスプロイトは引き続き機能しました (現在はCVE-2020-27937として割り当てられています)。したがって、私たちの研究は依然として新しい脆弱性であると考えていました。
Monterey リリースと 2 回目の POC エクスプロイト
10 月に macOS Monterey がリリースされる前に、 Microsoft Security Vulnerability Research (MSVR) を介してCoordinated Vulnerability Disclosure (CVD) を通じて調査結果を Apple に共有しました。ただし、上記のバージョンのリリース時に、 dsimportツールの動作方法が変更されたため、最初の POC エクスプロイトが機能しなくなっていることに気付きました。そこで、ホーム ディレクトリをサイレント モードで変更する別の方法を探しました。
macOS Monterey を調査しているときに、 /usr/libexec/configdに遭遇しました。これは、ローカル システムの多くの構成面を担当するシステム構成デーモンである、最新の macOS リリースに同梱されている Apple バイナリです。 configdには次の 3 つの側面があります。
- これは、値kTCCServiceSystemPolicySysAdminFilesを持つ「 com.apple.private.tcc.allow 」という資格を持つ Apple 署名付きバイナリです。これは、ホーム ディレクトリをサイレントに変更できることを意味します。
- 内部の macOS バンドルである構成エージェントに拡張性があります。これは、カスタム バンドルをロードする可能性があることを示唆しており、目的のためにコードを挿入できることを意味します。
- カスタム構成エージェントをロードするための強化されたランタイム フラグはありません。この側面は設計による可能性が最も高いですが、完全に署名されていないコードをロードできることも意味します。
-tオプションを指定してconfigdを実行することにより、攻撃者はロードするカスタム バンドルを指定する可能性があります。したがって、私たちの新しい POC エクスプロイトは、ユーザーのホーム ディレクトリを変更するdsexportおよびdsimportメソッドをconfigdコード インジェクションに置き換えます。これにより、最初の POC エクスプロイトと同じ結果が得られます。このエクスプロイトでは、設定を変更して、たとえば、Teams などのアプリにカメラやその他のサービスへのアクセスを許可することができます。
以前と同様に、最新の調査結果を Apple と共有しました。繰り返しになりますが、製品セキュリティ チームの協力に感謝します。
Microsoft Defender for Endpoint を使用した powerdir の脆弱性の検出
powerdir の脆弱性に関する私たちの調査は、ソフトウェア ベンダーと悪意のあるアクターの間の激しい競争のもう 1 つの例です。前者が定期的な更新を通じてアプリケーションを保護するための継続的な努力にもかかわらず、他の脆弱性が必然的に発見され、後者が悪用される可能性があります。自分の利益。また、システムの脆弱性は、攻撃者が組織のネットワークに侵入するためのエントリ ポイントになる可能性があるため、セキュリティ チームがすべてのプラットフォームで脆弱性と脅威を管理できるようにするには、包括的な保護が必要です。
Microsoft Defender for Endpointは、業界をリードするクラウドベースのエンドポイント セキュリティ ソリューションであり、組織は統合されたセキュリティ コンソールを通じて異種コンピューティング環境を管理できます。その脅威と脆弱性の管理機能により、防御側は、powerdir の脆弱性などの設定ミスや脆弱性を迅速に発見し、優先順位を付けて修正することができます。さらに、Defender for Endpoint の比類のない脅威オプティクスは、業界で最も深い脅威インテリジェンスに基づいて構築されており、脅威の状況を継続的に監視する世界クラスのセキュリティ専門家によって支えられています。
Defender for Endpoint の主な強みの 1 つは、悪意のある動作を一般的に検出して認識する能力です。たとえば、前のセクションで見たように、POC エクスプロイトは、次のような多くの疑わしいアクティビティを実行します。
- 適切なディレクトリ構造を持つ新しいTCC.dbファイルのドロップ
- 既存のtccdインスタンスの強制終了
- dsimportやdsexportなどの疑わしいディレクトリ サービスの呼び出し
Defender for Endpoint は、CVE-2020-9934 に関連する動作 (つまり、新しいTCC.dbファイルをドロップするとアラートが発生する) を一般的に検出することで、powerdir の脆弱性にパッチが適用される前に、これらのエクスプロイトに対する保護を即座に提供しました。これは、Defender for Endpoint の機能の証です。強力でインテリジェントな一般化により、今後発見される同様のバイパス脆弱性を検出します。
Microsoft Defender for Endpoint が、すべてのプラットフォームにわたって完全なエンドポイント セキュリティ ソリューションを提供する方法について説明します。
ジョナサン・バー・オア
Microsoft 365 Defender 研究チーム
Comments