Um den LLMNR-Poisoning Angriff zu erklären gehen wir zunächst auf die Grundlagen ein.
Link-local Multicast Name Resolution (LLMNR) Poisoning bewirkt, dass Datenverkehr in einem Netzwerk abgefangen und modifiziert werden kann. Dies ist mit diversen Tools ohne größere Kenntnis möglich und kann zu großem Schaden führen. Es besteht meist das Ziel Informationen zu sammeln, Passwort Hashes zu erlangen oder weitere Lücken im Netzwerk auszunutzen. Das Ganze fällt unter die Man-In-The-Middle Angriffstechniken und eröffnet viele neue Angriffsvektoren.
LLMNR gehört zur Protokollfamilie der Namensauflösung. Ähnlich wie NetBIOS ist es ein Urgestein der Microsoft bzw. Windows Geschichte. Es kommt immer dann zum Einsatz, wenn ein Computer / Server eine Anfrage absendet und vom internen DNS eine negative Antwort erhält. Sobald dies der Fall ist, sucht der Computer / Server mit Hilfe von LLMNR per Multicast nach der gewünschten Ressource. Dieser Ablauf ist seit Dekaden ein Microsoft internes Vorgehen um sicherzustellen, dass die Namensauflösung auch ohne die Einstellung von DNS funktioniert.
Dieses Vorgehen soll es dem User und Administrator einfacher machen, da weniger Fehler in Bezug auf die Namensauflösung entstehen, stellt aber zur gleichen Zeit einen Angriffsvektor bereit den wir gleich beschreiben werden. Microsoft hat LLMNR in jedem OS per Default aktiviert, wobei es jedoch in üblichen Firmennetzwerken nicht benötigt wird, wenn ein interner DNS Server im Einsatz ist und jedes System im Netzwerk diesen benutzt.
Wie oben schon erläutert, kommt LLMNR ins Spiel wenn der DNS-Server keine passende Antwort liefern kann.
Das heißt es wird versucht im lokalen Netz eine Antwort zu finden, dies kommt meist dann vor, wenn der User sich bei der Suche einer Netzwerkressource vertippt, sich nicht im richtigen Netz befindet, keinen DNS Server konfiguriert hat oder z.B. vergessen hat sich mit dem VPN zu verbinden und somit die gewünschte Netzwerkressource nicht erreichen kann.
In dem Fall kann der Angreifer dem Client eine Rückmeldung senden, dass er die Netzwerkressource kennt und ihm die IP der gewünschten Ressource schicken. Über diese IP soll er die Netzwerkressource erreichen können, kommt jedoch beim vom Angreifer gehosteten Server an.
Der Client sendet nun eine Anfrage an die ihm mitgeteilte IP-Adresse. Damit die vermeintliche Berechtigung des Clients aber geprüft werden kann verlangt der Angreifer vom Client nun eine Authentifizierung. Diese kann über Basic-Auth oder Challenge-Response (wie z.B. Net-NTLMv2) stattfinden. Nach der Authentifizierung bekommt der Client nun eine Fehlermeldung, sodass es aussieht, als wurde die Ressource doch nicht gefunden. In den meisten Fällen findet die Authentifizierung ohne User-Interaction statt.
Sollte der Angreifer Basic-Authentifizierungen erhalten haben, kann er mit diesen Base64 kodierten Zugangsdaten auf Ressourcen zugreifen. Hat der Angreifer z.B. Net-NTLMv2 Authentifizierungen erhalten, kann er versuchen diese zu cracken um so das Passwort des jeweiligen Nutzers zu erlangen.
Im Zusammenhang mit anderen Fehlkonfigurationen ist es auch möglich Challenge-Response Authentifierungen weiterzuleiten um somit direkten Zugriff auf Systeme zu bekommen. Dies wird jedoch in einem späteren Blogartikel thematisiert.
Zur technischen Umsetzung des soeben erklärten LLMNR Poisoning Angriffs kann das Tool Responder verwendet.
Zum Start von Responder kann der folgende Befehl verwendet werden:
responder -I
Im Beispielfoto hat sich ein Client auf die Antwort des Angreifers mit Net-NTLMv2 authentifiziert.
Responder bietet eine Vielzahl von Einstellungsmöglichkeiten und Servern und kann auch für gezielte Angriffe konfiguriert werden.
Um diese Art des Angriffs zu verhindern, ist die einfachste und effektivste Art LLMNR auf dem Computer / Server direkt, oder per GPO zu deaktivieren.
Die wenigsten Dienste haben heutzutage noch einen realen Bedarf an Abfragen dieser Art über Multicast.
Richtlinie\Administrative Vorlagen\Netzwerk\DNS-Client
unter Einstellungen: „Multicastnamensauflösung deaktivieren“ * -> Aktiviert
* Wichtig ist hierbei zu beachten, dass der Name der GPO in der deutschsprachigen Version zweimal vorkommt. Die Untere der beiden GPO’s ist in diesem Kontext die Richtige und sollte durch einen Push direkt oder beim nächsten Neustart auf dem Client Anwendung finden.
Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client
unter Einstellungen: “Turn OFF Multicast Name Resolution” -> Enabled
Um einen Angreifer im Netzwerk zu erkennen bieten sich Tools an welche gezielt LLMNR Anfragen für nicht existente Ressourcen ins Netzwerk senden. Bekommt man nun Anworten auf diese Anfragen befindet sich ein Angreifer im Netzwerk der auf LLMNR Anfragen wartet.
Sollten Sie die GPO wie empfohlen konfiguriert haben, lohnt es sich zur Überprüfung Traffic auf UDP 5355 zu monitoren.
In diesem Zuge sehen Sie ebenfalls, ob es Probleme bei der Umsetzung der GPO gab, oder neue Systeme möglicherweise nicht nach diesem neuen Standard konfiguriert wurden. Wenn Sie dies beachten, haben Sie einen Angriffsvektor im Optimalfall dauerhaft geschlossen.
Zur aktiven Erkennung eines Angreifers im Netzwerk können hierzu Tools wie Respounder, Conveigh oder HoneyCreds verwendet werden. Hier am Beispiel von Respounder:
Angreifer startet den Responder
Verwendete IP-Adresse des Angreifers
Responder Angriff von der IP 192.168.50.20 erkannt
git clone https://github.com/codeexpress/respounder
cd respounder
go build -o respounder respounder.go
./respounder -hostname test123
Nach Durchführung der oben genannten GPO Einstellungen und dem Honeypot kann es sein, dass Sie leider feststellen müssen, dass es Angreifer in Ihrem Netz gibt.
Hier besteht die Möglichkeit durch den Honeypot Informationen über den Angreifer zu Sammeln und zu prüfen ob die GPO tatsächlich von allen Clients übernommen wurde.
Wenn bekannt ist von welcher IP der Angriff erfolgt, kann der Port / MAC Adresse des Angreifers nach ausreichender Informationsgewinnung gesperrt werden um weitere Aktivitäten zu unterbinden.
Besonders im Notfall raten wir Ihnen dazu fachliche Hilfe hinzuzuziehen und so viel wie möglich zu dokumentieren.
Bei der Befassung mit den Folgenden ISMS-Framework-Controls spielt die Schwachstelle und deren Behebung eine Rolle:
ISO 27001:
A. 9.1.2 Zugang zu Netzwerken und Netzwerkdiensten
A.13.1.2 Sicherheit von Netzwerkdiensten
BSI Grundschutz:
NET.1.1.A7
Für die Schwachstelle gibt es einen Eintrag im MITRE ATT&CK Framework:
PSN-ID: PS-TN-2020-0007
