Falsch verbunden

von Dr. Matthias Wübbeling

Alte Servernamen verschwinden selten vollständig aus einem Netz. Anmeldeskripte, Laufwerkszuordnungen oder Anwendungen fragen sie oft noch Jahre später ab. Der Security-Tipp in diesem Monat zeigt Ihnen mit Pretender ein Tool, das wie ein Angreifer auf solche fehlgeleiteten Anfragen antworten und einen Windows-Client auf die falsche Adresse lenken kann. In einem isolierten Testnetz beobachten wir den Ablauf und leiten daraus Maßnahmen zur Absicherung ab.

Vermutlich kennen Sie das Dilemma: Alte Dateiserver verschwinden aus der Infrastruktur, neue treten an ihre Stelle – doch auch nach Jahren geistert der Servername mitunter weiter durchs Netz, egal, was Sie dagegen unternehmen. Er steht vielleicht in einer Gruppenrichtlinie, einem Makro oder einer geplanten Aufgabe auf irgendeinem noch aktiven System. Greifen Sie von einem Windows-Client etwa auf "\alter-dateiserver\abrechnung" zu, fragt Windows zunächst den konfigurierten DNS-Server. Fehlt dort ein passender Eintrag, liegt die Vermutung nahe, dass die Verbindung scheitert.

Je nach Windows- und Netzwerkkonfiguration versucht das System aber weitere Verfahren. Dazu gehören etwa Link-Local Multicast Name Resolution, kurz LLMNR, Multicast DNS und das schon recht betagte NetBIOS Name Service. Der Rechner stellt damit sinngemäß die Frage nach dem Host ins lokale Netz: Kennt hier jemand "\alter-dateiserver"?

Genau hier beginnt das Problem, das mitunter Sicherheitsaspekte berührt. Ein beliebiges System im gleichen Netzwerksegment kann nämlich auf diese Frage antworten und behaupten, selbst der gesuchte Server zu sein. Der Client erhält bei diesen Verfahren keinen verlässlichen Nachweis, dass die Antwort tatsächlich vom vorgesehenen System stammt – und Sie als Nutzer erst recht nicht.

Ein Angreifer muss für diesen Angriff also nicht zwingend einen DNS-Server kompromittieren. Es reicht schon, auf eine falsche (klassisch etwa durch einen Tippfehler) oder veraltete Anfrage schneller zu antworten als das legitime System.

Bedrohungsszenario

Eine manipulierte Namensauflösung übernimmt natürlich noch keinen Windows-Rechner. Sie liefert aber schon eine falsche Wegbeschreibung. Der Ablauf gliedert sich typischerweise in sechs Schritte: Eine Anwendung will "\alter-dateiserver" erreichen, der DNS-Server liefert keine brauchbare Antwort, der Client sendet daraufhin eine lokale Namensanfrage, ein fremdes System beantwortet diese mit seiner eigenen Adresse, der Client verbindet sich mit diesem System, und das verwendete Protokoll bestimmt den weiteren Verlauf.

Bei SMB, HTTP oder LDAP kann Windows unter bestimmten Bedingungen automatisch eine NTLM-Authentifizierung beginnen. Ein Angreifer könnte dann versuchen, diesen Vorgang an einen anderen Dienst weiterzureichen. Ob dieser sogenannte Relay-Angriff gelingt, hängt unter anderem von SMB- oder LDAP-Signierung, Channel Binding, der NTLM-Konfiguration und den Rechten Ihres Benutzerkontos ab.

Pretender als Beobachtungswerkzeug

Das Tool Pretender [1] von RedTeam Pentesting kann solche lokalen Namensanfragen beantworten und außerdem aktiv DNS-Konfigurationen über DHCPv6 beeinflussen. Nachfolgende SMB-, HTTP- oder LDAP-Anfragen nimmt das Werkzeug allerdings nicht selbst entgegen – dafür braucht es einen weiteren Dienst, der die eigentliche Verbindung annimmt. Da SMB für einen ersten Test zusätzliche Werkzeuge wie Impackets ntlmrelayx.py voraussetzt, demonstrieren wir den Mechanismus stattdessen mit einem einfachen HTTP-Webserver, den wir später aufsetzen.

Pretender besitzt einen Dry-Run-Modus, indem es Anfragen zunächst nur protokolliert. Für eine rein passive Beobachtung genügt das Argument "--dry" allein jedoch nicht. Zusätzlich setzen Sie "--no-ra", damit das Werkzeug keine IPv6-Router-Advertisements versendet.

Es erklärt sich von selbst, dass solche Versuche zunächst in ein isoliertes virtuelles Netzwerk gehören, vor allem, wenn Sie aktiv in das Netzwerk eingreifen möchten. Dafür bereiten Sie etwa eine Linux-VM für Pretender und eine Windows-11-VM als Client vor und verbinden beide über einen internen virtuellen Switch. Bestenfalls besteht dabei gar keine Verbindung zum Unternehmens- oder Heimnetz. In unserem Beispiel geben wir dem Linux-System die Adresse 192.0.2.10, Windows verwendet 192.0.2.20. Das Netz 192.0.2.0/24 ist für Dokumentationszwecke reserviert; in Ihrem Labor können Sie beliebige interne Adressen verwenden.

Installation und Beobachtung

Sie können Pretender direkt als veröffentlichtes Binary herunterladen oder mit Go installieren. Dafür starten Sie die folgenden Kommandos:

Wenn Sie später reproduzierbare Tests benötigen, dokumentieren Sie statt "latest" einen festen Versionsstand. Für unseren Test hier ist das nicht zwingend notwendig. Den Namen der Laborschnittstelle, etwa "eth0", "ens18" oder "enp0s8", entnehmen Sie der Ausgabe des Kommandos und merken sich die relevante Schnittstelle zum Mitlesen. In einem Terminal starten Sie nun als Root-Benutzer Pretender im passiven Modus mit dem Kommando

Pretender lauscht nun zehn Minuten lang auf dem angegebenen Interface, protokolliert aber nur ins Terminal. Hier sehen Sie bereits erste Einträge mit dem Hinweis, dass Pretender die Anfrage aufgrund des Dry-Run-Modus ignoriert. In Ihrer Windows-VM leeren Sie nun mit einer als Administrator gestarteten PowerShell den DNS-Cache und rufen einen nicht vorhandenen Namen auf:

Der Aufruf wird natürlich scheitern. Bleibt die Pretender-Ausgabe trotzdem leer, kann LLMNR bereits deaktiviert oder NetBIOS nicht gebunden sein, oder eine Firewall blockiert den Verkehr. Auch das wäre für Sie ja ein verwertbares Ergebnis.

Fake-Antwort im Labor

Nun starten wir in der Linux-VM einen harmlosen HTTP-Dienst. Das erledigen Sie recht schnell und ohne Aufwand mit dem in Python integrierten Server. Erstellen Sie eine index.html und starten den Server mit den Kommandos

Pretender begrenzen wir für den nächsten Start – Achtung, dieser läuft jetzt nicht mehr im Dry-Run – auf unseren Testnamen und den vorgesehenen Client:

Das Argument "--no-dhcp-dns" verhindert den DHCPv6-DNS-Angriff. "--spoof" begrenzt die Antwort auf den angegebenen Namen, "--spoof-for" auf den Testclient. Mit "--no-ipv6-lnr" bleibt der Versuch auf den vorgesehenen IPv4-Ablauf beschränkt. Nach dem Start sollte das Tool auf eingehende Pakete warten.

Auf Windows wiederholen Sie nun die Kommandos von oben. Pretender protokolliert nun die Anfrage und seine Antwort. Der Webserver sieht anschließend die Verbindung des Windows-Clients, und auf dessen Konsole erscheint der vorbereitete Text des Webservers. Beachten Sie, dass dieser Testaufbau nur die Namensauflösung und Umleitung nachstellt: Der curl-Aufruf überträgt keine Zugangsdaten, sodass hier noch kein vollständiger NTLM-Relay-Angriff stattfindet. Für dessen praktische Demonstration wäre zusätzlich ein Relaying-Werkzeug wie Impackets ntlmrelayx.py nötig, das den Rahmen dieses Security-Tipps sprengt.

Absichern oder Ursachen bekämpfen

Der naheliegende erste Schutzschritt besteht darin, LLMNR zu deaktivieren, wenn Sie es nicht benötigen. In einer verwalteten Windows-Umgebung geschieht das etwa über die Richtlinie unter "Computerkonfiguration / Administrative Vorlagen / Netzwerk / DNS-Client / Multicastnamensauflösung deaktivieren" oder durch den Wert "0" im Registry-Key "HKEY_LOCAL_MACHINE\SOFTWARE \ Policies \ Microsoft \ Windows NT \ DNSClient". Wie immer beim Aktualisieren von Richtlinien wenden Sie diese zunächst auf eine kleine Testgruppe an. Anschließend wiederholen Sie den passiven Mitschnitt und prüfen, ob Anwendungen oder Verwaltungsprozesse darunter leiden.

NetBIOS over TCP/IP und mDNS sollten Sie tatsächlich getrennt bewerten. Vor allem mDNS kann legitime Geräte und Anwendungen unterstützen und ein pauschales Abschalten ohne Bestandsaufnahme verlagert das Problem dann leicht in den Betriebsalltag.

Eigentlich ist es noch wichtiger, die Ursache der Anfragen zu ergründen. Alte Laufwerkszuordnungen, Anmeldeskripte, Druckerverbindungen, geplante Aufgaben und Anwendungskonfigurationen gehören bereinigt. Solange Clients ständig nicht vorhandene Namen suchen, bleibt die Umgebung natürlich fehleranfällig, selbst wenn einzelne Protokolle an der Firewall blockiert sind. Überwachen Sie das Netzwerk auf entsprechende Aufrufe – so wie mit Pretender dokumentiert –, finden Sie schnell die relevanten Systeme in Ihrem Netzwerk.

Fazit

Pretender weist nach, dass ein Client falsche Antworten auf lokale Namensanfragen akzeptiert. Das Werkzeug beweist nicht automatisch, dass sich daraus eine vollständige Kompromittierung Ihrer Windows-Umgebung ergibt und ist nicht unbedingt für den Dauerbetrieb gedacht.

Fallback-Namensauflösung im lokalen Netzwerk