Certifried セキュリティ脆弱性

Certifriedは2022年5月に公開されたセキュリティ脆弱性で、 CVE-2022-26921 および CVE-2022-26923. Oliver Lyakは証明書認証を利用して発見した特権昇格の脆弱性を説明しました。 彼は、攻撃者が証明書を登録してドメインコントローラーのコンピュータアカウントとして認証できるようにし、それによってADドメイン（接続されている場合はAADテナントも）を乗っ取る可能性があると説明しています。Microsoftは以下の方法で脆弱性に対処しました： KB5014754のパッチ。この記事では、これがSCEPmanを実行している組織にどのように影響するか、そしてSCEPmanがどのようにこのセキュリティ問題の緩和に役立つかを説明します。

要約

• 多くの場合、SCEPmanの証明書はCertifried攻撃に利用できません

• SCEPmanを使用することはCertifried攻撃の緩和に役立ちます。なぜならMicrosoft CA証明書とは異なり、SCEPmanのCA証明書は通常NTAuthストアに置く必要がないためです。

• Microsoftのパッチは多くの場合SCEPmanの導入には影響しません。そのようなケースでは、Full Enforcementモードを有効にするのが良い考えです。

Microsoftのパッチの影響

のパッチは、 KB5014754 デフォルトでは追加の監査イベントをいくつか追加するだけです。Full Enforcementモードは2025年2月11日に開始されます—または手動で有効化した場合はそれより早く開始されます。Full Enforcementモードでは、証明書がユーザーおよびデバイス認証に使用できるのは、アカウントのSIDを含むか、ユーザー証明書の場合はユーザーのADオブジェクトが特定の証明書への参照を含む場合のみです。前者は新しい独自のX.509拡張を必要とし、後者はCertificate Mappingと呼ばれ、altSecurityIdentities属性を使用します。

一般的に言えば、これはAD認証にのみ影響します。これはCA証明書をフォレストのNTAuthストアに追加することを要求します。デフォルトでは、明示的かつ手動で行わない限りSCEPmanはNTAuthストアに追加されません。もしまだこれを行っておらず、行う予定もないなら、パッチはあなたのSCEPmanインスタンスには影響しません。SCEPmanのドキュメントがSCEPmanのCA証明書をNTAuthストアに追加することを推奨するユースケースが一つあり、それは次のような場合です： SCEPmanにKerberos認証用のドメインコントローラー証明書を発行させたいとき.

Intune デバイス証明書

デバイス証明書は以下のために使用できる可能性があります： Windows Hello for Business 証明書トラスト。デバイス証明書にADのDNS名を追加してCertificate Trustに使用していた場合、影響を受ける可能性があります。これはAADとADの両方にデバイスオブジェクトを必要とします。このまれなユースケースについては、次への切替を推奨します： WHfB Cloud Trust.

Intune ユーザー証明書

ユーザー証明書はWindows Hello for Businessの証明書トラストに使用できます。また、ドメイン参加マシンへのRDPセッションやNPSに基づくWiFi認証など、証明書ベースの他のAD認証方法に使われることもあります。これを行いたい場合は、SCEPmanが強い証明書マッピング証明書を作成できるように設定 AppConfig:AddSidExtension を使用できます。ADとEntra IDの間で同期されたユーザーのユーザー証明書は、自動的にOID 1.3.6.1.4.1.311.25.2を持つ拡張を受け取り、ADユーザーに強くマップされます。 さらにIntuneチームは SAN値を追加する計画 を持っており、強い証明書マッピングを実装する予定です。SID拡張の代替としてこの方法を使うこともできます。

DC証明書

ドメインコントローラー証明書は脆弱性の影響を受けず、したがって一般的にはパッチの影響も受けません。以前は許可されていたクライアント認証にDC証明書が使われていることがあります。Full Enforcementが有効化されるとこれはもはや機能しません。パッチ適用後に 監査イベント を確認して、これがあなたに影響するかどうかを判断してください。ほとんどの場合、問題にはならないはずです。

SCEPman証明書を使った攻撃

Certifried攻撃はNTAuthストアのCA証明書でのみ使用できます。デフォルトではSCEPmanのCA証明書はそうなっていません。したがって、Microsoft Active Directory Certificate ServicesではなくIntune経由でSCEPmanを使用して証明書を登録している場合、あなたの環境はこの攻撃に対して免疫である可能性が高いです。しかし、SCEPmanがドメインコントローラー証明書を発行している場合、SCEPmanのCA証明書はNTAuthストアにあり、読み進めるべきです。

攻撃者は、Subject Alternative Name（SAN）拡張に偽造されたUPNとExtended Key Usage（EKU）でSmart Card Logonを含む証明書、あるいはSANに偽造されたDNS名とEKUでClient Authenticationを含む証明書のいずれかを必要とします。

Intune ユーザー証明書

攻撃者がAADのユーザーアカウントを制御してSCEPmanにユーザー証明書を登録させるとします。攻撃者はどのようにしてSCEPmanに攻撃に使える証明書を発行させることができるでしょうか？

ユーザー証明書には通常EKUのClient Authenticationが含まれます。しかし、推奨に従っていればSANにDNS名は含まれません。したがって、これらの証明書は使用できません。

EKUにSmart Card Logonを設定している場合、その証明書は認証に使用できますが、UPNに記載されたアカウントに対してのみ有効です。UPNはAADから来て検証されるため、攻撃者が既に持っていないアカウントのUPNを証明書に入れることはできません。もしあなたがさらに 強力な証明書マッピングを使用しているなら、UPNが変更された場合に証明書が別のアカウントで機能しないことを保証できます。

Intune デバイス証明書

基本的な推奨に従えば、デバイス証明書はEKUのClient Authenticationを持ちます。SANにはURIエントリが含まれており、これはエクスプロイトには使用できません。しかし、追加でDNS名をSANに入れることもできます。例えば DeviceName.contoso.com のようにです。もしSCEPmanのCA証明書をNTAuthストアにインポートしていれば、これらの証明書を使用して同じDNS名のデバイスとしてオンプレミスで認証することが可能です。ユーザーはデバイス名を自由に定義できるため、デバイス名を"PrimaryDomainController"と名付けて、たとえそのようなコンピュータが既にADに存在していてもPrimaryDomainController.contoso.comとしてオンプレミスで認証できてしまう可能性があります。これはSCEPman固有の問題ではなく、NDESのような他のSCEP実装にも影響します。

したがって、同じSCEPmanインスタンスをDC証明書にも使用している場合は、ユーザーが制御するデータ（例：デバイス名）に基づくDNS名エントリを、オンプレミスドメインに使われているドメイン名で追加すべきではありません。もしこれが必要であれば、昇格攻撃を防ぐためにFull Enforcementモードを有効にする必要があります。あるいは、DC証明書用とIntune登録用で別々のSCEPmanインスタンスを運用することもできます。

Jamf Pro ユーザーおよびデバイス証明書

Jamf Pro経由で発行された証明書はEKUのClient Authenticationを持ちます。当社のドキュメントに従う場合、いかなる種類の証明書もSANにDNS名を持ちません。したがって、これらの証明書はCertifried攻撃には利用できません。例えばDC証明書を発行しているためにSCEPmanのCAがADのNTAuthStoreにある場合は、SANにDNS名を追加しないか、ADドメインでFull Enforcementモードを有効にすることを確認してください。

Certificate Master 証明書

SCEPmanバージョン2.1時点では、Certificate Masterコンポーネントを通じて証明書を発行する方法は3つあります。

TLSサーバー証明書 はEKUとしてSmart Card LogonもClient Authenticationも含まないため影響を受けません。

手動クライアント証明書 も影響を受けません。これらはClient AuthenticationのEKUを含みますが、DNSのSANエントリはありません。

カスタムCSRリクエスト は自由に設定でき、認証用証明書を含みます。Certificate Masterアプリケーションにアクセスできる誰でもそのような証明書を発行できる可能性があるため、少なくとも次のいずれかの予防措置を講じるべきです：

• Certificate Masterにアクセスできるのは特権アカウントのみであることを確認してください。例えば、 Certificate Masterコンポーネントへのアクセスを付与する のを1つのAADグループのみに限定し、これを 特権アクセスグループ.

• として設計することができます。DC証明書（そのCA証明書がNTAuthストアにある）とCertificate Master用に別々のSCEPmanインスタンスとCA証明書を使用してください。

• ADドメインでFull Enforcementモードを有効にしてください。

ドメインコントローラー証明書

もし攻撃者がドメインコントローラー証明書を発行するための必要な権限を持っているなら、その攻撃者はおそらく既にドメインコントローラーを制御しており、ドメインを掌握しています。その場合、攻撃者はCertifried攻撃を必要としません。