Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00

Translator workflow e90c803209 Translated to Japanese

2023-07-07 23:42:27 +00:00

27 KiB

Raw Blame History

AD証明書

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

サイバーセキュリティ企業で働いていますか？ HackTricksで会社を宣伝したいですか？または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！
The PEASS Familyを見つけてください。独占的なNFTのコレクションです。
公式のPEASS＆HackTricksグッズを手に入れましょう。
💬 Discordグループまたはtelegramグループに参加するか、Twitterでフォローしてください🐦@carlospolopm。
ハッキングのトリックを共有するには、PRを hacktricks repo と hacktricks-cloud repo に提出してください。

基本情報

証明書のパーツ

Subject - 証明書の所有者。
Public Key - Subjectを個別に保存された秘密鍵と関連付けます。
NotBeforeとNotAfterの日付 - 証明書の有効期間を定義します。
Serial Number - CAによって割り当てられた証明書の識別子。
Issuer - 証明書を発行したものを識別します（一般的にはCA）。
SubjectAlternativeName - Subjectが使用することができる1つ以上の代替名を定義します（以下を確認してください）。
Basic Constraints - 証明書がCAまたはエンドエンティティであるか、証明書を使用する際の制約があるかを識別します。
Extended Key Usages（EKU） - 証明書の使用方法を説明するオブジェクト識別子（OID）。Microsoftの用語ではEnhanced Key Usageとも呼ばれます。一般的なEKU OIDには次のものがあります：
Code Signing（OID 1.3.6.1.5.5.7.3.3）- 証明書は実行可能なコードに署名するためです。
Encrypting File System（OID 1.3.6.1.4.1.311.10.3.4）- 証明書はファイルシステムを暗号化するためです。
Secure Email（1.3.6.1.5.5.7.3.4）- 証明書は電子メールを暗号化するためです。
Client Authentication（OID 1.3.6.1.5.5.7.3.2）- 証明書は別のサーバー（例：ADへの認証）への認証に使用されます。
Smart Card Logon（OID 1.3.6.1.4.1.311.20.2.2）- 証明書はスマートカード認証に使用されます。
Server Authentication（OID 1.3.6.1.5.5.7.3.1）- 証明書はサーバーを識別するためです（例：HTTPS証明書）。
Signature Algorithm - 証明書に署名するために使用されるアルゴリズムを指定します。
Signature - 発行者（例：CA）の秘密鍵を使用して作成された証明書の本体の署名。

Subject Alternative Names

Subject Alternative Name（SAN）はX.509v3拡張です。これにより、証明書に追加の識別子をバインドすることができます。たとえば、ウェブサーバーが複数のドメインのコンテンツをホストする場合、各ドメインがSANに含まれるようにして、ウェブサーバーは単一のHTTPS証明書のみを必要とします。

デフォルトでは、証明書ベースの認証中に、ADはSANで指定されたUPNに基づいて証明書をユーザーアカウントにマッピングします。攻撃者がクライアント認証を有効にするEKUを持つ証明書を要求する際に任意のSANを指定し、CAが攻撃者が指定したSANを使用して証明書を作成して署名する場合、攻撃者はドメイン内の任意のユーザーになることができます。

CA

AD CSは、ADフォレストが信頼するCA証明書をCN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>の下に4つの場所で定義します。それぞれの目的によって異なります。

Certification Authoritiesコンテナは信頼されたルートCA証明書を定義します。これらのCAはPKIツリー階層のトップにあり、AD CS環境での信頼の基盤です。各CAは、certificationAuthorityというobjectClassが設定され、cACertificateプロパティにはCAの証明書のバイトが含まれています。WindowsはこれらのCA証明書を各WindowsマシンのTrusted Root Certification Authorities証明書ストアに伝播します。ADが証明書を信頼するためには、証明書の信頼チェーンが最終的にこのコンテナで定義されたルートCAのいずれかで終了する必要があります。
Enrolment Servicesコンテナは、Enterprise CA（つまり、AD CSでEnterprise CAロールが有効になっているCA）を定義します。各Enterprise CAには、次の属性を持つADオブジェクトがあります：
pKIEnrollmentServiceにobjectClass属性
CAの証明書のバイトを含む**cACertificate**属性
CAのDNSホストを設定する**dNSHostName**プロパティ
有効な証明書テンプレートを定義するcertificateTemplatesフィールド。証明書テンプレートは、証明書の作成時にCAが使用する設定の「設計図」であり、EKU、登録許可、証明書の有効期限、発行要件、暗号設定などが含まれます。証明書テンプレートについては後ほど詳しく説明します。

{% hint style="info" %} AD環境では、**クライアントは証明書テンプレートで定義され

AIA（Authority Information Access）コンテナには、中間およびクロスCAのADオブジェクトが格納されています。中間CAはルートCAの「子」であり、このコンテナは証明書チェーンの検証を支援するために存在します。認証機関コンテナと同様に、各CAはADオブジェクトとして表され、オブジェクトクラス属性がcertificationAuthorityに設定され、cACertificateプロパティにはCAの証明書のバイトが含まれています。これらのCAは、Windowsマシンの中間認証機関証明書ストアに伝播されます。

クライアント証明書リクエストのフロー

これはAD CSから証明書を取得するプロセスです。大まかに言うと、登録時にクライアントはまず上記で説明した登録サービスのオブジェクトに基づいてエンタープライズCAを見つけます。

クライアントは公開-秘密鍵ペアを生成し、
クライアントは、証明書のサブジェクトや証明書テンプレート名などの他の詳細と共に、証明書署名リクエスト（CSR）メッセージに公開鍵を配置します。クライアントはその後、CSRをプライベートキーで署名し、CSRをエンタープライズCAサーバーに送信します。
CAサーバーは、クライアントが証明書を要求できるかどうかをチェックします。そうであれば、CSRで指定された証明書テンプレートADオブジェクトを参照して、証明書テンプレートのADオブジェクトのアクセス許可が認証アカウントが証明書を取得できるかどうかを確認します。
もし許可されていれば、CAは証明書を生成し、証明書テンプレートで定義された「設計図」の設定（例：EKU、暗号化設定、発行要件）を使用し、CSRで提供された他の情報を証明書のテンプレート設定で許可されている場合に使用します。CAはプライベートキーで証明書に署名し、それをクライアントに返します。

証明書テンプレート

AD CSは、次のコンテナにある**pKICertificateTemplateというobjectClass**を持つADオブジェクトとして利用可能な証明書テンプレートを保存します。

CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>

AD証明書テンプレートオブジェクトの属性は、その設定を定義し、セキュリティ記述子は証明書を登録することができる主体または証明書テンプレートを編集することができる主体を制御します。

AD証明書テンプレートオブジェクトの**pKIExtendedKeyUsage属性には、テンプレートで有効になっているOIDの配列が含まれています。これらのEKU OIDは、証明書の使用目的に影響を与えます**。ここで可能なOIDのリストを見つけることができます。

認証用のOID

1.3.6.1.5.5.7.3.2：クライアント認証
1.3.6.1.5.2.3.4：PKINITクライアント認証（手動で追加する必要があります）
1.3.6.1.4.1.311.20.2.2：スマートカードログオン
2.5.29.37.0：任意の目的
（EKUなし）：サブCA
追加の悪用できるEKU OIDは、証明書リクエストエージェントOID（1.3.6.1.4.1.311.20.2.1）です。このOIDを持つ証明書は、特定の制限が設定されていない限り、他のユーザーの代わりに証明書を要求するために使用できます。

証明書の登録

管理者はまず証明書テンプレートを作成し、その後エンタープライズCAがテンプレートを**「公開」**して、クライアントが登録できるようにします。AD CSでは、証明書テンプレートがエンタープライズCAで有効になるように、テンプレートの名前をADオブジェクトのcertificatetemplatesフィールドに追加することで指定されます。

{% hint style="warning" %} AD CSは、証明書を要求できる主体を定義するために、証明書テンプレートADオブジェクトとエンタープライズCA自体の2つのセキュリティ記述子を使用します。
証明書を要求できるためには、クライアントは両方のセキュリティ記述子に付与される必要があります。 {% endhint %}

証明書テンプレートの登録権限

ACEは主体にCertificate-Enrollment拡張権限を付与します。raw ACEは、ObjectTypeが0e10c968-78fb-11d2-90d4-00c04f79dc5547に設定されたRIGHT_DS_CONTROL_ACCESS45アクセス権を主体に付与します。このGUIDはCertificate-Enrollment拡張権限に対応します。
ACEは主体にCertificate-AutoEnrollment拡張権限を付与します。raw ACEは、ObjectTypeがa05b8cc2-17bc-4802-a710-e7c15ab866a249に設定されたRIGHT_DS_CONTROL_ACCESS48アクセス権を主体に付与します。このGUIDはCertificate-AutoEnrollment拡張権限に対応します。
ACEは主体にすべてのExtendedRightsを付与します。raw ACEは、ObjectTypeが00000000-0000-0000-0000-000000000000に設定されたRIGHT_DS_CONTROL_ACCESSアクセス権を有効にします。このGUIDはすべての拡張権限に対応します。
ACEは主体にFullControl/GenericAllを付与します。raw ACEは、FullControl/GenericAllアクセス権を有効にします。

エンタープライズCAの登録権限

エンタープライズCAに設定されたセキュリティ記述子は、証明書機関MMCスナップインcertsrv.mscでCAを右クリックしてプロパティ→セキュリティを表示することで確認できます。

これにより、CAサーバーの**HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration<CA NAME>**キーのSecurityレジストリ値が設定されます。私たちは、いくつかのAD CSサーバーで、低特権ユーザーがリモートレジストリを介してこのキーに対するリモートアクセス権限を付与されていることを確認しました。

低特権ユーザーは、ICertAdminD2 COMインターフェースのGetCASecurityメソッドを使用して、DCOMを介してこれを列挙することもできます。ただし、通常のWindowsクライアントは、COMインターフェースとそれを実装するCOMオブジェク

発行要件

証明書を取得できる人を制御するために、他の要件が存在する場合があります。

マネージャーの承認

CA証明書マネージャーの承認により、証明書テンプレートはADオブジェクトのmsPKI-EnrollmentFlag属性のCT_FLAG_PEND_ALL_REQUESTS（0x2）ビットを設定します。これにより、テンプレートに基づくすべての証明書リクエストが保留状態になります（certsrv.mscの「保留中のリクエスト」セクションで表示されます）。証明書が発行される前に、証明書マネージャーがリクエストを承認または拒否する必要があります。

登録エージェント、承認署名、およびアプリケーションポリシー

承認署名の数とアプリケーションポリシーが設定されることもあります。前者は、CAが受け入れるためにCSRに必要な署名の数を制御します。後者は、CSRの署名証明書が持っている必要のあるEKU OIDを定義します。

これらの設定の一般的な使用法は、登録エージェントです。登録エージェントは、他のユーザーの代わりに証明書をリクエストできるAD CS用語です。そのためには、CAは登録エージェントアカウントに、少なくとも証明書リクエストエージェントEKU（OID 1.3.6.1.4.1.311.20.2.1）を含む証明書を発行する必要があります。発行された後、登録エージェントは他のユーザーのためにCSRに署名し、証明書をリクエストすることができます。CAは、以下の非網羅的な一連の条件（主にデフォルトのポリシーモジュールcertpdef.dllで実装されています）の下で、登録エージェントに別のユーザーとして証明書を発行します。

CAに認証するWindowsユーザーが、対象の証明書テンプレートに対する登録権限を持っている場合。
証明書テンプレートのスキーマバージョンが1の場合、CAは証明書の発行前に署名証明書に証明書リクエストエージェントOIDが必要です。テンプレートのスキーマバージョンは、ADオブジェクトのmsPKI-Template-Schema-Versionプロパティで指定されます。
証明書テンプレートのスキーマバージョンが2の場合：
テンプレートは「承認署名の数」設定を行い、指定された数の登録エージェントがCSRに署名する必要があります（テンプレートのmspkira-signature AD属性がこの設定を定義します）。つまり、この設定は、CAが証明書を発行する前にいくつの登録エージェントがCSRに署名する必要があるかを指定します。
テンプレートの「アプリケーションポリシー」発行制限は「証明書リクエストエージェント」に設定する必要があります。

証明書のリクエスト

Windowsのクライアント証明書登録プロトコル（MS-WCCE）を使用して、さまざまなAD CSの機能（登録を含む）と対話する一連の分散コンポーネントオブジェクトモデル（DCOM）インターフェースを介して証明書をリクエストします。DCOMサーバーはデフォルトですべてのAD CSサーバーで有効になっており、クライアントが証明書をリクエストする最も一般的な方法です。
ICertPassageリモートプロトコル（MS-ICPR）を介したリモートプロシージャコール（RPC）プロトコルは、名前付きパイプまたはTCP/IP上で動作することができます。
証明書登録Webインターフェースにアクセスします。これを使用するには、ADCSサーバーに証明書機関Web登録ロールをインストールする必要があります。有効になると、ユーザーはhttp:///certsrv/で実行されているIISホストされたASP Web登録アプリケーションに移動できます。

certipy req -ca 'corp-DC-CA' -username john@corp.local -password Passw0rd -web -debug

証明書登録サービス（CES）との対話。これを使用するには、サーバーに証明書登録Webサービスロールをインストールする必要があります。有効になると、ユーザーはhttps:///_CES_Kerberos/service.svcでWebサービスにアクセスして証明書をリクエストできます。このサービスは、証明書登録ポリシー（証明書登録ポリシーウェブサービスロールを介してインストールされる）と連携して動作し、クライアントはURL https:///ADPolicyProvider_CEP_Kerberos/service.svc で証明書テンプレートをリストするために使用します。証明書登録およびポリシーウェブサービスは、それぞれMS-WSTEPおよびMS-XCEP（SOAPベースのプロトコル）を実装しています。
ネットワークデバイス登録サービスを使用します。これを使用するには、サーバーにネットワークデバイス登録サービスロールをインストールする必要があります。これにより、クライアント（主にネットワークデバイス）がシンプル証明書登録プロトコル（SCEP）を介して証明書を取得できます。有効になると、管理者はURL http:///CertSrv/mscep_admin/からワンタイムパスワード（OTP）を取得できます。管理者はOTPをネットワークデバイスに提供し、デバイスはURL http://NDESSERVER/CertSrv/mscep/を使用してSCEPを使用して証明書をリクエストします。

Windowsマシンでは、ユーザーはGUIを使用して証明書をリクエストできます。ユーザー証明書の場合はcertmgr.mscを起動し、パーソナル証明書ストアを展開してCertificatesを右クリックし、All Tasksを選択し、Request New Certificateを選択します。

証明書の登録には、組み込みの**certreq.exeコマンドまたはPowerShellのGet-Certificate**コマンドも使用できます。

証明書の認証

ADはデフォルトで2つのプロトコルを介した証明書認証をサポートしています：KerberosとSecure Channel（Schannel）。

Kerberos認証とNTAuthCertificatesコンテナ

要約すると、ユーザーは自分の証明書の秘密鍵を使用してTGTリクエストの認証

セキュアチャネル（Schannel）認証

Schannelは、TLS/SSL接続を確立する際にWindowsが利用するセキュリティサポートプロバイダ（SSP）です。Schannelは、クライアント認証（その他多くの機能の中で）をサポートし、リモートサーバが接続するユーザの身元を確認することができます。これは、証明書を主要な資格情報として使用するPKIを使用して行われます。
TLSハンドシェイク中、サーバは認証のためにクライアントから証明書を要求します。サーバが信頼するCAからクライアント認証証明書を事前に発行されたクライアントは、証明書をサーバに送信します。サーバはその後、証明書が正しいことを検証し、すべてが正常であればユーザにアクセスを許可します。

ADに証明書を使用してアカウントが認証される場合、DCは証明書の資格情報をADアカウントにマッピングする必要があります。Schannelは、最初にKerberosのS4U2Self機能を使用して資格情報をユーザアカウントにマッピングしようとします。
それが失敗した場合、証明書をユーザアカウントにマッピングするために、証明書のSAN拡張、サブジェクトと発行者のフィールドの組み合わせ、または発行者のみを使用します。デフォルトでは、AD環境の多くのプロトコルは、Schannelを使用したAD認証をそのままサポートしていません。WinRM、RDP、およびIISは、Schannelを使用したクライアント認証をサポートしていますが、追加の設定が必要であり、WinRMのような場合はActive Directoryと統合されていません。
一般的に動作するプロトコルは、AD CSがセットアップされている場合にLDAPSです。コマンドレットGet-LdapCurrentUserは、.NETライブラリを使用してLDAPに認証する方法を示しています。このコマンドレットは、LDAPの「Who am I？」拡張操作を実行して現在認証中のユーザを表示します。

AD CS列挙

ADのほとんどの情報と同様に、これまでにカバーした情報は、ドメイン認証されたが特権のないユーザとしてLDAPをクエリすることで利用できます。

エンタープライズCAとその設定を列挙するには、CN=Configuration,DC=<domain>,DC=<com>の検索ベース（この検索ベースはADフォレストの構成名前空間に対応します）でLDAPをクエリし、(objectCategory=pKIEnrollmentService)のLDAPフィルタを使用します。結果には、CAサーバのDNSホスト名、CA名自体、証明書の開始日と終了日、さまざまなフラグ、公開された証明書テンプレートなどが表示されます。

脆弱な証明書を列挙するためのツール:

Certifyは、AD CS環境に関する有用な設定とインフラ情報を列挙し、さまざまな方法で証明書を要求できるC#ツールです。
Certipyは、Active Directory証明書サービス（AD CS）を任意のシステム（DCへのアクセス権がある）から列挙および悪用できるPythonツールで、Lyak（良い人で優れたハッカー）が作成したBloodHoundの出力を生成できます。

# https://github.com/GhostPack/Certify
Certify.exe cas #enumerate trusted root CA certificates, certificates defined by the NTAuthCertificates object, and various information about Enterprise CAs
Certify.exe find #enumerate certificate templates
Certify.exe find /vulnerable #Enumerate vulenrable certificate templater

# https://github.com/ly4k/Certipy
certipy find -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128
certipy find -vulnerable [-hide-admins] -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128 #Search vulnerable templates

certutil.exe -TCAInfo #enumerate Enterprise CAs
certutil -v -dstemplate #enumerate certificate templates

参考文献