[English]Sicherheitsforscher haben kürzlich einen neuen Angriffsvektor namens PetitPotam offen gelegt. Mittels eines NTLM-Relay-Angriffs kann jeder Windows Domain Controller übernommen werden. Inzwischen hat Microsoft reagiert und einen Sicherheitshinweis zu diesem Sicherheitsproblem veröffentlicht. Aber es gibt einen zweiten Vorschlag von Sicherheitsforschern, den Angriff über RPC-Filter zu blockieren. Aber dieser Vorschlag ist keine Universallösung.
Anzeige
Die PetitPotam-Schwachstelle
Der französische Sicherheitsforscher Gilles Lionel (Alias Topotam) hatte im Juli 2021 ein Proof of Concept (PoC) zur Ausnutzung eines NTLM-Relay-Angriffs veröffentlicht, mit dem Windows Domain Controller übernommen werden können. Sicherheitsforscher waren auf eine Methode gestoßen, um einen Domänencontroller zu zwingen, sich gegenüber einem bösartigen NTLM-Relay zu authentifizieren. Die ermöglicht, dann die Anfrage über HTTP an die Active Directory-Zertifikatsdienste einer Domäne weiter zu leiten. Letztendlich erhält der Angreifer ein Kerberos-Ticket (TGT), mit dem er die Identität eines beliebigen Geräts im Netzwerk, einschließlich eines Domänencontrollers, annehmen könnte.
Einziges Problem ist es, einen Rechner zu zwingen, die Authentifizierung gegenüber einem Remote-Server durchzuführen. Eine Möglichkeit wäre die Verwendung der Funktion RpcRemoteFindFirstPrinterChangeNotification der MS-RPRN-Druck-API. Ein Angreifer, der einen Domänenbenutzer/Computer kontrolliert, kann mit einem bestimmten RPC-Aufruf den Spooler-Dienst eines Ziels, auf dem er läuft, auslösen und ihn dazu bringen, sich bei einem Ziel seiner Wahl zu authentifizieren", verrät Hacker.recipes in einem Blogbeitrag.
Der Angreifer benötigt aber Zugriff auf die Domäne (d. h. ein kompromittiertes Konto), damit dieser Angriff funktioniert. Denn es wird ein RPC-Aufruf in der SMB-„Pipe" über die IPC$-Freigabe für den Angriff benötigt. Diese Schwachstelle kann prinzipiell nicht geschlossen werden und ist standardmäßig in allen Windows-Umgebungen aktiviert, heißt es dazu. Seit dieser Angriff bekannt wurde, haben viele Organisationen MS-RPRN deaktiviert, um den Angriffsvektor zu blockieren.
Ich hatte im Beitrag PetitPotam-Angriff erlaubt Windows Domain-Übernahme über diesen Sachverhalt berichtet. Einen Tag später bestätigte Microsoft dieses Angriffsszenario, von dem quasi alle Server-Betriebssysteme von Windows Server 2008 bis Windows Server 20H2 betroffen sind. Gleichzeitig macht Microsoft Vorschläge, wie diese Sicherheitslücke durch Administratoren abgeschwächt werden kann. Domänenadministratoren müssen sicherstellen, dass Dienste, die eine NTLM-Authentifizierung zulassen, Schutzmaßnahmen wie Extended Protection for Authentication (EPA) oder Signierungsfunktionen wie SMB-Signierung verwenden. Ich hatte über die Details im Blog-Beitrag Microsoft liefert Workaround für Windows PetitPotam NTLM-Relay-Angriffe berichtet.
Anzeige
PetitPotam-Angriffe mit NETSH-Fitern blockieren
Am Wochenende hatte ich bereits die nachfolgenden Informationen von Benjamin Delpy auf Twitter gelesen, wie man MS-EFSR-PetitPotam-Aufrufe über RPC-Filter blockieren könne. CraigKirby hatte auf diese betreffende Möglichkeit hingewiesen.
Allerdings sagte mir diese Filtertechnik nichts und es war mir unklar, ob da was mit Bordmitteln ging. Delpy hatte aber wohl mit den Kollegen von Bleeping Computer Kontakt, die das Thema in diesem Beitrag aufgegriffen haben. Delpy schlägt nachfolgenden NETSH-RPC-Filter vor, der den Fernzugriff auf die MS-EFSRPC-API blockiert und damit den unauthentifizierten PetitPotam-Angriffsvektor wirksam blockiert. Dazu sind folgende Anweisungen in einen Datei block_efsr.txt auf dem Desktop des Administratorkontos zu speichern.
rpc
filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quitAnschließend ist eine administrative EIngabeaufforderung zu öffnen und der nachfolgende Befehl auszuführen, um den Filter zu importieren:
netsh -f %userprofile%\desktop\block_efsr.txt
Führt ein Administrator dann zur Kontrolle den nachfolgenden Befehl in einer administrativen EIngabeaufforderung aus, sollten die nachfolgend gezeigten beiden Filter angezeigt werden.
netsh rpc filter show filter
Mit diesen Filtern sollte ein PetitPotam-Angriff nicht mehr funktionieren, während EFS wird weiterhin normal auf dem System genutzt werden kann. Sicherheitsforscher Will Dormann bestätigt in diesem Tweet, dass diese Filterung funktioniert.
Wichtig ist aber, dass diese nur Remote-Angriffe blockiert. Der französische Sicherheitsforscher Gilles Lionel (Alias Topotam) weist in diesem Tweet auf den Sachverhalt hin.
An dieser Stelle ist mir allerdings unklar, wie gut nun der RPC-Filter schützt, denn die der Angreifer benötigt bereits Zugriff auf die Domäne. Sollte Microsoft jemals die API korrigieren, um diesen Angriffsvektor zu blockieren, lässt sich dieser Filter mit dem folgenden Befehl in einer administrativen Eingabeaufforderung entfernen:
netsh rpc filter delete filter filterkey=[key]
Vielleicht hilft es euch trotzdem weiter.
Ähnliche Artikel:
PetitPotam-Angriff erlaubt Windows Domain-Übernahme
Microsoft liefert Workaround für Windows PetitPotam NTLM-Relay-Angriffe
HiveNightmare: Neue Details zur Windows-Schwachstelle CVE-2021-36934
Neue Infos zur Windows 10-Schwachstelle HiveNightmare
PrintNightmare: Point-and-Print erlaubt die Installation beliebiger Dateien
Microsoft Security Update Revisions (29. Juli 2021)
Anzeige
Für mein Verständnis, wenn wir keine CA haben wirkt der Angriff nicht?
So kommt es auch bei mir an, Paul.
Nicht nur keine CA, so wie ich es verstehe nüssen bestimmte CA Web Roles installiert sein. Leider sind alle Artikel in Englisch und die deutschen Namen der Rollen sind irgendwie anders.
Ich frage mich ob man im Zweifel einfach alle CA Rollen mit "Web" im Namen vom Server entfernen kann, wenn man eh keine Websites hostet.
Ihr könnt eine CA haben, nur wenn zusätzlich die Dienste Certificate Authority Web Enrollment und/oder Certificate Enrollment Web Service installiert sind, gibt es Probleme. Man kann auch eine CA betreiben, ohne die beiden Dienste installiert zu haben.
Falls aber die Dienste installiert sind und benötigt werden, dann sollte man diese gemäß KB5005413 absichern. Falls die Dienste nur zusätzlich installiert wurden und nicht benötigt werden, dann runter mit den Diensten ;-)
Danke für die Antwort.
Weißt du zufällig wofür die Web Dienste sind?
Glaube die sind hier unnötigerweise mit drauf.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831649(v=ws.11)
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831822(v=ws.11)
Der Dienst "Certificate Authority Web Enrollment" ist für Browser, damit man über den Browser ein Zertifikat beantragen kann (geht -denke ich- nur mit dem IE, ist also eh outdated).
Der letztere "Certificate Enrollment Web Service" ist -man möge mich korrigieren, wenn ich falsch liege- ein Dienst, damit Clients (Workstations – MS redet von "network client computers"), die ausserhalb der Domäne sind, per HTTP Zertifikate beantragen/erhalten können.
Dumme Verständnisfrage: Ich muss die RPC-Filter dann auf dem Server mit der CA oder den DCs setzen?
Weiß jemand ob die Windows Firewall dafür auf dem Server an sein muss?
Das NTLM Relaying funktioniert unabhängig von der CA. Ohne Zertifikatsdienste lässt sich dann blos kein Zertifikat damit generieren. Die NTLM Anmeldung lässt sich aber ggf. für andere Sachen missbrauchen. Der "Trick" ist generell keine schlechte Idee um das aktuelle Problem abzumildern.
Der einzige sichere Weg, das Problem NTLM Relay ganz los zu werden, ist NTLM überall (per GPO) komplett zu verbieten. Blos nicht alle Legacy Anwendungen unterstützen Kerberos.