# Certifried セキュリティ脆弱性

Certifried は、2022年5月に公開されたセキュリティ脆弱性で、 [CVE-2022-26921](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26921) および [CVE-2022-26923](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26923). [Oliver Lyak は、特権昇格の脆弱性について説明しました](https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4) 彼は証明書認証を使って発見したと述べています。攻撃者は、Domain Controller コンピューターアカウントとして認証できる証明書を登録し、それによって AD ドメイン（接続されている場合は AAD テナントも）を乗っ取れる可能性があると説明しています。Microsoft はこれらの脆弱性に対し [KB5014754 のパッチ](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap)で対処しました。この記事では、これが SCEPman を運用している組織にどのような影響を与えるか、また SCEPman がどのようにこのセキュリティ問題の軽減に役立つかを説明します。

## 概要

* SCEPman の証明書は、ほとんどの場合 Certifried 攻撃には使用できません
* SCEPman を使用すると Certifried 攻撃の軽減に役立ちます。というのも、Microsoft CA の証明書とは異なり、SCEPman CA の証明書は通常 NTAuth ストアに存在している必要がないためです
* Microsoft のパッチは、ほとんどの場合 SCEPman のインストールには影響しません。そのような場合は、Full Enforcement モードを有効にするのがよいでしょう。

## Microsoft のパッチの影響

パッチ [KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap) は、既定では監査イベントをいくつか追加するだけです。Full Enforcement モードは、2025年2月11日に開始されます。あるいは、手動で有効にすればそれより早く開始されます。Full Enforcement モードでは、証明書は、アカウントの SID を含む場合、またはユーザー証明書の場合は AD オブジェクトにその特定の証明書への参照が含まれている場合にのみ、ユーザーおよびデバイス認証に使用できます。前者には新しい独自の X.509 拡張が必要で、後者は Certificate Mapping と呼ばれ altSecurityIdentities 属性を使用します。

一般的に言えば、これは AD 認証にのみ影響します。これには CA 証明書をフォレストの NTAuth ストアに追加する必要があります。既定では、これを明示的かつ手動で行わない限り、SCEPman は NTAuth ストアに追加されません。まだこれを行っておらず、今後も行う予定がない場合、パッチは SCEPman インスタンスに影響しません。SCEPman Docs では、SCEPman CA 証明書を NTAuth ストアに追加することを推奨しているユースケースが1つあります。それは、次のことを行いたい場合です [SCEPman に Kerberos Authentication 用の Domain Controller 証明書を発行させる](https://docs.scepman.com/ja/zheng-ming-shu-guan-li/domain-controller-certificates#trust-the-ca-certificate-in-the-domain-for-kerberos-authentication).

### Intune デバイス証明書

デバイス証明書は [Windows Hello for Business Certificate Trust](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust)に使用できる可能性があります。Certificate Trust に使用するためにデバイス証明書へ AD DNS 名を追加している場合、影響を受ける可能性があります。これには AAD と AD の両方にデバイス オブジェクトが必要です。このまれなユースケースでは、次への切り替えを推奨します [WHfB Cloud Trust](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust).

### Intune ユーザー証明書

ユーザー証明書は Windows Hello for Business Certificate Trust に使用できます。さらに、ドメイン参加済みマシンへの RDP セッションや NPS に基づく WiFi 認証など、証明書ベースの AD 認証の他の方法にも使用できます。これを行いたい場合は、設定 [AppConfig:AddSidExtension](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/certificates#appconfig-addsidextension) を使用して、SCEPman に Strong Certificate Mapping 証明書を作成させることができます。AD と Entra ID の間で同期されたユーザー向けのユーザー証明書には、OID 1.3.6.1.4.1.311.25.2 の拡張が自動的に付与され、AD ユーザーへ強くマッピングされます。\
さらに Intune チームは [SAN 値を追加する](https://docs.scepman.com/ja/scepman-gou-cheng/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates) Strong Certificate Mapping を実装する予定です。この方法は SID 拡張の代替としても使用できます。

### DC 証明書

Domain Controller 証明書はこの脆弱性の影響を受けず、したがって一般にパッチの影響も受けません。DC 証明書が Client Authentication に使用されている場合がありますが、これは以前は許可されていました。Full Enforcement が有効になると、これは使用できなくなります。パッチ適用後に [監査イベント](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_auditevents) を確認し、これが影響するかどうかを調べてください。ほとんどの場合、問題にはならないはずです。

## SCEPman 証明書を使った攻撃

Certifried 攻撃は、NTAuth ストアにある CA 証明書でのみ使用できます。既定では、SCEPman CA 証明書はこれに該当しません。したがって、Microsoft Active Directory Certificate Services の代わりに Intune 経由で証明書を登録するために SCEPman を使用している場合、環境はこの攻撃に対して免疫がある可能性が高いです。ただし、SCEPman が Domain Controller 証明書を発行している場合は、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 を証明書に入れることはできません。さらに [Strong Certificate Mapping](https://docs.scepman.com/ja/scepman-gou-cheng/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates)を使用している場合、UPN が変更されても別のアカウントでは証明書が機能しないことを নিশ্চিতできます。

### Intune デバイス証明書

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

したがって、同じ SCEPman インスタンスを DC 証明書にも使用する場合は、デバイス名のようなユーザー制御可能なデータに基づく DNS 名エントリを、オンプレミス ドメインでも使用されているドメイン名と組み合わせて追加してはいけません。これがどうしても必要な場合は、昇格攻撃を防ぐために Full Enforcement モードを有効にする必要があります。あるいは、DC 証明書用と Intune 登録用で、2つの別々の 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 サーバー証明書**](https://docs.scepman.com/ja/zheng-ming-shu-guan-li/certificate-master/tls-server-certificate-pkcs-12) は、EKU として Smart Card Logon も Client Authentication も含まないため、影響を受けません。

[**手動クライアント証明書**](https://docs.scepman.com/ja/zheng-ming-shu-guan-li/certificate-master/client-certificate-pkcs-12) も影響を受けません。Client Authentication EKU は含まれますが、DNS SAN エントリはありません。

[**カスタム CSR リクエスト**](https://docs.scepman.com/ja/zheng-ming-shu-guan-li/certificate-master/certificate-signing-request-csr) は自由に構成でき、認証証明書を含みます。Certificate Master アプリケーションにアクセスできる人なら誰でもそのような証明書を発行できるため、少なくとも次のいずれかの対策を取るべきです:

* 特権アカウントのみが Certificate Master にアクセスできるようにしてください。たとえば、 [Certificate Master コンポーネントへのアクセスを許可する](https://docs.scepman.com/ja/scepman-zhan-kai/permissions/post-installation-config#granting-the-rights-to-request-certificates-via-the-certificate-master-website) AAD グループを1つだけに限定し、そのグループを [特権アクセス グループ](https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/groups-features).
* として設計することができます。
* AD ドメインで Full Enforcement モードを有効にしてください。

### Domain Controller 証明書

攻撃者が Domain Controller 証明書を発行するために必要なアクセス権を持っているなら、その攻撃者はおそらくすでに Domain Controller を制御しており、ドメインの所有権も持っています。攻撃者には Certifried 攻撃は必要ありません。