AD Certificate Services: Risikobehaftete Einstellungen und deren Behebung

Active Directory Certificate Services gibt es schon seit langem, aber die Ressourcen zum Erlernen sind nicht großartig. Infolgedessen gibt es oft Fehlkonfigurationen, die ein zunehmender Vektor für Angriffe sind. Tatsächlich hat SpecterOps ein Whitepaper veröffentlicht, das eine Reihe von Fehlkonfigurationen und potenziellen Angriffen detailliert beschreibt und Ratschläge zur Absicherung bietet. In diesem Blog behandle ich mehrere der Einstellungen, die fehlkonfiguriert sein können und wie man sie erkennt, biete mehrere Optionen zur weiteren Absicherung und erkläre, wie man ein kostenloses Tool verwendet, um Ihre Umgebung zu überprüfen.

Hintergrund

Wenn einem Identitätsnachweis ein auf Authentifizierung basierendes Zertifikat ausgestellt wird, kann das Zertifikat verwendet werden, um sich als die im Subject Alternative Name (SAN) festgelegte Identität zu authentifizieren; dies ist normalerweise ein UPN oder DNS-Name. Das Zertifikat wird dann anstelle eines Passworts für die Erstauthentifizierung verwendet. Der technische Referenzpunkt für diese Erstauthentifizierung ist RFC4556, wenn Sie mehr Details erfahren möchten.

Sobald ein authentifizierungsbasiertes Zertifikat ausgestellt wurde, kann es zur Authentifizierung als der Betreffende verwendet werden, bis es widerrufen oder abgelaufen ist. Dies wird Maßnahmenpläne für Zwischenfälle umgehen, die auf Strategien wie das Zurücksetzen des Benutzerpassworts beruhen, um einen Angreifer auszuschließen; der Angreifer kann dauerhaften Zugang zum Konto haben, es sei denn, die Zertifikate werden ebenfalls widerrufen.

Risikoreiche Vorlageneinstellungen

Hier sind einige der Zertifikatvorlageneinstellungen, die zu Fehlkonfigurationen führen können.

Auf Authentifizierung basierende EKUs

Zuerst suchen Sie nach Enhanced Key Usages (EKUs), die eine Art der Domänen-Authentifizierung ermöglichen. Hier ist eine kurze Liste:

• Any Purpose (2.5.29.37.0)
• SubCA (Keine)
• Client-Authentifizierung (1.3.6.1.5.5.7.3.2)
• PKINIT-Client-Authentifizierung (1.3.6.1.5.2.3.4)
• Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

Der einfachste manuelle Weg, um alle Ihre Zertifikatvorlagen zu finden, die dies zulassen, besteht darin, das Certificate Authority MMC Snap-in zu öffnen, sich mit Ihrer Certificate Authority zu verbinden, den Abschnitt Certificate Template anzusehen und die Spalte Intended Purpose nach einem dieser Authentifizierungs-EKUs zu durchsuchen. Zum Beispiel zeigt die untenstehende Abbildung, dass die Vorlagen Computer, Kopie von Smartcard-Anmeldung und beide Domain Controller-Vorlagen mindestens eines der PKUs enthalten.

Nachdem Sie die Vorlagen bearbeitet haben, die Sie finden, denken Sie daran, dass es auch Möglichkeiten gibt, normale Zertifikate zu missbrauchen. Zum Beispiel kann die Get-SmartCardCertificate-Funktion von PoshADCS eine Vorlage ändern, Zertifikate dafür anfordern und dann die Änderungen an der Vorlage rückgängig machen.

„Enrollee Supplies Subject“-Kennzeichnung

Wenn das Flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT im Eigenschaftsfeld mspki-certificate-name-flag vorhanden ist, kann der Anmelder des Zertifikats seinen eigenen alternativen Subject-Namen in der Zertifikatsignieranforderung angeben. Das bedeutet, dass jeder Benutzer, der berechtigt ist, ein Zertifikat mit dieser Einstellung zu beantragen, ein Zertifikat als beliebiger Benutzer im Netzwerk anfordern kann, einschließlich eines privilegierten Benutzers.

Sie können diese Markierung in der Zertifikatvorlagen-Konsole überprüfen; sie befindet sich unter dem Reiter „Subject Name“ als die Radio-Option „Supply in the request“:

Alternativ können Sie einen PowerShell-Befehl wie den folgenden verwenden, um die Vorlagen aus AD zu erhalten und zu überprüfen, ob das Flag im Zertifikat gesetzt ist:

      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 } }
      

Weiteres Reduzieren von Risiken

Neben der Korrektur von Zertifikatsfehlkonfigurationen sollten Sie die folgenden Optionen in Betracht ziehen, um die Ausstellung von Zertifikaten zu steuern.

Genehmigung des CA Certificate Manager oder autorisierte Unterschriften

Zuerst und wahrscheinlich am wichtigsten, schauen Sie auf den Reiter Ausstellungsanforderungen bei jedem Zertifikat, um zu sehen, ob es eine Genehmigung vom Certificate Authority (CA) Manager oder einem oder mehreren Autorisierten erfordert.

Das Aktivieren einer oder beider dieser Einstellungen kann das Risiko erheblich verringern, indem Überprüfungen vor der Ausstellung von Zertifikaten erforderlich gemacht werden. Wenn Sie sich nicht sicher sind, ob autorisierte Signaturen erforderlich sind, sollten Sie zumindest die Genehmigung des CA-Zertifikatmanagers verlangen; dann wird jedes Mal, wenn ein Zertifikat angefordert wird, dieses zur manuellen Überprüfung an die Zertifizierungsstelle gesendet, bevor es ausgestellt wird.

Berechtigungen für die Einschreibung

Zweitens, betrachten Sie die Einschreibeberechtigungen in jeder Vorlage, die auf dem Sicherheitstab gefunden werden können. Viele Fehlkonfigurationen sind kritisch, nur wenn generische Prinzipale oder große Gruppen diese Berechtigungen haben. Überprüfen Sie insbesondere auf Authentifizierte Benutzer, Domänenbenutzer und jede große Benutzergruppe, die keine Zertifikate anfordern dürfen; wenn Sie sie finden, erwägen Sie, deren Berechtigungen zum Einschreiben oder AutoEinschreiben zu widerrufen.

EDITF_ATTRIBUTESUBJECTALTNAME2-Registrierungsschlüssel

Zuletzt überprüfen Sie die Registrierungseinstellung EDITF_ATTRIBUTESUBJECALTNAME2. Diese Einstellung ist eine der interessantesten: Wenn sie auf der Zertifizierungsstelle aktiviert ist, dann kann jedes auf Authentifizierung basierende Zertifikat, das ausgestellt wird (einschließlich Zertifikate, bei denen das Subjekt automatisch aus Active Directory erstellt wird), benutzerdefinierte Werte im SAN enthalten.

Um diese Einstellung zu überprüfen, können Sie diesen Befehl ausführen:

      certutil –getreg policyEditFlags
      

Wenn EDITF_ATTRIBUTESUBJECALTNAME2 in der Ausgabeliste steht, sollten Sie es mit diesem Befehl entfernen:

      certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2
      

Weitere Anleitungen zu dieser Einstellung finden Sie hier.

Überprüfung auf riskante Einstellungen mit PSPKIAudit

The PSPKIAudit tool can help you audit your PKI infrastructure. To use PSPKIAudit, simply download the tool from GitHub, import the module and run the Invoke-PKIAudit command. This will enumerate the Certificate Authority from Active Directory and then query it for some of the default options.

Unten finden Sie ein paar Screenshots, die die Ausgabe dieses Tools zeigen, welches ein falsch konfiguriertes Zertifikat und Fehlkonfigurationen auf der CA offenlegt. Wenn PSPKIAudit irgendwelche Fehlkonfigurationen aufdeckt, die in diesem Beitrag nicht behandelt werden, schauen Sie im SpecterOps paper nach Ratschlägen zur Behebung.

Fazit

Ich erwarte eine zunehmende Anzahl von Angriffen auf Active Directory Certificate Services. Tatsächlich ist seit der Veröffentlichung des SpecterOps-Papiers bereits ein PetitPotam-Angriff mit ADCS NTLM Relaying aufgetreten, und SpecterOps veröffentlicht ForgeCert, das Golden Ticket der Zertifikate, auf der BlackHat 2021. Daher ist es dringend erforderlich, auf Fehlkonfigurationen in Ihrer Umgebung zu überprüfen und diese umgehend zu beheben und dann den Prozess regelmäßig zu wiederholen.

Für umfassenden Schutz sollten Sie die Netwrix Active Directory security solution in Betracht ziehen. Sie wird Ihnen helfen:

• Identifizieren Sie proaktiv Sicherheitslücken durch eine umfassende Risikobewertung.
• Minimieren Sie kostspielige Ausfallzeiten und Geschäftsunterbrechungen.
• Erkennen Sie selbst fortgeschrittene Bedrohungen umgehend und reagieren Sie schnell.