In einem unserer letzten Beiträge haben wir aufgezeigt, wie wir mit LLMNR (Link-local Multicast Name Resolution) Poisoning durch einen Man-In-The-Middle-Angriff Informationen und Passwort-Hashes erlangt haben. In diesem Beitrag möchten wir uns um das „Vorgängerprotokoll“ NBT-NS (Netbios-Nameservice) kümmern, mit dem wir ebenfalls die Pakete „vergiften“ können.
NetBios over TCP/IP oder NBT-NS ist ein altes Protokoll zur Namensauflösung, sollten die DNS-Server im Netzwerk keine passenden Namen liefern können. Der Host nutzt dieses Protokoll als Broadcast, um selbst nach dem passenden Dienst zu suchen.
Netbios wird in Windows-Versionen bis zu Windows ME verwendet, um höhere Netzwerkfunktionen (Server Message Block (SMB)) zu realisieren. Neuere Windows Versionen ab Windows 2000 wickeln die SMB-Kommunikation direkt über TCP-Port 445 ab.
Standardmäßig ist die NetBIOS-over-TCP/IP-Unterstützung für alle Schnittstellen in allen Windows-Versionen aktiviert.
Das Protokoll befindet sich auf folgenden Ports:
UDP 137: Namensauflösung
UDP 138: Datagram Service
TCP 139: Session Service
Die Arbeitsweise das Protokolls kann über fünf Nodes eingestellt werden.
Standardmäßig nutzt NBT-NS den H-Node (hybrid) für die Namensauflösung und Namensregistrierung. Diese ist eine Kombination aus Broadcastanfragen (B-Node) und Peer-to-Peer-Anfragen (P-Node).
Ähnlich, wie bei einem LLMNR-Poisoning Angriff wird ohne passende Antwort des DNS-Servers NTB-NS verwendet.
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. Diese IP 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 eine Authentifizierung. Diese kann über Basic-Auth oder Challenge-Response (wie z.B. Net-NTLMv2) stattfinden. Nach der Authentifizierung bekommt der Client eine Fehlermeldung, sodass es aussieht, als wurde die Ressource doch nicht gefunden. In den meisten Fällen findet die Authentifizierung ohne User-Interaction statt.
Zur technischen Umsetzung des soeben erklärten NBT-NS Poisoning Angriffs kann das Tool Responder verwendet werden.
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 NBT-NS Angriffe zu verhindern, bzw. NBT-NS Nutzung zu deaktivieren, gibt es verschiedene Möglichkeiten. Von der Einstellung über DHCP bis hin zur Deaktivierung über GPO.
In den DHCP Serveroptionen kann für alle Schnittstellen eine erweiterete Option mitgegeben werden: 001 Microsoft NetBIOS-Deaktivierungsoption – 0x2
Erhält ein System einen DHCP-Lease wird NetBIOS automatisch auf allen Schnittstellen deaktiviert.
Ebenfalls kann der Node Type via Registierung und GPO mitgegeben werden. Durch diese Änderung wird der NodeType auf P (Peer-to-Peer) geändert. Es erfolgt also keine Namensauflösung über NBT-NS.
Unter den Netzwerkoptionen, Auswählen TCP/IPv4, Erweitert, WINS – kann die Option „Netbios über TCP/IP deaktivieren“ ausgewählt werden.
Diese Anpassung kann auch mittels Powershell-Script über eine GPO in der Domäne ausgerollt werden.
Nach dem Sie NBT-NS in Ihrem Netzwerk deaktiviert haben lohnt es sich den Traffic im Netzwerk zu analysieren. In diesem Zuge sehen Sie ebenfalls, ob es Probleme bei der Umsetzung der Härtungsmaßnahmen 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.
Suchen Sie nach Broadcast NBT-NS Traffic oder konfigurieren Sie eine IDS-Regel (hier beispielhaft für Snort).
alert udp any 137 -> any 137 (msg:"NetBIOS NBT\-NS Query Broadcast"; content:"|01 10|"; depth: 46; reference:url,prosec-networks.com/blog/netbios-tcp; classtype:non-standard-protocol; sid:1000001; rev:001;)
Um einen Angreifer im Netzwerk zu erkennen bieten sich Tools an welche gezielt NBT-NS Anfragen für nicht existente Ressourcen ins Netzwerk senden. Bekommt man nun Anworten auf diese Anfragen befindet sich ein Angreifer im Netzwerk der auf NBT-NS Anfragen wartet.
Zur aktiven Erkennung eines Angreifers im Netzwerk können hierzu Tools wie Conveigh oder HoneyCreds verwendet werden. Hier am Beispiel von Respounder:
Nach Durchführung der oben genannten Härtungsmaßnahmen und Installation eines 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.
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-0006
