Kategorien
Tutorials

Schwachstelle LLMNR und NBT-NS in Windows-Netzwerken verstehen und beheben

LLMNR und NBT-NS sind veraltete Protokolle, die bei aktuellen Windows-Betriebssystemen allerdings noch immer im Standard aktiviert sind. Die Schwachstelle in den beiden Protokollen sorgt dafür, dass Angreifer wertvolle Passwort-Hashes abfangen oder sich ohne die Kenntnis von Anmeldeinformationen an Servern oder Clients authentifizieren können. Leider ist diese gravierende Schwachstelle bei vielen Systemadministratoren nicht bekannt und in vielen Unternehmensnetzwerken klafft daher diese gravierende Sicherheitslücke.

Getestet wurde dieser Artikel mit Windows Server 2019 als Domänencontroller, und Windows 10 20H2 und Windows Server 2012R2 als Ziel für den Relaying-Angriff. Je nach System und Konfiguration können die gezeigten Angriffe funktionieren oder auch nicht. Der Erfolg des Angriffs hängt von vielen Faktoren und der Geduld des Angreifers ab. Als Angreifer-PC wurde ein Ubuntu 20.04 LTS verwendet.
Dieser Artikel dient ausschließlich der Bildung, damit Systemadministratoren die Gefahr besser einschätzen und ihr Windows-Netzwerk entsprechend absichern können. Das hier vermittelte Wissen darf nur innerhalb der gesetzlichen Rahmenbedingungen angewendet werden.

Was ist LLMNR und NBT-NS?

LLMNR (Link-Local Multicast Name Resolution) und NBT-NS (NetBIOS-Nameservice) sind alte Protokolle für die Namensauflösung. Kurz gesagt kommen diese Protokolle zum Einsatz, wenn der DNS-Server im Netzwerk keine passende Antwort liefert. Beispiel: Ein Host im Netzwerk fragt den DNS-Namen "gibtesnicht" an. Der DNS-Server liefert allerdings keine passende IP-Adresse, weil er den Namen nicht kennt. Der Host macht sich daher selbst auf die Suche und schickt mit den Protokollen LLMNR, oder wenn LLMNR deaktiviert ist mit NBT-NS, einen Broadcast ins Netzwerk und hofft, dass sich ein Teilnehmer des Netzwerks auf "gibtesnicht" angesprochen fühlt und antwortet.

LLMNR NBT-NS Host Discovery
Per LLMNR / NBT-NS erfragt ein Host per Broadcast die IP-Adresse eines DNS-Namens.

Net-NTLM, NTLMv1/2 und NTLM

Da die hier gezeigten Angriffe viel mit Passwort-Hashes zu tun haben, hier einmal etwas einleitende Theorie zu den verschiedenen Hashes. Wem das nicht sonderlich interessiert, kann direkt zum nächsten Abschnitt springen, in dem es um den eigentlichen Angriff geht.

Es gibt verschiedene relevante Passwort-Hashes in Windows. In diesem Artikel beschäftigen wir uns mit Net-NTLM, NTLMv1/2 und NTLM. Wenn man von NTLMv1/2 spricht, spricht man eigentlich von Net-NTLM(v1/2). Diese Hashes werden für Netzwerkauthentifizierungen verwendet und können durch einen Name Resolution Response-Angriff abgefangen oder für einen Relaying-Angriff, nicht aber für einen Pass-the-Hash-Angriff, verwendet werden. Den nachgelagerten Relaying-Angriff schauen wir uns später in diesem Artikel an. Für einen Pass-the-Hash-Angriff benötigt der Angreifer einen NTLM-Hash (also nicht Net-NTLM bzw. NTLMv1/NTLMv2, sondern einen LM- oder NT-Hash). LM- oder NT-Hashes sind in der SAM-Datenbank (Security Account Manager Datenbank) von Windows oder in der Ntds.dit Datenbank auf dem Domänencontroller gespeichert. Ein solcher Hash sieht wie folgt aus:

aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0

Vor dem Doppelpunkt ist das Passwort als (schwacher) LM-Hash gespeichert und nach dem Doppelpunkt als NT-Hash. Wenn man von NTLM spricht, meint man in der Regel aber den NT-Hash. Das Speichern des LM-Hashes kann man mit einer GPO deaktivieren. Außerdem empfiehlt es sich in diesem Zusammenhang die GPO "Netzwerksicherheit: LAN-Manager-Authentifizierungsebene" auf "Nur NTLMv2-Antworten senden. LM & NTLM verweigern" zu setzen.

Die verschiedenen Hashes ermöglichen verschiede Angriffsszenarien und es ist schwer den Überblick über die verschiedenen Hashtypen zu behalten. Zusammenfassend könnte man folgendes festhalten: (Net-)NTLMv1/2-Hashes ermöglichen einen Relaying-Angriff und LM- oder NT-Hashes ermöglichen einen Pass-the-Hash-Angriff.

Zwei empfehlenswerte Seiten, die die verschiedenen Hashes noch ganz gut erklären, habe ich hier einmal verlinkt:

https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html
https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4

Der Name Resolution Response-Angriff

Mit dem Wissen was LLMNR und NBT-NS ist, kann sich ein Angreifer jetzt als "gibtesnicht" ausgeben und dem Opfer vortäuschen, dass er "gibtesnicht" sei. Wenn das Opfer jetzt beispielsweise versucht einen falschgeschriebenen Netzwerkshare "gibtesnicht" aufzurufen und ein Angreifer sich als Zielserver "gibtesnicht" meldet, wird das Opfer sogar seinen Passwort-Hash (Net-NTLM Hash) an den Angreifer senden.

LLMNR NBT-NS Name Resolution Response-Angriff
Der Angreifer gibt sich bei einem Name Resolution Response-Angriff als "gibtesnicht" aus, um so an den Passwort-Hash des Opfers zu kommen.

Voraussetzungen für diesen Angriff:

  • Opfer und Angreifer müssen in der selben Broadcast-Domäne sein.
  • LLMNR und/oder NBT-NS muss bei dem Opfer aktiviert sein.

Der Angreifer kann jetzt beispielsweise versuchen diesen Hash mit einem Dictionary- oder Brute-Force-Angriff (offline) zu knacken.

Die Laborumgebung

Für die durchgeführten Tests in diesem Artikel habe ich in meiner Testumgebung folgende Systeme aufgesetzt, die bis auf dem Angreifer, alle Teil der Domäne lab.local sind:

Domänencontroller / DNS-Server
Windows Server 2019
Hostname: LABDC01.lab.local
IP-Adresse: 192.168.0.2

Opfer
Windows 10 20H2
Hostname: LABCLIENT01.lab.local
IP-Adresse: 192.168.0.200 (DHCP)
Benutzer: LAB\peter

Angreifer
Ubuntu 20.04 LTS
Hostname: HACKERPC
IP-Adresse: 192.168.0.205 (DHCP)

Der Name Resolution Response-Angriff in der Praxis

Bevor wir den eigentlichen Angriff starten, schauen wir uns in Wireshark die Auswirkung von LLMNR bzw. NBT-NS an. Dazu installiere ich auf dem Angreifer-PC Wireshark und starte es:

sudo apt install wireshark
sudo wireshark

Wenn das entsprechende Netzwerkinterface in Wireshark ausgewählt wurde, beginnt auch schon der Mitschnitt sämtlicher Pakete. Mit dem Anzeigefilter udp.port == 5355 || nbns lässt sich die Anzeige schließlich auf das Wesentliche reduzieren. Wenn wir auf einem Host im Netzwerkt ping gibtesnicht ausführen, zeichnet Wireshark auf dem Angreifer-PC diverse LLMNR- und NBT-NS-Pakete auf:

LLMNR NBT-NS ping
Ein Ping an einen nicht existierenden Host.
LLMNR NBT-NS ping Wireshark
Am Angreifer-PC kommen alle LLMNR und NBT-NS-Pakete an, da diese an die Broadcast-Adresse des Netzwerks versendet wurden.

An dieser Stelle passiert jetzt noch nicht viel. Aber das ändert sich ganz schnell, wenn der Angreifer-PC auf die Anfrage antwortet und sich als "gibtesnicht" ausgibt. Genau das werden wir jetzt tun. Es gibt bereits diverse freie Tools, die auf eine solche Anfrage antworten können. Ich nutze für diesen Artikel Responder. Das Tool setzt Python voraus. Die Installation ist denkbar einfach:

cd /home/hacker/Downloads/
wget https://github.com/lgandx/Responder/archive/master.zip
unzip master
cd Responder-master/
sudo python3 Responder.py -I enp0s3
Der Parameter "I" gibt das Netzwerkinterface an, auf dem gelauscht werden soll. Im meinem Beispiel etwa enp0s3.

Der Responder läuft jetzt und wartet auf Anfragen:

LLMNR NBT-NS responder.py
Der Responder ist jetzt einsatzbereit und wartet auf sein nächstes Opfer.

Jetzt mache ich den gleichen Test wie vorhin und pinge von unserem Opfer-PC "gibtesnicht" an:

LLMNR NBT-NS poisoned ping
Der Responder gibt sich jetzt als "gibtesnicht" aus und antwortet (siehe Ping-Reply).
LLMNR NBT-NS poisoned ping Wireshark
Auch Wireshark zeigt an, dass der Angreifer (IP 192.168.0.205) auf die Anfrage antwortet und sich als "gibtesnicht" ausgibt.
LLMNR NBT-NS responder.py poisoned Antwort
Warum das passiert ist, sehen wir schließlich, wenn wir in die Konsolenausgabe des Responders schauen. Er hat eine poisoned "vergiftete" Antwort auf die LLMNR und NBT-NS Anfrage gesendet (grüner Text).

Als wäre der Angriff bis jetzt nicht genug, kann der Angreifer mit etwas Glück und Geduld auch den Passwort-Hash des Opfers abfangen. Der einfachste Weg für dieses Szenario ist, dass ein Benutzer schließlich versucht eine nicht existierende Webadresse (z.B. http://gibtesnicht oder https://gibtesnicht) oder Netzwerkshare (\\gibtesnicht) aufzurufen:

Die Seite lässt sich zwar nicht aufrufen, aber das kann dem Angreifer egal sein.
LLMNR NBT-NS responder.py NTLM-Hash
Der Angreifer hat jetzt bereits den Passwort-Hash abgefangen (orangene Ausgabe in der Mitte).

Jetzt hat der Angreifer mehrere Möglichkeiten, wie er weiter vorgehen kann. Er könnte einen Relaying-Angriff versuchen (dazu später mehr) oder er versucht den NTLMv2-Hash mit einem Tool wie z.B. hashcat zu cracken und so zum Klartextpasswort zu kommen.

Hash mit hashcat cracken

Mit hashcat kann nun versucht werden das Klartextpasswort für den Hash herauszufinden. Dafür eignen sich beispielsweise der Dictionary- oder der Brute-Force-Angriff. Installiert werden kann hashcat mit folgendem Befehl:

sudo apt install hashcat
Für Windows kann hashcat von der offiziellen Homepage heruntergeladen werden.
Dictionary-Angriff

Dieser Angriff versucht eine Liste von bekannten Passwörtern auszuprobieren, bis das richtige Passwort gefunden ist. Dafür werden meist große Passwortlisten oder Passwörter aus bekannten Leaks verwendet. Bekannte Passwortlisten sind beispielsweise CrackStation's Password Cracking Dictionary oder rockyou.txt.

Ein Angriff sähe beispielsweise wie folgt aus:

hashcat -a 0 -m 5600 hashes.txt rockyou.txt -o passwords.txt

Der Parameter "a" gibt den Angriffstyp an. 0 steht dabei für den Dictionary-Angriff. Mit "m" wird der Hashtyp angegeben. 5600 steht dabei für NTLMv2 bzw. Net-NTLMv2 (NTLMv2 und Net-NTLMv2 sind Synonyme). Als nächstes wird die Textdatei mit den Hashes angegeben. Die Hashes die der Responder ausgegeben hat, können dort einfach Ziele für Zeile eingefügt werden. Schließlich kann noch mit "o" eine Ausgabedatei angegeben werden.

Die Vorbereitungen für den Dictionary-Angriff sind abgeschlossen.

Weil der Benutzer Peter in diesem Beispiel ein sehr schwaches Kennwort gewählt hat, war der Dictionary-Angriff bereits nach kurzer Zeit erfolgreich:

hashcat Dictionary-Angriff
Das Kennwort wird schließlich an das Ende des jeweiligen Hash-Eintrags in der Ausgabedatei geschrieben.
Brute-Force-Angriff

Ist der Dictionary-Angriff nicht erfolgreich, kann noch durch rohe Gewalt versucht werden, das Kennwort zu knacken. Das kann wie folgt gelingen:

hashcat -a 3 -m 5600 hashes.txt -1 ?l?u?d?s ?1?1?1?1?1?1?1 -o password.txt

Die 3 bei "a" steht hier für einen Brute-Force-Angriff. Mit "-1" kann noch angegeben werden, welche Zeichen das Passwort enthalten könnte:

  • ?l steht für Kleinbuchstaben.
  • ?u steht für Großbuchstaben.
  • ?d steht für Zahlen.
  • ?s steht für Sonderzeichen.

"?1?1?1?1?1?1?1" bedeutet, dass das gesuchte Passwort aus sieben Zeichen besteht. Wenn ein Angreifer nicht weiß, wie lang das Kennwort ist, wird es viel aufwändiger. Er kann dann eine Mindest- oder Maximallänge angeben:

-i --increment-min 8 --increment-max 12

Mehr Informationen zu den möglichen Parametern sind in der offiziellen Dokumentation zu finden. Weitere Erklärungen zu den Passwortmasken sind ebenfalls in der offiziellen Dokumentation zu finden.

Wenn der Angreifer die Passwortrichtlinien oder weitere Informationen über ein Passwort kennt, lässt sich ein Brute-Force-Angriff effizienter gestalten, da er beispielsweise die Mindestlänge oder erlaubte Passwortzeichen weiß. Hat ein Angreifer bereits Zugriff auf einen Domänenrechner (beispielsweise durch einen Relaying-Angriff), kann er die gültigen Passwortrichtlinien einfach einsehen.

Hier zeigt sich jetzt, dass ein möglichst komplexes Passwort sehr wichtig ist, um den Angreifer das Knacken zu erschweren, sollte er bereits an den Hash gekommen sein.

Der Relaying-Angriff

Wenn der Name Resolution Response-Angriff erfolgreich war, das Passwort sich aber nicht so einfach cracken lässt, beispielsweise weil es sehr komplex ist, kann der Angreifer auch versuchen sich mit Hilfe eines Relaying-Angriffs, also Weitereichen des Passwort-Hashes, an seinem eigentlichen Ziel zu authentifizieren. Beispiel: Der Benutzer "Peter" arbeitet immer auf seiner Workstation "LABCLIENT01" und hat zusätzlich administrative Berechtigungen auf die Workstation "LABCLIENT02" und dem Server "LABSRV2012R2". Peter wollte auf einem Netzwerkshare zugreifen und hat durch Vertippen einen nicht existierenden DNS-Namen angefragt. Der Angreifer konnte durch den Name Resolution Response-Angriff zwar den Passwort-Hash von Peter abfangen, diesen jedoch nicht cracken, weil das Passwort zu stark ist. Der Angreifer kann jetzt durch einen Relaying-Angriff den Hash einfach an sein eigentliches Ziel "LABCLIENT02" oder "LABSRV2012R2" weiterreichen und sich dort authentifizieren. Er muss das Passwort für diesen nachgelagerten Angriff also gar nicht kennen.

LLMNR NBT-NS Relaying-Angriff
Durch den Relaying-Angriff versucht der Angreifer sich an einem weiteren Host im Netzwerk per Passwort-Hash des Opfers zu authentifizieren.

Voraussetzungen für diesen Angriff:

  • Opfer, Angreifer und das Angriffsziel müssen in der selben Broadcast-Domäne sein.
  • LLMNR und/oder NBT-NS muss bei dem Opfer aktiviert sein.
  • SMB-Signierung auf dem Zielsystem darf nicht erzwungen sein.
  • Firewall auf dem Zielsystem darf die SMB-Anfrage vom Angreifer nicht blockieren.
  • Der abgefangene Passwort-Hash muss zu einem Benutzer mit ausreichenden Rechten auf dem Zielsystem gehören.

Erweiterung der Laborumgebung

Die Laborumgebung aus dem ersten Angriff habe ich für diesen nachgelagerten Angriff etwas erweitert. Hinzugekommen sind zwei Angriffsziele, auf die wir einen Relaying-Angriff starten möchten.

Domänencontroller / DNS-Server
Windows Server 2019
Hostname: LABDC01.lab.local
IP-Adresse: 192.168.0.2

Opfer
Windows 10 20H2
Hostname: LABCLIENT01.lab.local
IP-Adresse: 192.168.0.200 (DHCP)
Benutzer: LAB\peter

Angriffsziel 1 (Ziel für Relaying-Angriff)
Windows 10 20H2
Hostname: LABCLIENT02.lab.local
IP-Adresse: 192.168.0.202 (DHCP)
Lokaler Administrator: LAB\peter
Windows Firewall: deaktiviert

Angriffsziel 2 (Ziel für Relaying-Angriff)
Windows Server 2012 R2
Hostname: LABSRV2012R2.lab.local
IP-Adresse: 192.168.0.204 (DHCP)
Lokaler Administrator: LAB\peter
Windows Firewall: deaktiviert

Angreifer
Ubuntu 20.04 LTS
Hostname: HACKERPC
IP-Adresse: 192.168.0.205 (DHCP)

In dieser Laborumgebung habe ich die Windows Firewall der beiden Angriffsziele deaktiviert, um den Test einfacher zu gestalten. Es hätte aber auch genügt eingehenden SMB-Traffic zu erlauben.

Der Relaying-Angriff in der Praxis

Wir wissen jetzt wie der Name Resolution Response-Angriff funktioniert. Diesen wandeln wir etwas ab. Jetzt wollen wir nicht bloß den Passwort-Hash abfangen, sondern diesen an einen weiteren Host (Angriffsziel 1 und 2) weiterleiten, um uns dort ohne Passwort zu authentifizieren.

Für diesen Angriff kann der Angreifer nach wie vor den Responder nutzen. Allerdings wird für diesen Angriff noch ein weiteres Tool ntlmrelayx.py, welches Bestandteil von impacket ist, benötigt. Da das neue Tool ntlmrelayx.py auf HTTP- und SMB-Anfragen lauscht, müssen diese Protokolle zuvor im Responder deaktiviert werden. Das gelingt wie folgt:

cd /home/hacker/Downloads/Responder-master/
nano Responder.conf
responder.conf
Die Dienste SMB und HTTP müssen im Responder deaktiviert werden, damit diese später von ntlmrelayx.py verwendet werden können.

Als nächstes kann schließlich ntlmrelayx.py installiert werden. Die Installation auf dem Angreifer-PC gelingt wie folgt:

sudo apt install python3-pip
cd /home/hacker/Downloads/
wget https://github.com/SecureAuthCorp/impacket/archive/master.zip
unzip master.zip
cd impacket-master/
pip3 install -r requirements.txt
sudo python3 setup.py install

Ab jetzt kann in jedem Verzeichnis das Skript ntlmrelayx.py ausgeführt werden.

Der Responder kann jetzt wie folgt gestartet werden:

cd /home/hacker/Downloads/Responder-master/
sudo python3 Responder.py -I enp0s3 -rdw
Der Parameter "I" gibt hier wieder das Netzwerkinterface auf dem Angreifer-PC an, auf dem auf Anfragen des Opfers gelauscht werden soll.

Das Skript ntlmrelayx.py wird wie folgt gestartet:

sudo ntlmrelayx.py -t 192.168.0.202 -smb2support
Die IP-Adresse 192.168.0.202 ist die IP-Adresse von unserem ersten Angriffsziel "LABCLIENT02".
ntlmrelayx.py
ntlmrelayx.py wartet auf dem Angreifer-PC jetzt, bis ein beliebiges Opfer im Netzwerk eine LLMNR- oder NBT-NS-Anfrage stellt.

Wenn jetzt ein Teilnehmer im Netzwerk, z.B. Peter auf seiner Workstation LABCLIENT01 (192.168.0.200) einen nicht (mehr) existierenden DNS-Namen versucht aufzulösen, startet der Angriff. Peter versucht jetzt sich auf seiner Workstation mit einer Netzwerkfreigabe "\\gibtesnicht" zu verbinden.

Peter versucht einen DNS-Namen aufzulösen, der nicht (mehr) vorhanden ist. Er löst dadurch einen LLMNR oder NBT-NS Broadcast aus und ermöglicht den Relaying-Angriff.
ntlmrelayx.py dump SAM Hashes
Der Relaying-Angriff war erfolgreich und es wurden sogar weitere wertvolle Passwort-Hashes ausgegeben.

Der Relaying-Angriff war erfolgreich. Das sehen wir z.B. in der oberen Hälfte des Bildes an der Zeile "[*] Authenticating against smb://192.168.0.202 as LAB/PETER SUCCEED" oder an den Passwort-Hashes der SAM-Datenbank (rote Markierung im Bild) des Angriffsziels. Der Angreifer hat an dieser Stelle jetzt die LM- und/oder NT-Hashes sämtlicher lokaler Benutzer auf LABCLIENT02. Diese Hashes kann er jetzt versuchen zu cracken. Außerdem sind diese Hashes ausreichend für einen späteren Pass-the-Hash-Angriff, falls der Angreifer die Passwörter nicht cracken kann.

Schauen wir uns unser Angriffsziel "LABCLIENT02" etwas genauer an, sehen wir ebenfalls, dass es einen erfolgreichen Login gab:

Unser Angriffsziel "LABCLIENT02" hat einen erfolgreichen Login von Peter protokolliert. Auffällig ist, dass der protokollierte Arbeitsstationsname von unserem Opfer "LABCLIENT01", die protokollierte IP-Adresse "192.168.0.205" aber vom Angreifer stammt.

Bis hierhin haben wir es schon mit einer schwerwiegenden Sicherheitslücke zu tun. Aber es geht noch schlimmer. Denn das Tool ntlmrelayx.py kann auch direkt versuchen einen Befehl auf dem Zielhost auszuführen:

sudo ntlmrelayx.py -t 192.168.0.202 -smb2support -c "mkdir C:\Temp"

Auf dem Angreifer-PC sehen wir jetzt, dass die Authentifizierung zwar erfolgreich war, der Befehl "mkdir C:\Temp" aber nicht ausgeführt wurde:

Die Authentifizierung war zwar erfolgreich, der eigentliche Befehl wurde jedoch nicht ausgeführt.

Wenn wir das auf LABCLIENT02 (192.168.0.202) überprüfen, lässt sich auch verifizieren, dass der Login erfolgreich war (Windows Ereignisanzeige), und dass der Ordner C:\Temp nicht angelegt wurde.

Der Angreifer überlegt mit jeder Information, die er hat "Was kann ich hiermit anfangen?". Er hat bis jetzt diverse Passwort-Hashes, die er versuchen kann zu cracken oder für Pass-the-Hash-Angriffe verwenden kann. Er kann an dieser Stelle auch noch mehr Energie aufbringen, in der Hoffnung, dass sein gewünschter Befehl "mkdir C:\Temp" doch noch erfolgreich ausgeführt wird. Aber der Angreifer könnte sich auch neue Angriffsziele im Netzwerk suchen. Wir versuchen den gleichen Angriff also jetzt auf unser Angriffsziel 2 "LABSRV2012R2" (192.168.0.204). Da es langweilig ist einen Ordner zu erstellen, verändern wir unseren Befehl etwas:

sudo ntlmrelayx.py -t 192.168.0.204 -smb2support -c "powershell.exe (net user hacker Test123 /add),(net localgroup Administratoren hacker /add)"

Unser Peter auf LABCLIENT01 versucht jetzt wieder einen Netzwerkshare zu erreichen, den es nicht gibt, beispielsweise \\gibtesnicht und triggert dadurch eine LLMNR- und/oder NBT-NS-Anfrage und ermöglicht den Angriff:

ntlmrelayx.py Relaying-Angriff
Der Angreifer hat mittlerweile ein Ziel gefunden, auf dem er seine Befehle erfolgreich abfeuern kann.
Der Angreifer verfügt jetzt über einen Benutzer mit Administratorrechten auf dem Zielcomputer.

Ich denke, dass man an dieser Stelle ganz gut sieht, wie mächtig dieser Relaying-Angriff ist. Ohne Zugangsdaten zu wissen, konnte sich der Angreifer durch die Weitergabe des Passwort-Hashes an einem weiteren Host authentifizieren und dort Befehle ausführen, beispielsweise um einen administrativen Benutzer zu erstellen, den der Angreifer fortan verwenden kann. Was wäre nun, wenn der Angreifer den Passwort-Hash von einem Domänenadministrator statt von Peter abgefangen hätte? Selbst in der aktuellen Situation ist der Angreifer dem Domänenadministrator schon ein ganzes Stück näher. Auf diesem Host findet er vielleicht weitere Informationen oder Passwort-Hashes zu Domänenbenutzern. Falls sich in der Vergangenheit ein Domänenadministrator auf diesem Host angemeldet hat, vielleicht sogar den Passwort-Hash des Domänenadministrators...

Schutz vor Name Resolution Response- und Relaying-Angriff

Wir haben eindrucksvoll gesehen, wie mächtig diese beiden Angriffe sind. Ich denke, dass jedem einleuchtet, dass diese unter allen Umständen unterbunden werden sollten. Einige wichtige Erkenntnisse sollten sein:

  • Windows Firewall aktivieren und möglichst sicher konfigurieren, dann hätte der Relaying-Angriff eventuell nicht geklappt.
  • Mit der Vergabe von Berechtigungen geizig sein, damit es einen Angreifer erschwert wird sich im Netzwerk auszubreiten.
  • Sicherheitsupdates alleine reichen nicht aus. Windows Server 2012 R2 bekommt immer noch Sicherheitsupdates und alle Sicherheitsupdates waren für meinen Versuch installiert, der Relaying-Angriff hat aber auf Anhieb funktioniert. Auf dem Windows 10 20H2 Client hat er hingegen nicht vollständig funktioniert. Eventuell hätte der Angreifer es durch Ausprobieren und mit viel Geduld aber noch hinbekommen.
  • Sich niemals mit hochprivilegierten Accounts wie einem Domänenadministrator auf Clients anmelden. Denn wenn ein Angreifer Zugriff auf einen solchen Client hat, kann er gegebenenfalls den Passwort-Hash des Domänenadministrators erlangen.
  • Möglichst starke Passwörter verwenden, damit das Cracken des Passwort-Hashes erschwert oder gar unmöglich wird.

Abgesehen von den eben genannten grundsätzlichen Tipps kann man sich vor den beiden vorgestellten Angriffen durch relativ einfache technische Maßnahmen schützen:

  • Netzwerkweites Deaktivieren von LLMNR und NBT-NS (Schutz vor Name Resolution Response- und Relaying-Angriff)
  • Netzwerkweites Erzwingen von SMB-Signing (Schutz vor Relaying-Angriff)

SMB-Signing per GPO erzwingen

Die SMB-Signierung kann relativ einfach per GPO auf Server und Clients erzwungen werden. Der Angreifer kann ziemlich einfach herausfinden, ob sein eigentliches Ziel SMB-Signing erzwungen hat oder nicht:

sudo apt install nmap
nmap -p 445 --script smb2-security-mode 192.168.0.204/32
nmap SMB-Signing
Per nmap lässt sich herausfinden, wie das SMB-Signierung auf den einzelnen Hosts konfiguriert ist.

Wenn das SMB-Signing zwar aktiviert, aber nicht erzwungen ist, kann ein Angreifer das SMB-Protokoll für seinen Relaying-Angriff ausnutzen. Denn wenn das Signing nicht erzwungen ist, reicht es wenn ein Kommunikationspartner SMB-Signing nicht unterstützt, damit auf SMB-Signing verzichtet wird.

Die entsprechende GPO für das SMB-Signing ist in folgendem Pfad zu finden: Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen.

Dort sind die beiden Richtlinien "Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)" und "Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)" zu aktivieren:

GPO SMB-Signing
Per GPO kann das SMB-Signing erzwungen werden.
Es ist zu beachten, dass mit der Unterteilung "Client" und "Server" nicht die Unterteilung von Client- und Serverbetriebssystem gemeint ist, sondern welcher Kommunikationspartner den SMB-Dienst in Anspruch nimmt (Client) bzw. bereitstellt (Server).

Prüfen, dass die neue GPO erfolgreich verteilt wurde und funktioniert, lässt sich wie folgt:

nmap SMB-Signing
Der nmap des Angreifers zeigt jetzt auch, dass SMB-Signing erzwungen ist und er mit seinem Relaying-Angriff schlechte Chancen hat.
ntlmrelayx.py SMB-Signing
Der Relaying-Angriff funktioniert jetzt entsprechend auch nicht mehr. Der Angreifer bekommt ein "Access Denied".

LLMNR per GPO deaktivieren

LLMNR lässt sich relativ einfach per GPO deaktivieren. Die entsprechende GPO ist in folgendem Pfad zu finden: Computerkonfiguration > Richtlinien > Administrative Vorlagen > Netzwerk > DNS-Client. Die Richtlinie heißt "Multicastnamensauflösung deaktivieren" und ist entsprechend zu aktivieren:

GPO LLMNR
LLMNR lässt sich mit einer GPO deaktivieren.

Dass die GPO angewendet wurde, lässt sich in der Registry feststellen. Der DWORD-Wert "EnableMulticast" unter "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" sollte jetzt auf "0" stehen.

Die eigentliche Sicherheitslücke ist allerdings noch nicht geschlossen. Auf dem Angreifer-PC sehen wir, dass zwar keine LLMNR-Pakete mehr empfangen werden, aber immer noch NBT-NS-Anfragen verschickt werden, was der Angreifer ausnutzen kann, um sich als "gibtesnicht" auszugeben:

LLMNR-Pakete werden nicht mehr versendet, dafür aber immer noch NBT-NS-Pakete. Wie hier zu sehen, kann der Angreifer (192.168.0.205) sich immer noch als "gibtesnicht" ausgeben.

Es reicht also nicht LLMNR zu deaktivieren. Es muss ebenfalls NBT-NS deaktiviert werden.

NBT-NS deaktivieren

NBT-NS ist nicht ganz so einfach zu deaktivieren wie LLMNR, weil es keine vorgefertigte GPO dafür gibt. Dennoch möchte ich einen Weg zeigen, der meiner Meinung nach auch akzeptabel ist.

In den erweiterten Eigenschaften der TCP/IP-Einstellungen im Netzwerkadapter ist die entsprechende NBT-NS-Einstellung zu finden:

NetBIOS Netzwerkadapter
Die NBT-NS-Einstellungen werden auf Netzwerkadapterebene konfiguriert.

Der dazugehörige Wert wird windowstypisch in der Registry gespeichert. Im Pfad "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces" befindet sich für jedes Netzwerkinterface ein Unterordner im Format Tcpip_INTERFACEID. In diesen Schlüsseln befinden sich wiederum die gesuchten Einträge "NetbiosOptions".

NetBIOS Registry
Die NetBIOS-Einstellungen sind in der Registry pro Netzwerkinterface gespeichert.

Der Eintrag "NetbiosOptions" kann drei Zustände haben:

  • 0 NetBIOS-Einstellung werden vom DHCP-Server entgegengenommen. Als Fallback (z.B. wenn der DHCP-Server keine NetBIOS-Einstellung übermittelt oder eine statische IP-Adresse konfiguriert wurde) wird NetBIOS aktiviert.
  • 1 NetBIOS ist aktiviert.
  • 2 NetBIOS ist deaktiviert.

Meine Lösung zur Deaktivierung von NetBIOS sieht wie folgt aus: Per DHCP-Option NetBIOS deaktivieren und zusätzlich ein Skript erstellen und per GPO verteilen, welches NetBIOS deaktiviert. Dadurch sind alle DHCP-Clients, unabhängig von der Domänenmitgliedschaft, und alle Domänenmitglieder berücksichtigt.

NBT-NS per DHCP-Option deaktivieren

Auf dem DHCP-Server muss die Konfiguration "001 Microsoft NetBIOS-Deaktivierungsoption" aktiviert und auf "0x2" gesetzt werden:

NetBIOS deaktivieren per DHCP-Option
Per DHCP-Option lässt sich NetBIOS für alle DHCP-Clients deaktivieren.
Diese Einstellung belässt "NetbiosOptions" in der Registry natürlich auf "0", erstellt aber einen zusätzlichen DWORD-Wert "DhcpNetbiosOptions" mit dem Wert "2".

NBT-NS per Skript deaktivieren

Da in einem Netzwerk in der Regel nicht alle Geräte ihre IP-Konfiguration über einen DHCP-Server beziehen, erstelle ich zusätzlich ein Skript, welches ich per GPO verteile.

Zuerst erstelle ich ein neues Skript "nbt-ns-deaktivieren.cmd" in der NETLOGON-Freigabe (C:\Windows\SYSVOL\sysvol\DOMAIN\scripts) auf dem Domänencontroller mit folgendem Inhalt:

wmic nicconfig where (TcpipNetbiosOptions!=Null and TcpipNetbiosOptions!=2) call SetTcpipNetbios 2

Die GPO, mit der das Skript schließlich verteilt wird, ist unter folgendem Pfad zu finden: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Skripts (Start/Herunterfahren). Dort kann per Doppelklick auf "Starten" das Skript entsprechend ausgewählt werden:

GPO NetBIOS
Per GPO wird unser Skript zum Deaktivieren von NetBIOS verteilt.
Der Pfad zum Skript muss natürlich auf den Geräten wo die GPO ausgeführt wird verfügbar sein.

Das Skript setzt schließlich bei allen aktiven Netzwerkadaptern den Wert für "NetbiosOptions" in der Registry auf "2".

Verifizieren, dass LLMNR und NBT-NS deaktiviert ist

Ist LLMNR und NetBIOS deaktiviert, ist auch der Ping von Peter nicht mehr erfolgreich (Am Anfang des Artikels wurde der Ping noch vom Angreifer beantwortet). Außerdem werden keine LLMNR und NBT-NS-Pakete mehr versendet:

Der Angreifer kann jetzt nicht mehr auf Anfragen eines Netzwerkteilnehmers antworten.
An dem Angreifer-PC kommen jetzt keine LLMNR und NBT-NS-Anfragen mehr an.

Damit ist die Sicherheitslücke, die mit LLMNR und NBT-NS einherkommt, vollständig geschlossen.


Weiterführende Links
https://en.hackndo.com/ntlm-relay/

Quellen
https://www.terreactive.ch/de/cyber_blog/rattenfaenger-im-netz-ntlm-relaying-angriff
https://www.crowe.com/cybersecurity-watch/netbios-llmnr-giving-away-credentials
https://infinitelogins.com/2020/11/23/disabling-llmnr-in-your-network/
https://infinitelogins.com/2020/02/11/abusing-llmnr-nbtns-part-1-capturing-hashes/
https://infinitelogins.com/2020/04/16/abusing-llmnr-nbtns-part-2-cracking-ntlmv2-hashes/
https://infinitelogins.com/2020/11/13/abusing-llmnr-nbtns-part-3-relaying-hashes/
https://www.tenaka.net/smb-relay-attack
https://docs.microsoft.com/de-de/troubleshoot/windows-server/networking/disable-netbios-tcp-ip-using-dhcp

Seit mehreren Jahren begeistere ich mich privat und beruflich für die IT. Das habe ich dann auch zum Anlass genommen, diesen Blog ins Leben zu rufen, um dort praxisnahe Tutorials über verschiedene IT-Themen zu schreiben und meine selbst geschriebene Software zu veröffentlichen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.