Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln

Im Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle" habe ich beschrieben, wie sich ein Angreifer, der im Besitz administrativer Rechte auf der Zertifizierungsstelle ist, unter Umgehung der Zertifizierungsstellen-Software, also unter direkter Verwendung des privaten Schlüssels der Zertifizierungsstelle, ein Anmeldezertifikat für administrative Konten der Domäne erzeugen kann.

Im vorigen Artikel habe ich das PSCertificateEnrollment Powershell Modul verwendet, um das Vorgehen zu demonstrieren. Microsoft liefert mit certreq und certutil allerdings bereits ab Werk perfekt geeignete Pentesting-Werkzeuge direkt mit dem Betriebssystem mit.

„Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln“ weiterlesen

Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für Microsoft Active Directory Certificate Services

Als Betreiber einer Zertifizierungsstelle ist man (unter Anderem) für die Identifikation der Antragsteller und die Bestätigung der beantragten Identitäten verantwortlich. Dass diese Aufgabe gewissenhaft und fehlerfrei ausgeführt wird, ist der zentrale Grundpfeiler für das Vertrauen, dass der Zertifizierungsstelle eingeräumt wird. Namhafte Firmen sind bereits an dieser Aufgabe gescheitert, mussten in Folge von Falschausstellungen sogar Insolvenz anmelden und/oder wurden durch die großen Player am Markt empfindlich bestraft.

In vielen Fällen sind wir als (Microsoft-)PKI-Betreiber in Unternehmen (ungeachtet der damit einhergehenden Qualität) in der Lage, unsere Aufgabe der eindeutigen Identifikation eines Antragstellers an das Active Directory zu delegieren. In vielen Fällen müssen wir unsere Zertifizierungsstelle(n) aber auch anweisen, einfach alles auszustellen, was beantragt wird.

„Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für Microsoft Active Directory Certificate Services“ weiterlesen

Aktivieren der Basic Authentication für den Registrierungsdienst für Netzwerkgeräte (NDES)

Wird der Registrierungsdienst für Netzwerkgeräte (NDES) neu installiert (Vorzugsweise ohne Enterprise Administrator Berechtigungen), wird zunächst nur die Windows-integrierte Authentisierung für die Administrations-Webseite aktiviert. Mit dieser ist (per NT LAN Manager, NTLM) Protokoll auch eine Authentisierung per Benutzername und Passwort möglich. Nicht alle Client-Anwendungen unterstützen diese jedoch.

Ebenso könnte ein Unternehmen gewillt sein, NTLM wo möglich zu deaktivieren und Kerberos für die Anmeldung zu erzwingen. Mit dem Erzwingen von Kerberos fällt die Möglichkeit weg, sich per Benutzername und Passwort an der Administrations-Seite für den Registrierungsdienst für Netzwerkgeräte anzumelden (da dies mit NTLM-Anmeldedaten erfolgt). Um hier wieder eine Möglichkeit zu schaffen, kann jedoch die Basic Authentication nachgerüstet werden.

Einen Ausweg aus diesem Dilemma kann die Basic Authentisierung sein, deren Einrichtung im folgenden dargelegt werden soll.

„Aktivieren der Basic Authentication für den Registrierungsdienst für Netzwerkgeräte (NDES)“ weiterlesen

Deaktivieren von NTLM und erzwingen von Kerberos an der Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES)

Viele Unternehmen verfolgen die Strategie, das NT LAN Manager (NTLM) Authentisierungsprotokoll in ihren Netzwerken (weitestgehend) abzuschalten.

Auch für die Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES) ist dies möglich. Wie genau die Umsetzung erfolgt, und wie sich dadurch eventuell das Anwendungsverhalten ändert soll nachfolgend erläuert werden.

„Deaktivieren von NTLM und erzwingen von Kerberos an der Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES)“ weiterlesen

Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als PKINIT oder auch Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

„Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)“ weiterlesen

Grundlagen: Namenseinschränkungen (Name Constraints)

Namenseinschränkungen sind ein Teil des X.509 Standard und im RFC 5280 beschrieben. Sie sind ein Werkzeug, das im Rahmen der qualifizierten Subordinierung eingesetzt werden kann, um den Gültigkeitsbereich eines Zertifizierungsstellenzertifikats feingranular zu steuern.

„Grundlagen: Namenseinschränkungen (Name Constraints)“ weiterlesen

Grenzen der Microsoft Active Directory Certificate Services

Die Active Directory Certificate Services bestehen (wenn auch unter anderem Namen) in ihren Grundzügen seit Windows NT 4.0. Die heutzutage verwendete auf Active Directory besierende Architektur wurde mit Windows 2000 Server eingeführt. Die AD CS sind sehr gut in das Windows-Ökosystem integriert und erfreuen sich weiterhin weltweit großer Beliebtheit in Unternehmen und Behörden jeglicher Größenordnung.

Gerne wird auf die vielen Möglichkeiten hingewiesen, welche die Active Directory Certificate Services bieten. Selten wird allerdings darauf verwiesen, was mit ihnen nicht möglich ist. Das Produkt stößt nämlich mittlerweile an vielen Stellen auch an seine Grenzen.

Welche das sind, soll nachfolgend näher ausgeführt werden, um besser entscheiden zu können, ob die AD CS für geplante Vorhaben die richtige Lösung sein können.

„Grenzen der Microsoft Active Directory Certificate Services“ weiterlesen

Neues Blog zum Thema Active Directory Certificate Services mit Fokus auf Sicherheit

Mit Freuden kann ich verkünden, dass meine sehr geschätzte ehemalige Kollegin Dagmar Heidecker wieder am bloggen ist.

In ihrer neuen Rolle in der Microsoft Compromise Recovery Security Practice setzt Dagmar den thematischen Schwerpunkt insbesondere (aber nicht nur) auf Sicherheitsthemen rund um die Active Directory Certificate Services und damit verbundene Komponenten.

Ihr Blog ist zu finden im Core Infrastructure and Security Blog.

Grundlagen: Einschränkung der Pfadlänge (Path Length Constraint)

Der Ende 2008 vorgeführte Angriff auf den MD5 Signaturalgorithmus konnte nur deshalb zur Erstellung eines nutzbaren gefälschten Zertifizierungsstellen-Zertifikats verwendet werden, da die angegriffene Zertifizierungsstelle keine Einschränkung der Pfadlänge konfiguriert hatte.

Die Einschränkung der Pfadlänge ist im RFC 5280 beschrieben. Die Idee dahinter ist, dass in der "Basic Constraints" Erweiterung eines Zertifizierungsstellen-Zertifikats die maximale Tiefe der Zertifizierungsstellen-Hierarchie hinterlegt wird.

„Grundlagen: Einschränkung der Pfadlänge (Path Length Constraint)“ weiterlesen

Konfigurieren der Trusted Platform Module (TPM) Key Attestation

Seit Windows 8 ist es möglich, dass private Schlüssel für Zertifikate mit einem – sofern vorhanden – Trusted Platform Modul (TPM) geschützt werden. Dadurch ist eine Nichtexportierbarkeit des Schlüssels – auch mit Werkzeugen wie mimikatz – gegeben.

Auf den Ersten Blick ist allerdings nicht ersichtlich, dass nicht garantiert werden kann, dass auch wirklich ein TPM zum Einsatz kommt. Zwar wird keine Beantragung über die Microsoft Management Console oder AutoEnrollment möglich sein, wenn der Computer über kein TPM verfügt.

Es handelt sich jedoch bei der Konfiguration in der Zertifikatvorlage lediglich um eine Voreinstellung für den Client. Die Zertifizierungsstelle wird bei Beantragung nicht explizit prüfen, ob auch wirklich ein Trusted Platform Modul verwendet wurde.

Um sicherzustellen, dass der private Schlüssel einer Zertifikatanforderung wirklich mit einem Trusted Platform Modul geschützt wurde verbleibt also nur die TPM Key Attestation.

„Konfigurieren der Trusted Platform Module (TPM) Key Attestation“ weiterlesen

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle

Immer wieder kommt in Diskussionen zur Sicherheit einer Zertifizierungsstelle auf, dass ein Missbrauch der Zertifizierungsstelle durch deren Sicherheitseinstellungen eingedämmt werden könnte.

Dass die Integrität einer Zertifizierungsstelle jedoch unmittelbar an ihr Schlüsselmaterial gebunden ist und sie somit durch dieses auch kompromittiert werden kann, ist auf den Ersten Blick nicht offensichtlich.

Muss man sich die Zertifizierungsstellen-Software als eine Art Management um das Schlüsselmaterial herum vorstellen. Die Software bietet beispielsweise eine Online-Schnittstelle für die Zertifikatbeantragung an, kümmert sich um die Authentifizierung der Antragsteller, um die automatisierte Durchführung von Signaturoperationen (Ausstellen von Zertifikaten und Sperrlisten) und deren Protokollierung (Zertifizierungsstellen-Datenbank, Auditprotokoll, Ereignisprotokoll).

Signaturoperationen benötigen jedoch nichts weiter als den privaten Schlüssel der Zertifizierungsstelle. Nachfolgend wird anhand eines Beispiels aufgezeigt, wie ein Angreifer, wenn er Zugang zum privaten Schlüssel der Zertifizierungsstelle erhält, Zertifikate erzeugen und ausstellen kann, ohne dass die Zertifizierungsstellen-Software und deren Sicherheitsmechanismen dies mitbekommen würden.

Mit einem solchen Zertifikat wäre es im schlechtesten Fall sogar möglich, die Active Directory Gesamtstruktur unerkannt zu übernehmen.

„Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle“ weiterlesen

Gibt es eine Abhängigkeit des Registrierungsdienstes für Netzwerkgeräte (NDES) mit dem NTAuthCertificates Objekt?

Der Registrierungsdienst für Netzwerkgeräte (NDES) verfügt über zwei Registration Authority Zertifikate. Mit dem Enrollment-Agenten-Zertifikat werden Zertifikatanforderungen signiert und man kann die NDES-Gerätevorlage entsprechend konfigurieren, sodass Zertifikate auch nur dann ausgestellt werden, wenn die eingereichten Zertifikatanforderungen auch eine entsprechende Signatur aufweisen.

Plant man, die mit dem NDES verbundene Zertifizierungsstelle aus dem NTAuthCertificates Objekt zu entfernen, kommt eventuell die Frage auf, ob hier wechselseitige Abhängigkeiten zu berücksichtigen sind – schließlich erfordert Enroll on Behalf Of (EOBO) das Vorhandensein des Zertifizierungsstellen-Zertifikats in NTAuthCertificates.

„Gibt es eine Abhängigkeit des Registrierungsdienstes für Netzwerkgeräte (NDES) mit dem NTAuthCertificates Objekt?“ weiterlesen

Domänencontroller (oder andere Teilnehmer) zwingen, einen Onlineresponder (OCSP) zu verwenden

In der Standardeinstellung werden Windows-Systeme, auch wenn ein Onlineresponder (OCSP) konfiguriert ist, nach einer bestimmten Anzahl von OCSP-Anfragen auf eine (falls vorhanden) Sperrliste zurückfallen, weil dies in einem solchen Fall meistens effizienter ist. Nicht immer ist dieses Verhalten aber gewünscht.

Setzt man beispielsweise Smartcard-Anmeldungen ein, möchte man vielleicht wissen, ob Anmeldungen mit unberechtigt ausgestellten Zertifikaten ausgeführt wurden. In Verbindung mit dem deterministischen Good des Onlineresponders kann man so einen (beinahe) lückenlosen Auditierungspfad für alle Smartcard-Anmeldungen schaffen.

„Domänencontroller (oder andere Teilnehmer) zwingen, einen Onlineresponder (OCSP) zu verwenden“ weiterlesen

Details zum Ereignis mit ID 5127 der Quelle Microsoft-Windows-Security-Auditing

Ereignisquelle:Microsoft-Windows-Security-Auditing
Ereignis-ID:5127 (0x1407)
Ereignisprotokoll:Security
Ereignistyp:Information
Ereignistext (englisch):The OCSP Revocation Provider successfully updated the revocation information. CA Configuration ID: %1 Base CRL Number: %2 Base CRL This Update: %3 Base CRL Hash: %4 Delta CRL Number: %5 Delta CRL Indicator: %6 Delta CRL This Update: %7 Delta CRL Hash: %8
Ereignistext (deutsch):Der OCSP-Antwortdienst hat die Sperrungsinformationen erfolgreich aktualisiert. Konfigurations-ID der Zertifizierungsstelle: %1 Basissperrlistennummer: %2 Basissperrliste, diese Aktualisierung: %3 Basissperrlistenhash: %4 Deltasperrlistennummer: %5 Deltasperrlistenanzeige: %6 Deltasperrliste, diese Aktualisierung: %7 Deltasperrlistenhash: %8
„Details zum Ereignis mit ID 5127 der Quelle Microsoft-Windows-Security-Auditing“ weiterlesen

Details zum Ereignis mit ID 5125 der Quelle Microsoft-Windows-Security-Auditing

Ereignisquelle:Microsoft-Windows-Security-Auditing
Ereignis-ID:5125 (0x1405)
Ereignisprotokoll:Security
Ereignistyp:Information
Ereignistext (englisch):A request was submitted to OCSP Responder Service.
Ereignistext (deutsch):An den OCSP-Antwortdienst wird eine Anforderung übermittelt.
„Details zum Ereignis mit ID 5125 der Quelle Microsoft-Windows-Security-Auditing“ weiterlesen
de_DEDeutsch