研究者らは、MicrosoftのActive Directory証明書サービス(AD CS)に存在した、すでにパッチが適用済みの欠陥を突く概念実証(PoC)エクスプロイトを公開しました。この欠陥は、権限の低いドメインユーザーがドメインコントローラーになりすまし、AD環境全体を完全に侵害することを可能にするものです。原因は、Microsoft AD Servicesの証明書ベースのクライアント認証部分に存在した、信頼境界の欠陥にありました。
Microsoftは7月に過去最多となる622件のPatch Tuesdayアップデートを配信し、その中でCVE-2026-54121として追跡されている脆弱性を修正しました。この脆弱性を発見し悪用したAniq Fakhrul氏(@aniqfakhrul)とMuhammad Ali氏(@h0j3n)は、GitHub上の投稿の中でこの脆弱性を「Certighost」と名付けています。
研究者らの説明によると、この脆弱性はエンタープライズ認証局(CA)が、AD CSの登録フォールバック機構である「チェイス(chase)」を処理する方法に起因しています。チェイスとは、一部のクロスドメインコントローラー登録シナリオで実行される二次的なディレクトリ検索のことです。
Fakhrul氏とAli氏が発見したところによると、この欠陥のためにサブジェクトと公開鍵を紐づける証明書の発行過程において、cdc(Client DC)とrmd(Remote Domain)というリクエスト属性を操作することで、CAを騙して攻撃者が制御するホストにAD識別情報を問い合わせさせることが可能だったといいます。
研究者らは投稿の中で次のように説明しています。「脆弱性のある経路は、ディレクトリオブジェクトの解決処理中に発生するAD CS登録フォールバック、いわゆるチェイスです。攻撃者はcdcなどのリクエスト属性を指定することで、認証局(CA)にドメインコントローラーの識別データを、攻撃者が制御するホストへ問い合わせさせることができました。CAはその後、そのデータを証明書発行時に使用していました」
この結果、CAはリクエスト元が提示したチェイスの対象先が、本当にそれが名乗るドメインコントローラーであるかを検証しないまま受け入れてしまっていました。「これにより、攻撃者は自らが制御するホスト上でLDAPとLSAのサービスを稼働させ、CAをそのホストへ誘導し、選んだ対象プリンシパルのディレクトリデータを返させることが可能になっていました」と研究者らは記しています。
Certighostが悪用する信頼境界
この脆弱性は、AD CSの証明書登録プロセス内にある信頼境界の破綻に起因しており、研究者らはPoC攻撃の中でこれを悪用しました。
認証局大手Sectigoのシニアフェロー、ジェイソン・ソロコ氏はDark Reading の取材に対し、「Active Directoryは自らのディレクトリを『誰が誰であるか』についての真実の源として扱っており、証明書サービスはディレクトリが述べる内容を保証してしまいます」と説明します。「そのため、ディレクトリにエントリを追加できる者であれば誰でも、証明書が主張する内容を形作れてしまうのです」
残念ながら、こうしたリスクシナリオは他の標準的なプロトコルのやり取りでもたびたび繰り返されているとソロコ氏は指摘します。「信頼度の低い側が、信頼度の高いコンポーネントにポインタを渡し、そのコンポーネントは対象が本当にポインタの主張どおりの存在かを確認せずに、それをたどってしまいます」とソロコ氏は言います。「ディレクトリのリファラル、DNSの委任、OAuthのリダイレクトは、いずれも同じ形のバグを生み出してきました」
研究者らの説明によれば、Active Directory証明書サービスはMicrosoftの公開鍵基盤(PKI)実装として機能し、Active Directoryと連携して暗号化、署名、セキュアな通信、認証などの目的でX.509証明書を発行します。
秘密鍵はリクエスト元の手元に残る一方、証明書にはCAが署名した公開鍵と識別情報が含まれます。証明書は、HTTPS接続の検証やドメインの所有権情報を示すため、Webドメインの署名によく用いられます。
研究者らは「証明書テンプレートが登録プロセスを制御しています」と記しています。「テンプレートは、誰が証明書を要求できるか、何の用途に使えるか、どのような識別情報が必要か、そしてCAがリクエスト内で提供された情報を受け入れてよいかどうかを決定します」
この欠陥とPoCが関わるのは証明書ベースのクライアント認証で、クライアントはエンタープライズCAに証明書を要求し、後にそれを鍵配布センター(KDC)に提示してKerberos資格情報を取得する仕組みだと研究者らは説明しています。
Certighostエクスプロイトの仕組み
研究者らは、エンタープライズCA、Windows Server Active Directory、デフォルトのマシン証明書テンプレート、そして低権限のドメインユーザーアカウントを備えた標準的なエンタープライズ環境の実験室で、この欠陥を悪用しました。PoC自体は自己完結型のPythonスクリプトで、Impacket、pyasn1、asn1crypto、dnspythonといったツールを必要とすると研究者らは述べています。
攻撃の流れは、スクリプトが提供された低権限アカウントを使ってLDAP(Lightweight Directory Access Protocol)経由で接続し、CA、DC、ドメインSID、ドメインGUIDを特定するところから始まります。続いて、ms-DS-MachineAccountQuotaを通じてマシンアカウントを作成し、必要なサービスプリンシパル名を登録します。
攻撃の次の段階は、ローカルのLSAおよびLDAPサービスを起動することです。これらはCAの認証チャレンジを実際のドメインコントローラーへ中継し、チェイスのエンドポイントが正当なドメインプリンシパルとして受け入れられるようにする役割を果たすと研究者らは説明しています。その後、スクリプトはcdcとrmdの属性を含む証明書リクエストを送信します。
対象のDCの識別情報(認証フローで使用されるSIDやDNS名データを含む)を含んだ証明書を受け取ると、スクリプトはその証明書を使って対象のドメインコントローラーとして認証を行い、得られた資格情報キャッシュを書き込むと研究者らは述べています。
パッチと緩和策
研究者らは5月14日にMicrosoft Security Response Centerへこの欠陥を報告し、5月22日までに同社は調査を行い脆弱性を確認しました。パッチは今月初めの7月のPatch Tuesdayアップデートで配信され、Microsoftはこの欠陥に関する報告書の中で、責任ある開示を行った研究者らに謝意を示しています。
同社は本日、Dark Readingのコメント要請に対しすぐには回答しませんでした。
研究者らによると、このアップデートは2点を変更しています。1つ目は対象の真正性で、チェイスの対象が任意のリクエスト元が制御するホストではなく、AD登録済みのドメインコントローラーでなければならないようにする点です。2つ目はオブジェクトの真正性で、チェイスを通じて解決されたオブジェクトが期待される識別情報と一致しなければならないようにし、たとえ検索経路が通常と異なっていても、なりすましを防ぐ点です。
今回の修正はこの特定の欠陥については有効ですが、これは基本的な信頼の仕組み自体は温存したままの「一連の類似修正の最新版」に過ぎず、長期的な解決策にはならない可能性があるとソロコ氏は指摘します。セキュリティチームは、耐量子暗号方式への移行を進めつつも、証明書の登録を「単なる配管ではなくセキュリティ境界」として本気で捉え始めるべきだと同氏は付け加えます。
「証明書に対する信頼は、常にその裏にある審査プロセスに宿ってきました」とソロコ氏は語ります。
そして、この欠陥を緩和する最善の方法はパッチを適用することですが、アップデートを直ちに展開できない組織向けの暫定的な回避策も存在します。システム管理者は、EDITF_ENABLECHASECLIENTDCポリシーフラグをクリアすることで、脆弱なチェイスの動作を無効化できると研究者らは指摘しています。ただし、この緩和策を絶対的な解決策として扱うべきではないと研究者らは付け加えており、正当な証明書登録のワークフローに影響を及ぼす可能性があるため、導入前にテストを行う必要があるとしています。
