Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle

Autor Uwe GradeneggerVeröffentlicht am Kategorien Active Directory, Penetration Testing, Security, Smartcard, ZertifizierungsstelleSchlagwörter , , , ,

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.

Die nachfolgenden Schritte sollten niemals in einer produktiven Umgebung durchgeführt werden. Bei der hier durchgeführten Demonstration handelt es sich nicht um eine Anleitung zum Einbrechen in Computersysteme, sie soll vielmehr das Sicherheitsrisiko aufzeigen, um Gegenmaßnahmen einleiten zu können.

Für die Demonstration verwenden wir das PSCertificateEnrollment PowerShell Modul. Es kann über die PowerShell Gallery bezogen und anschließend geladen werden.

Bitte beachten, dass es sich bei dem PSCertificateEnrollment Modul nicht um ein Hacking-Werkzeug handelt, sondern um ein völlig legitimes Stück Software, das die Benutzung einer Public Key Infrastruktur im Windows-Ökosystem erleichtern soll. Der hier gezeigte Angriff wäre auch mit anderen Werkzeugen auf gleiche Weise möglich. Darüber hinaus handelt es sich bei diesem Beispiel nicht um die Ausnutzung einer Sicherheitslücke im Zertifizierungsstellen-Produkt, sondern zeigt eher die konzeptuellen Zusammenhänge auf, und wie diese bei unterlassener Sicherheitshärtung missbraucht werden können.

Install-Module -Name PSCertificateEnrollment
Import-Module -Name PSCertificateEnrollment

Um das erzeugte Zertifikat signieren zu können, wird das Zertifizierungsstellen-Zertifikat inklusive privatem Schlüssel benötigt.

Im Beispiel nehmen wir einen der beiden folgenden Fälle an:

  • Der Angreifer ist (z.B. durch Diebstahl einer der Sicherungen) im Besitz einer Kopie des privaten Schlüssels der Zertifizierungsstelle, da dieser nicht durch ein Hardware Security Modul (HSM) geschützt wurde. In diesem Fall funktioniert der Angriff von jedem Windows-System aus.
  • Der Angreifer hat sich Systemrechte auf der Zertifizierungsstelle verschafft und führt die Operation direkt auf dieser aus. In diesem Fall funktioniert der Angriff sogar, wenn der private Schlüssel durch ein Hardware Security Modul geschützt wurde.

Das Zertifizierungsstellen-Zertifikat muss zunächst in einem lokalen Zertifikatspeicher identifiziert werden.

Get-ChildItem -Path Cert:\LocalMachine\My

Als nächstes wird es in eine Variable eingelesen.

$CaCert = Get-ChildItem -Path Cert:\LocalMachine\My\A40E27C70460D0CD0AF7DE4088105869AD90AF60

Anschließend kann eine Zertifikatanforderung erzeugt werden, die direkt mit dem Zertifizierungsstellen-Zertifikat signiert wird.

Im Beispiel…

  • wird das resultierende Zertifikat im Benutzer-Zertifikatspeicher erzeugt (Standardeinstellung des Moduls).
  • wird der Microsoft Software Key Storage Provider verwendet (Standardeinstellung des Moduls).
  • wird der private Schlüsel als exportierbar markiert (sodass er anschließend auf einem anderen System oder in eine Smartcard importiert werden kann).
  • enthält das resultierende Zertifikat den Benutzerprinzipalnamen (UPN) des Administrator-Kontos der Gesamtstruktur.
  • enthält das resultierende Zertifikat die Extended Key Usages für Clientauthentifizierung und Smartcard-Anmeldung.
  • enthält das resultierende Zertifikat einen Sperrlistenverteilungspunkt, der auf eine gültige Sperrliste der Zertifizierungsstelle verweist (Voraussetzung, damit das Zertifikat von einem Domänencontroller akzeptiert wird).
  • enthält das resultierende Zertifikat eine durch den Angreifer vorgegebene Seriennummer.
New-CertificateRequest `
-Exportable `
-Upn "administrator@intra.adcslabor.de" `
-EnhancedKeyUsage ClientAuthentication,SmartcardLogon `
-Cdp "http://pki.adcslabor.de/CertData/ADCS Labor Issuing CA 1.crl" `
-SerialNumber "deadbeef1337" `
-SigningCert $CaCert

Nach Ausführung des Befehls sollte sich ein entsprechendes Zertifikat im Zertifikatspeicher des angemeldeten Benutzers befinden.

Ein Blick in die Eigenschaften des Zertifikats zeigt, dass die angegebene Seriennummer übernommen wurde. Dies soll verdeutlichen, dass der Angreifer die komplette Kontrolle über den Inhalt des Zertifikats hat – auch über die Seriennummer. Es ist also praktisch nicht möglich, ein solches Zertifikat zu sperren, da die Seriennummer im Regelfall nicht bekannt ist.

Der Subject Alternative Name (SAN) enthält den Benutzerprinzipalnamen des Administratoren-Kontos. Der Angreifer kann hier beliebige Identitäten eintragen.

Die erweiterte Schlüsselverwendung (Extended Key Usage, EKU) enthält die notwendigen Einträge für eine Smartcard-Anmeldung.

Zu guter letzt lässt sich feststellen, dass das Zertifikat offensichtlich von der Zertifizierungsstelle ausgestellt wurde – die Zertifikatkette kann erfolgreich hergestellt werden.

Da direkt der private Schlüssel angesprochen wurde, wird sich jedoch kein entsprechendes Zertifikat in der Zertifizierungsstellen-Datenbank finden lassen. Ebenso wurde auf der Zertifizierungsstelle auch kein Audit-Ereignis erzeugt.

Importiert der Angreifer ein solches Zertifikat in einer Smartcard, kann er sich damit an der Active Directory Gesamtstruktur mit der im Zertifikat enthaltenen Identität anmelden, sofern die Voraussetzungen in der Infrastuktur erfüllt sind. Er erhält dann die Berechtigungen des entsprechenden Benutzers – im Beispiel also "Enterprise Administrator". Ein Super-GAU für die IT-Sicherheit.

Mittlerweile gibt es mit kekeo auch ein Werkzeug, welches die direkte Beantragung eines Ticket Granting Ticket (TGT) mit einem Zertifikat – also ohne Smartcard und Präsenz im lokalen Netzwerk ermöglichen – was den Angriff somit noch gefährlicher macht.

Gegenmaßnahmen

Folgende Maßnahmen können helfen, die von einem solchen Angriff ausgehenden Gefahren abzumildern, oder einen solchen Angriff zu erkennen:

Weiterführende Links:

de_DEDeutsch
en_USEnglish de_DEDeutsch