Active Directory Certificate Services は長い間使われてきましたが、学習のためのリソースはあまり充実していません。その結果、攻撃にとって増え続ける攻撃経路になり得る設定ミスが、しばしば見つかります。実際に SpecterOps は whitepaper を公開し、複数の設定ミスや潜在的な攻撃を詳述するとともに、ハードニングの助言も提供しています。このブログでは、設定ミスが起こりやすいいくつかの項目と見つけ方、さらにセキュリティを強化するための選択肢をいくつか提示し、無料ツールを使って環境をチェックする方法も説明します。
背景
認証ベースの証明書があるアイデンティティに発行されると、その証明書は Subject Alternative Name (SAN) に設定されたアイデンティティとして認証に使用できます。これは通常、UPN または DNS 名です。次に、この証明書は初回認証においてパスワードの代わりに使用されます。この初回認証の技術的な参照は RFC4556 もし詳しい情報を知りたい場合は、こちらを参照してください。
認証ベースの証明書が発行されると、失効されるか期限切れになるまで、その証明書を主語(Subject)として認証に使用できます。これは、攻撃者を追い出すためにユーザーのパスワードをリセットするといった戦略に依存したインシデント対応計画を回避してしまいます。証明書も同時に失効させない限り、攻撃者はアカウントへの継続的なアクセスを維持できる可能性があります。
Netwrix Threat Manager
リスクのあるテンプレート設定
誤設定につながり得る、いくつかの証明書テンプレート設定を以下に示します。
認証ベースの EKU
まず、あらゆる種類のドメイン レベルの認証を可能にする拡張キー使用法(Enhanced Key Usages(EKUs))を探します。簡単なリストは次のとおりです:
- 任意の目的 (2.5.29.37.0)
- SubCA(なし)
- クライアント認証 (1.3.6.1.5.5.7.3.2)
- PKINIT クライアント認証 (1.3.6.1.5.2.3.4)
- スマートカード ログオン (1.3.6.1.4.1.311.20.2.2)
この機能を許可しているすべての証明書テンプレートを手動で見つける最も簡単な方法は、証明書機関 (Certificate Authority) の MMC スナップインを開き、証明書機関に接続して、「Certificate Template(証明書テンプレート)」セクションを確認し、「Intended Purpose(意図された用途)」列をスキャンして、これらの認証 EKU のいずれかが含まれているものを探すことです。たとえば、下の図では、「Computer」、「Copy of Smartcard Logon」、および「Domain Controller」の両方のテンプレートに、少なくとも 1 つの PKU が含まれていることが示されています。
見つけたテンプレートを対応した後も、通常の証明書を悪用する方法もあることを忘れないでください。たとえば、PoshADCS の Get-SmartCardCertificate 関数は、テンプレートを変更し、そのテンプレートに対して証明書を要求したうえで、テンプレートへの変更を元に戻すことができます。
“Enrollee Supplies Subject” フラグ
フラグ CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT が mspki-certificate-name-flag プロパティに存在すると、証明書の申請者は証明書の署名要求(CSR)で自身の代替となる Subject Name を指定して提供できます。つまり、この設定で証明書の登録が許可されている任意のユーザーが、ネットワーク内の任意のユーザー(特権ユーザーを含む)として証明書を要求できることになります。
このフラグは Certificate Template コンソールで確認できます。Subject Name タブの下にある「Supply in the request」ラジオオプションとして表示されます:
または、次のような PowerShell コマンドを使用して AD からテンプレートを取得し、証明書でフラグが設定されているかどうかを確認することもできます:
Get-ADobject -Filter { ObjectClass -eq "PKIcertificateTemplate" } -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -prop * | Select Name, mspki-certificate-name-flag, @{ Name = "SupplyInRequest" ; Expression = { $_.'mspki-certificate-name-flag' -band 0x00000001 } }
リスクをさらに低減する
証明書の誤設定を修正することに加えて、証明書の発行を制御するために、次のオプションの使用も検討してください。
CA 証明書マネージャーの承認または認可された署名
まずおそらく最も重要なのは、各証明書の「Issuance Requirements(発行要件)」タブを確認し、Certificate Authority(CA)マネージャーからの承認、または 1 人以上の認可された承認者が必要かどうかを見ます。
これらの設定のいずれか、または両方を有効にすると、証明書が発行される前に確認を要求することで、リスクを大幅に低減できます。認可された署名の要求について迷っている場合は、少なくとも CA 証明書マネージャーの承認を必須にしてください。すると、証明書が要求されるたびに、発行前に Certificate Authority に送られて手動レビューが行われます。
登録(Enrollment)権限
次に、各テンプレートの登録(Enrollment)権限を確認します。これは「Security」タブで見つけられます。多くの誤設定は、一般的なプリンシパルや大規模グループがこれらの権限を持っている場合にのみ致命的になることがあります。特に、Authenticated Users、Domain Users、および証明書を要求できるべきでないユーザーの大規模グループがないか確認してください。見つかった場合は、それらの Enroll または AutoEnroll 権限を取り消すことを検討してください。
EDITF_ATTRIBUTESUBJECTALTNAME2 レジストリ キー
最後に、EDITF_ATTRIBUTESUBJECALTNAME2 のレジストリ設定を確認します。この設定は最も注目すべきものの1つです。CA で有効になっている場合は、any 認証ベースで発行される証明書(サブジェクトが Active Directory から自動的に構築される証明書を含む)には、SAN にユーザー定義の値を含めることができます。
この設定を確認するには、次のコマンドを実行できます:
certutil –getreg policyEditFlags
出力リストに EDITF_ATTRIBUTESUBJECALTNAME2 が含まれている場合は、次のコマンドで削除してください:
certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2
この設定に関する追加のガイダンスは here を参照してください。
PSPKIAudit を使用したリスクのある設定の確認
PSPKIAudit ツールは、PKI インフラストラクチャを監査するのに役立ちます。PSPKIAudit を使用するには、単に GitHub からツールをダウンロードし、モジュールをインポートして Invoke-PKIAudit コマンドを実行してください。これにより、Active Directory から Certificate Authority を列挙し、その後、いくつかの既定のオプションについて問い合わせます。
以下に、このツールの出力結果を示すスクリーンショットをいくつか掲載します。そこでは、誤って設定された証明書や、CA における設定ミスが明らかになります。PSPKIAudit が本記事で扱っていない設定ミスを検出した場合は、 SpecterOps paper の修復(対応)の助言を確認してください。
結論
Active Directory Certificate Services への攻撃が、今後ますます増えていくことを予想しています。実際、 PetitPotam に ADCS NTLM Relaying を組み合わせた攻撃は、SpecterOps の論文が公開されて以来、すでに登場しています。そして SpecterOps は BlackHat 2021 で ForgeCert(証明書のゴールデンチケット)を公開する予定です。したがって、環境内の設定ミスを早急に確認し、速やかに是正したうえで、この手順を定期的に繰り返すことが重要です。
エンドツーエンドの保護のために、Netwrix Active Directory security solution をご検討ください。次のことに役立ちます:
- 詳細なリスク評価によって、セキュリティのギャップを先回りして特定します。
- 費用のかかるダウンタイムや業務の中断を最小限に抑えます。
- 高度な脅威であってもいち早く見つけ、迅速に対応します。
共有する
もっと詳しく
著者について
Joe Dibley
セキュリティリサーチャー
Netwrix のセキュリティリサーチャーであり、Netwrix Security Research Team のメンバーです。Joe は Active Directory、Windows、およびさまざまなエンタープライズソフトウェアのプラットフォームとテクノロジーの専門家であり、新たなセキュリティリスク、複雑な攻撃手法、そしてそれに関連する緩和策と検知について研究しています。