
Burp Suite von Portswigger und OWASP ZAP sind beides Programme mit einem Proxy-Server, welche auf deinem lokalen Gerät laufen. Mit
In diesem Artikel befassen wir uns mit den Risiken einer fehlerhaften oder unvollständigen Einrichtung von ADCS (Active Directory Certificate Services). Je nach Ausmaß kann ein Angreifer Zertifikate für jegliche Aktion und Berechtigung erstellen, sodass hier ein sehr großes Risiko besteht. Wir zeigen euch die drei größten Risikofaktoren, schildern zwei mögliche Angriffswege und erklären, wie ihr euch davor schützen könnt.
Die Active Directory Zertifikatsdienste gibt es unter diesem Namen seit Windows Server 2008, vorher hieß es nur Stammzertifizierungsstelle (engl. Certificate Authority). Die ADCS dienen der Erstellung einer eigenen Public Key Infrastructure (kurz PKI). Details zur ADCS findest du im entsprechenden Artikel: Public Key Infrastructure mit Active Directory Certificate Services
Eine umfängliche und strukturierte Einrichtung und Umsetzung der AD Zertifikatsdienste ist enorm wichtig für den Schutz vor möglichen Hacking Angriffen.
Eine Fehlkonfiguration bei den ADCS kann zu weitreichenden Konsequenzen führen. Daher werden im Folgenden einige der wichtigsten Konfigurationsschritte bei der Erstellung bzw. Anpassung der Zertifikatsvorlagen beschrieben und die Konsequenzen mancher Optionen vorgestellt. Da diese einzeln betrachtet durchaus sinnvoll und notwendig sein können, ist insbesondere die Kombination der Eintellungen dabei relevant.
Im Reiter Antragstellername stehen zwei Optionen zur Verfügung:
Informationen werden in der Anforderung angegeben: Diese Option ist z. B. beim Template “Webserver” im Standard aktiv. Hier macht es Sinn, dass ein berechtigter Administrator die entsprechenden alternativen Namen eines Servers im Zertifikat angibt.
Achtung: Wird diese Option bei Benutzerzertifikaten ausgewählt, kann der Antragsteller ein Zertifikat für jeden beliebigen Benutzer ausstellen. Falls die Berechtigungen zur Erstellung nun noch für alle Benutzer (s.u.) gesetzt werden, kann ein “normaler” Nutzer Zertifikate für den Administrator beantragen.
Aus diesen Informationen im Active Directory erstellen: Bei Auswahl dieser Option werden die verwendeten Informationen aus den AD Einträgen des Benutzers bzw. des Computers generiert. Dies ist insbesondere bei Benutzern sinnvoll: So wird verhindert, dass Werte anderer Benutzer verwendet werden können.
Der Reiter Berechtigungen entspricht dem bekannten Layout der Berechtigungsvergabe. Letzlich unterscheidet sich dies nicht von sonstigen Berechtigungen und der Empfehlung zur Nutzung der üblichen Vorgaben: “So wenige Berechtigungen wie möglich”.
Die Anwendungsrichtlinien legen den Verwendungszweck des Zertifikates fest. Wichtig ist hier die genaue Festlegung, angepasst auf die Zielsetzung des Zertifikates. Beispielsweise benötigt ein Zertifikat zur Nutzung im Webserver oder zur Codesignierung keine Clientauthentifizierung.
Besonders kritisch ist die Ausstellung von Zertifikaten mit der Anwendungsrichtlinie “Beliebiger Zweck” bzw. “Any Purpose”. Die Erfahrung zeigt, dass es immer wieder zu Konfigurationen kommt, in denen teils Benutzer oder auch Administratoren diese Zertifikate erstellen können. Die Beantragung sollte hier auf ein absolutes Minimum beschränkt sein und der berechtigte Account bestmöglich geschützt sein.
Der Subject Alternative Name oder auch der Haken bei „Informationen werden in der Anforderung angegeben“. Mit dem Alternativnamen kannst du sein, wer du möchtest: Wenn der Zweitname Administrator ist, geht das auch.
Zuerst musst du die notwendigen Informationen beschaffen, also ein klassischer Fall für Bloodhound. Dafür werden valide Benutzerdaten aus der Domäne benötigt, hier unser dcUser.
Zuerst der Bloodhound Dump für Benutzer und Computer Informationen:
bloodhound-python -u -p -d [-c all] -dc [-ns ] --zip
Danach mit certipy (hier 4.0) die Zertifikatsinformationen holen:
certipy find -u -p -old-bloodhound -target
Die .zip‘s dann in die BloodhoundGUI ziehen für weitere Analysen.
Für die Analyse eignen sich die Customqueries von @Ly4k dem Autor von certipy:
Hier haben wir einen ‚Generic All‘, weil sich der Administrator „verklickt” hat und allen Nutzern den Vollzugriff gestattet hat. So etwas passiert gerne mal im Rahmen der Implementierung oder des Troubleshooting und der “Rückbau” wird nicht gemacht, wenn es funktioniert. Uns reicht in diesem Fall der Subject Alternativ Name/Enrollee Supplies Subject = true.
Weiter geht es auf der Shell mit certypy:
certipy req -u -p -ca -target -template -upn
Danach das Zertifikat zur Anmeldung benutzen:
certipy auth -pfx administrator.pfx
Damit erhältst du ein TGT und den PasswortHash. Mit dem Zertifikat kannst du dir immer ein TGT und den Hash holen, solange es gültig ist. Auch ein Passwortwechsel des Nutzers und vom KRBTGT helfen hier nicht.
Die Domäne ist dein, solange das Zertifikat nicht gesperrt wird.
Das “Any purpose” Zertifikat. Es ist in der Regel eine CA oder SubCA Zertifikat und hat damit auch genau die Rechte, die Standardgültigkeit sind 5 Jahre. Da es nur von Administrativen Nutzern angefordert werden kann, ist dies eher eine Maßnahme zur Persistenz.
Behandeln wir hier noch nicht. Der ESC6 ist wie die ESC1, nur von der CA aus an alle Zertifikatstemplates vererbt.
Der angreifbare Webserver. Vollumfänglich in unserem PetitPotam Artikel behandelt.
Mein Computer heißt jetzt wie der Domänencontroller. Hierfür muss der Wert für das Erstellen weiterer Computer in der Domäne so gesetzt sein, dass weitere hinzugefügt werden können. Im Standard beträgt dieser 10 (ms-DS-MachineAccountQuota
), wenn man noch keinen privilegierteren Account hat.
Diese Lücke wurde von Microsoft im Mai 2022 gepatched. Eine Ausnutzung via Kerberos oder Schannel ist somit nicht möglich, wenn CA und DC gepatched sind.
Durch den Patch wird ein weiterer Parameter in das Zertifikat geschrieben, der szOID_NTDS_CA_SECURITY_EXT
die SID
des Benutzers.
Falls es doch nicht gepatched wurde oder der CT_FLAG_NO_SECURITY_EXTENSION (0x80000)
im msPKI-Enrollment-Flag
gesetzt ist, geht es trotzdem. Mit certipy einen neuen Computer erstellen, aber einen alternativen dNSHostName
eintragen lassen.
certipy account create -user -username -password -target -dns
Danach forderst du ein Zertifikat an. Da für Computer Zertifikate der dNSHostName
genutzt wird, muss hier nichts “manipuliert” werden. Die Machine
Zertifikatsvorlage wird dafür benutzt.
Wenn die Anmeldung mit dem Zertifikat nicht klappt, weil es nicht unterstütz ist, erhältst du folgende Fehlermeldung:
Fehler:
eRR-PDATA-Type-NOSUPP
oder
Error Code: 16 Reason: KDC has no support for PADATA
.
type (pre-authentication data)
Hier hilft ein Tool von AlmonOffSec, PassTheCert in C# und Python. LDAPS und LDAP sind ausnutzbar durch StartTLS. Auch LDAP ChannelBinding hat durch Schannel keinen negativen Effekt auf den Angriff.
Aber zuerst muss das .pfx in ein .crt und in ein .key gewandelt werden, also den privaten Schlüssel und das Zertifikat selbst als eigenständige Daten haben.
certipy cert -pfx .pfx -nokey -out .crt
certipy cert -pfx .pfx -nocert -out .key
Danach erstellen wir einen neuen Computer, wenn wir noch keine Kontrolle über einen haben. Anmeldung als das System sollte mit einem Passwort möglich sein.
python3 /opt/PassTheCert/Python/passthecert.py -dc-ip -crt .crt -key .key -domain -action add_computer -computer-name
Danach erstellen wir eine Delegation von unserem “neuen Computer” zu dem Domänencontroller. msDS-AllowedToActOnBehalfOfOtherIdentity
, eine ResourceBasedConstrainedDelegation
. Zur Hilfestellung das -delegate-from
und -delegate-to
: das from ist der Computer, den ich kontrolliere, und die Daten schreibe ich in den to, also mein Ziel.
python3 /opt/PassTheCert/Python/passthecert.py -dc-ip -crt .crt -key .key -domain -action write_rbcd -delegate-from -delegate-to
Mit den delegierten Berechtigungen Kerberos anfragen, takeover.
impacket-getST -spn 'cifs/' -impersonate Administrator '/:' -dc-ip
Certipy hat auch eine LDAP Shell mit einfachen Befehlen implementiert, worüber dieses Szenario auch ausgenutzt werden kann.
Wer die Gefahr von fehlerhaft konfigurierten Zertifikatstemplates in einer reinen Windowsumgebung ohne die Nutzung von Kali-Linux nachstellen möchte, kann dies mittels normalen Windowsboardmitteln und dem Smartcard-Emulator PIVert umsetzen.
In unserem Anwendungsfall nutzen wir einen Windows 10 Client. In der MMC Console fügen wir den entsprechenden Snap-In der Zertifikate hinzu, um anschließend aus den vorhandenen Templates ein Zertifikat zu erstellen.
“Glücklicherweise” befindet sich in unseren Templates eine Vorlage zur Erstellung eines SmartCard-Zertifikates, in der wir den Antragstellernamen selbst eingeben können. Wir können also als angemeldeter Standarduser ein Zertifikat für den Administrator erstellen!
Wichtig ist es, bei der Erstellung den privaten Schlüssel als exportierbar einzustellen und zur Nutzung in PIVert den Antragstellernamen leer zu lassen, da es hier sonst zu Problemen kommen kann.
Nach der erfolgreichen Erstellung des Zertifikates musst du dieses als *.pfx exportieren. Dabei muss der private Schlüssel exportiert und ein Kennwort angegeben werden.
Anschließend kannst du dieses Zertifikat in PIVert einbinden und eine entsprechende SmartCard emulieren. Damit erfolgt ein RDP-Verbindungsaufbau, im Beispielfall als Administrator auf den ADCS.
Den besten Schutz vor Angriffen bietet eine bewusste und angemessene Konfigruation der Templates und der Berechtigungen. Dabei sind insbesondere die oben genannten Risiken zu betrachten und bei der Konfiguration zu minimieren.
Der Antragstellername sollte wenn immer möglich direkt aus den Benutzerdaten des AD gezogen werden und nicht selbst zu editieren sein, mittels Auswahl “Aus diesen Informationen im Active Directory erstellen” aus oben zu sehendem Screenshot.
Vergib die Berechtigungen so restriktiv wie möglich, insbesondere wenn der Antragstellername nicht festgelegt ist oder die Möglichkeiten des Zertifikates sehr weitreichend sind.
Weiterhin gilt bei der Festlegung der Anwendungsrichtlinien zur Definition des Verwendungszwecks: Wähle nur diejnigen in einem Zertifikat aus, die zum Nutzungszweck notwendig sind. Für verschiedene Anwendungsfelder sind verschiedene Templates zu erstellen.
Die korrekte und bewusste Konfiguration der Zertifikatstamplates stellt den wichtigsten Schritt zum Schutz gegen Missbrauch und Angriffe dar.
Eine weitere Möglichkeit, das Risiko eines Missbrauchs zu minimieren, ist die Aktivierung der Genehmigung der Zertifikatsverwaltung (manager approval). Wenn du das in der entsprechenden Zertifikatsvorlage aktivierst, kann ein Zertifikat zwar beantragt werden, die Freigabe muss jedoch durch einen Administrator auf dem ADCS erfolgen. Somit ist eine Erstellung von Zertifikaten erschwert – dies ist entsprechend mit Mehraufwand im Erstellungsprozess verbunden.
Eine weitere Herausforderung dieser Methode ist das “Rückspielen” der freigegebenen Zertifikate an den Antragsteller. Hier bestehen verschiedene Möglichkeiten, welche wir an dieser Stelle nicht im Detail vorstellen:
Burp Suite von Portswigger und OWASP ZAP sind beides Programme mit einem Proxy-Server, welche auf deinem lokalen Gerät laufen. Mit
Unser Mitgründer Immanuel war zu Gast bei Radio Bonn/ Rhein-Sieg und hat dem Moderatoren-Team Nico Jansen und Jasmin Lenz und
Wenn Cyber Versicherungen und Penetration Tester zusammenarbeiten, entsteht daraus ein großer Mehrwert für alle Beteiligten. Warum das so ist und