SecCore Essentials - Network Protocols

Zusammenfassung

Um die Netzwerkumgebung abzusichern und dieses SecCore Essential zu implementieren müssen folgende Einstellungen gesetzt werden:

• Link-Local Multicast Name Resolution (LLMNR) muss auf Microsoft Windows Systemen deaktiviert werden:
  • Turn off Multicast Name Resolution: Enabled.
• NetBIOS Name Service (NBNS) muss auf Microsoft Windows Systemen deaktiviert werden:
  • Dies kann mit dem folgenden PowerShell-Befehl, der beim Einloggen ausgeführt werden soll, bewerkstelligt werden: Get-WmiObject -Class Win32_NetworkAdapterConfiguration | % {$_.SetTcpipNetbios(2)}.
• Schutz gegen ARP-Spoofing muss auf den Netzwerkswitches aktiviert werden:
  • Cisco¹
  • HPE Aruba²
  • Fortinet³
  • Juniper⁴
  • Barracuda⁵
• Keine wichtigen Dienste verwenden unverschlüsselte Protokolle (telnet, ftp, http etc.).
• Schutz gegen IPv6 Spoofing ist konfiguriert:
  • Cisco⁶
  • HPE Aruba⁷
  • Fortinet⁸
  • Juniper⁹
  • Barracuda¹⁰

Einleitung

Die zuverlässige Kommunikation zwischen Diensten und Computern in einem Netzwerk basiert auf dem Zusammenspiel verschiedener Netzwerkprotokolle. In einem typischen Netzwerk werden dutzende Protokolle für Funktionen wie Namensauflösung, Dateitransfers, verschlüsselte Kommunikation oder Applikations- und Gerätesteuerung verwendet. Diese Protokolle ändern sich jedoch im Laufe der Zeit und Designprobleme werden oft erst Jahre nach ihrer Entwicklung und Standardisierung sichtbar. Dies führt dazu, dass einige noch verwendete Protokolle heutzutage nicht mehr gängigen Security-Standards entsprechen und als unsicher eingestuft werden. Telnet zum Beispiel, das seit langem ein wichtiges Fernwartungsprotokoll für Geräte ist, funktioniert rein über unverschlüsselte Kanäle. Das macht es aufgrund möglicher Man-in-the-Middle-Angriffe zu einer schlechten Wahl für Verwaltungsschnittstellen. Einige andere Protokolle wie beispielsweise SMTP oder SMB wurden so weiterentwickelt, dass sie starke Verschlüsselungsmethoden unterstützen und umsetzen.

Häufige Angriffsvektoren

Die folgenden Abschnitte beschreiben häufige Angriffsvektoren auf verschiedene Netzwerkprotokolle.

Broadcast Name Resolution

Bevor die meisten Netzwerke Namensauflösung mittels zentraler Domain-Name-System (DNS) Server umsetzten, benötigten diese eine einfache Methode, um Hostnamen in Internet Protocol (IP)-Adressen aufzulösen. Ohne einen zentralen Nameserver erfolgte dies in der Regel über Broadcast-Protokolle wie Link-Local Multicast Name Resolution oder NetBIOS Name Service in Microsoft Windows. Ein Client konnte einfach einen Request an die Broadcast-Adresse des jeweiligen Netzwerks senden und jeder andere Computer im Netzwerk konnte darauf beliebig antworten. Somit war die Namensauflösung abgeschlossen.

Der gesamte Prozess wird in keiner Weise authentifiziert oder überprüft, was zur Folge hat, dass beliebige Antworten von beliebigen Systemen gesendet werden können.

Dies kann ausgenutzt werden, um beliebige Hostnamen zu fälschen, indem einfach alle eingehenden Broadcast-Anfragen mit Tools wie Responder¹¹ beantwortet werden.

Sowohl LLMNR als auch NBNS sind nicht mehr die Standardprotokolle für Namensauflösung in modernen Microsoft Windows-Installationen. Ein DNS-Server wird immer bevorzugt, aber wenn ein Hostname vom DNS-Server nicht aufgelöst werden kann, werden weiterhin Broadcast-Pakete als Fallback-Mechanismus gesendet.

Das Spoofen von LLMNR- und NBNS-Paketen ist ein einfacher, passiver Angriff, bei dem man nur auf Broadcast-Pakete warten muss. Sollte dies erfolgreich sein, können diese Spoofing-Angriffe beispielsweise für SMB Relaying oder LDAP Relaying verwendet werden.

ARP Spoofing

Das Address Resolution Protocol (ARP) wird in IPv4-Netzwerken verwendet, um eine IP-Adresse einer MAC-Adresse zuzuordnen. Die Ethernet-Kommunikation in internen Netzwerken funktioniert über MAC-Adressen, sodass alle Geräte eine Möglichkeit benötigen, eine IP-Adresse in eine MAC-Adresse zu übersetzen, um Pakete an das richtige Ziel zu senden. ARP funktioniert ebenfalls über Broadcasting und ist daher nicht authentifiziert oder einfach überprüfbar.

Diese ARP-Antworten werden in der ARP-Tabelle auf jedem Gerät gespeichert, damit nicht jedesmal ARP-Anfragen gesendet werden müssen, wenn eine IP-Adresse in eine MAC-Adresse übersetzt werden muss.

Zusätzlich ist es möglich, ARP-Antworten ohne vorherige ARP-Anfrage an ein Zielsystem zu senden. Dies ist eigentlich dafür gedacht, dass Geräte Änderungen an ihrer eigenen IP-Adresse direkt an alle anderen Geräte weitergeben können.

Bei diesem Angriff wird sämtlicher Datenverkehr von einem Client zum Server und umgekehrt über ein angreifendes System geleitet. Diesen Vorgang nennt man auch Man-in-the-Middle (MitM) Angriff. Er ist besonders gefährlich, wenn zur Kommunikation unverschlüsselte Protokolle verwendet werden.

Unverschlüsselte Protokolle

In einer MitM Position kann jeder unverschlüsselte Datenverkehr einfach mitgeschnitten und ausgelesen werden. Nach einem erfolgreichen ARP-Spoofing Angriff werden häufig Tools wie Wireshark¹² verwendet, um die Daten zu dekodieren. Sensible Daten wie Dateien oder Passwörter können extrahiert werden, wenn unverschlüsselte Protokolle wie Telnet, HTTP oder FTP verwendet werden.

Wird eine starke Verschlüsslung wie TLS verwendet, kann selbst in einer MitM-Position kein Datenverkehr mitgelesen werden.

IPv6

IPv6 ist der Nachfolger des bekannten IPv4 Internet Protokolls und bietet einen viel größeren Raum zur Vergabe von Adressen. Auch wenn es bereits 2017 standardisiert wurde, verwenden vor allem interne Netzwerke eher selten IPv6. Dies wird jedoch deshalb zum Problem, da Microsoft Windows Systeme seit Windows Vista nicht nur IPv6 unterstützen, sondern dieses auch gegenüber IPv4 bevorzugen. Dieses Verhalten kann in einem Angriff ausgenutzt werden, indem ein gefälschter IPv6 DHCP- und DNS-Server im selben Netzwerk erstellt wird. Das Zielsystem erhält somit die Netzwerk- und DNS-Konfiguration vom gefälschten DHCPv6 Server und präferiert nun den gesetzten IPv6-DNS-Server. Das führt dazu, dass sämtliche DNS-Abfragen nun von einem bösartigen DNS-Server beantwortet werden und diese somit umgeleitet werden können, um eine MitM Position zu erhalten.

Angriffsszenario

In diesem Abschnitt wird gezeigt, wie IPv6-Spoofing verwendet werden kann, um in das interne Netzwerk einzudringen und Informationen zu sammeln. Das Szenario für diesen Angriff sieht wie folgt aus:

• Es wurde Zugriff zum internen Netzwerk erlangt, jedoch ohne gültige Zugangsdaten
• Es wurde keine Rücksicht auf OPSEC genommen, der direkteste Ansatz wurde gewählt

Nachdem bereits Zugriff zum internen Netzwerk besteht, kann mit Tools wie Responder¹¹ auf eingehende Verbindungen gewartet werden. Sobald ein Computer sich aus welchem Grund auch immer zu diesem System verbindet, kann eine Anmeldung abgefangen und der dazugehörige NTLMv2-Hash offline geknackt werden. Um diesen Prozess zu beschleunigen kann mit dem Tool mitm6¹³ ein gefälschter DHCPv6- sowie DNS-Server erstellt werden. Mit dem folgenden Befehl wird ein DHCPv6-Server erstellt, der das bösartige System als DNS-Server für alle Clients im Netzwerk einträgt. Wie im Screenshot ersichtlich, hat sich kurz darauf ein Client zum DHCP-Server verbunden, sich eine IPv6-Adresse abgeholt und den DNS-Server gesetzt. Während Responder verwendet wird, um auf eingehende Verbindungen zu warten, werden mit dem Tool ntlmrelayx¹⁴ diese Verbindungen an den Domain-Controller dc1.lab.local weitergeleitet:

ntlmrelayx.py -t dc1.lab.local -smb2support -addcomputer

Mehr Informationen zu NTLM-Relaying können in unseren SMB Signing und LDAP Signing Essentials nachgelesen werden.

Dieser Befehl fügt einen neuen Computer zur Domäne hinzu, welcher einen zufälligen Namen und Passwort besitzt. Dies ist im folgenden Screenshot ersichtlich: Dieses Computerkonto kann zur Authentifizierung am Domain-Controller und zum Extrahieren sensibler Informationen wie Benutzerdaten verwendet werden: Das Angriffsszenario ist in folgender Abbildung zusammengefasst:

Gegenmaßnahmen

Wenn die in diesem Eintrag beschriebenen Sicherheitsmaßnahmen zum Thema IPv6 implementiert wurden, ist dieses Angriffsszenario nicht mehr möglich. Es kann zwar versucht werden einen DHCPv6-Server aufzusetzen, aber da Maßnahmen gegen IPv6-Spoofing ergriffen wurden, wird dieser von keinem Client-System akzeptiert: