Kompromittierung von Windows durch LLMNR Spoofing und NTLM Relaying
Mein Name ist Hase
Name-Spoofing ist Grundlage einer Reihe effizienter Techniken zum Kompromittieren von Windows-Netzen. Frei verfügbare Angriffswerkzeuge erlauben das erstaunlich einfache Durchführen solcher Attacken.
Wenn es um das Zuordnen von Hostnamen zu IP-Adressen geht, kommt Systemadministratoren zunächst DNS (Domain Name System) in den Sinn. Schlägt das Auflösen der Namen damit fehl, verwendet Windows eine Reihe von Protokollen, die jeder interne Angreifer wesentlich leichter manipulieren kann. Geeignete Angriffsmodule finden sich etwa in von Geheimdiensten entwickelter Malware wie Duqu 2.0. Grund genug, sich mit den Grundlagen der Schwachstellen auseinanderzusetzen.
Ein Windows-System, das einen Netzwerknamen auflösen will, prüft zunächst die lokale hosts-Datei. Findet es dort keinen Eintrag, sendet es eine Anfrage an den in den Netzwerkeinstellungen vorgegebenen DNS-Server. Schickt der keine IP-Adresse, sucht Windows im lokalen Netz ein System mit diesem Namen. Bei diesem Vorgang kommen folgende Protokolle zum Einsatz:
– NBT-NS (NetBIOS-Nameservice) ist Teil des ursprünglichen NetBIOS-Stacks von Windows, eines Vorgängers des SMB-Protokolls (Server Message Block). Daher unterliegt NBT-NS diversen Einschränkungen: Das Protokoll kommt nicht mit IPv6 zurecht, und NetBIOS-Namen dürfen maximal 15 Zeichen lang sein.
– LLMNR (Link-Local Multicast Name Resolution) hat Microsoft mit Windows Vista eingeführt. Es handelt sich um ein separates, nicht an den NetBIOS-Stack gebundenes Protokoll. Anders als NBT-NS kennt LLMNR IPv6, und die Zeichenlänge ist nicht begrenzt.
Zunächst versucht Windows mittels LLMNR die Namen aufzulösen. Schlägt das fehl und ist der abgefragte Name nicht länger als 15 Zeichen, folgt ein Anlauf via NBT-NS. Beide Protokolle arbeiten ähnlich: Sie senden eine Anfrage an die Broadcast-Adresse des lokalen Netzwerks, die an alle beteiligten Komponenten weitergeleitet wird. Sollte sich eine von ihnen von dem gefragten Hostnamen angesprochen fühlen, meldet es sich, andernfalls ignoriert das System die Anfrage.
Ziemlich häufig: LLMNR-/NBT-NS-Anfragen
Da eine Active-Directory-Umgebung zwingend einen DNS-Server voraussetzt, scheint es naheliegend, dass in einem solchen Netz nur selten LLMNR-/NBT-NS-Anfragen versendet werden. Die Analyse des Datenverkehrs zeigt in der Regel jedoch ein anderes Bild. Die Ursachen solcher Anfragen reichen von Tippfehlern der Nutzer über Aufrufe nicht mehr vorhandener Netzwerkfreigaben bis zu Auto-Konfigurationsprotokollen wie WPAD (dazu mehr weiter unten).
Wer sich einen Überblick über LLMNR- und NBT-NS-Anfragen verschaffen möchte, kann den lokalen Netzwerkverkehr mithilfe des Netzwerkanalysewerkzeugs Wireshark (Abbildung 1) und des folgenden Display-Filters prüfen:
udp.port == 5355 || nbns
Ein Angreifer, der beispielsweise über einen Trojaner in das Windows-Netz vorgedrungen ist, kann LLMNR-/NBT-NS-Anfragen beantworten und so ein System seiner Wahl als Zielsystem ausgeben. Dies geht wesentlich leichter, als eine DNS-Antwort zu fälschen, da er die notwendigen Informationen direkt aus der Broadcast-Anfrage entnehmen kann und nicht wie bei einer DNS-Anfrage erraten muss. Zudem muss der Eindringling bei einer DNS-Anfrage schneller antworten als der DNS-Server. Bei LLMNR/NBT-NS ist dies in der Regel nicht der Fall, da ein System, das die an die Broadcast-Adresse gesendete Anfrage beantworten könnte, nicht existiert.