Um den IPv6 MITM Angriff zu erklären gehen wir zunächst auf die Grundlagen ein.
Im heutigen Beitrag wollen wir erklären, warum Man in the Middle Angriffe über IPv6 einfach zum Erfolg führen können, wie man diese durchführt und was man tun kann, um sich davor zu schützen. Um die möglichen Angriffsszenarien zu verstehen, gehen wir noch einmal kurz auf die Grundlagen ein.
IPv6 ist eine neuere Version des allgemein als Internet Protocol bekannten IPv4. Das Internet Protocol ist eines der grundlegenden Protokolle für die Vermittlung von Datenpaketen über das Internet sowie lokale Netzwerke. Es wird immer dann benötigt, wenn Daten zwischen Netzwerken und Systemen übertragen werden sollen. IPv6 wurde konzipiert, weil die zur Verfügung stehenden IP-Adressen im Protokoll IPv4 nicht mehr ausreichen für die immer größer werdende Anzahl von vernetzten Geräten. IPv6 hat einen um einen vielfachen größeren Adressbereich (IPv4: 32 Bit, IPv6 128 Bit), sodass ein erneutes Ausgehen verfügbarer Adressen auch in der Zukunft sehr unwahrscheinlich ist.
Interessant ist hierbei noch zu erwähnen, weil IPv6 das neuere Protokoll ist, wird es in der Regel priorisiert.
Eine weitere wichtige Eigenschaft von IPv6 ist, dass es ohne administrativen Aufwand verwaltet werden kann. Hierbei ist die Rede von der zustandslosen automatischen Konfiguration (SLAAC) die es Systemen erlaubt, ohne Konfiguration, d.h. ohne händische Vergabe von IP-Adressen oder Einrichtung von DHCP, in IPv6 Netzen teilzunehmen. Diese Autokonfiguration ist eine der Grundlagen für den Angriff. Die gesamte Kommunikation für SLAAC läuft über das Neighbour Discovery Protocol (NDP) und ICMPv6. Da Systeme automatisch auf Anfragen und Informationen eines IPv6-Router-Systems reagieren, können Änderungen an der Konfiguration der Systeme vorgenommen werden, die Angriffe möglich machen.
Um den Angriff durchzuführen, sendet der Angreifer Router Advertisements ins Netzwerk, um anderen Systemen mitzuteilen, dass es als IPv6-Router fungiert und zur Verfügung steht. Ebenso fungiert es als nicht autorisierter DHCPv6-Server im Netzwerk. Hierbei verwendet er die Flag „managed“, um den Systemen mitzuteilen, dass eine weitere Konfiguration des IPv6 Interfaces über einen DHCPv6-Server erfolgt
Das Fox-IT Security Research Team hat Snort- und Suricata-Signaturen veröffentlicht, um betrügerischen DHCPv6-Datenverkehr und WPAD-Antworten über IPv6 zu erkennen:
alert udp fe80::/12 [546,547] -> fe80::/12 [546,547] (msg:"FOX-SRT - Policy - DHCPv6 advertise"; content:"|02|"; offset:48; depth:1; reference:url,blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/; threshold:type limit, track by_src, count 1, seconds 3600; classtype:policy-violation; sid:21002327; rev:2;)
alert udp ::/0 53 -> any any (msg:"FOX-SRT - Suspicious - WPAD DNS reponse over IPv6"; byte_test:1,&,0x7F,2; byte_test:2,>,0,6; content:"|00 04|wpad"; nocase; fast_pattern; threshold: type limit, track by_src, count 1, seconds 1800; reference:url,blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/; classtype:attempted-admin; priority:1; sid:21002330; rev:1;)
Nach Durchführung der oben genannten Möglichkeiten, den Angriff zu verhindern, kann es sein, dass Sie leider feststellen müssen, dass es Angreifer in Ihrem Netz gibt.
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
PSN-ID: PS-TN-2020-0053
In der Folge wird der Client eine IPv6-Konfiguration im Netzwerk anfragen. Hierauf kann der Angreifer ebenfalls antworten und sich als DHCPv6-Server ausgeben und dadurch Konfigurationsänderungen am Client durchführen.
Der Angreifer fungiert nun als DNS-Server für das Opfer und kann dadurch DNS-Spoofing betreiben. In der Realität wird dies verwendet, um Anfragen an die lokale Domäne zu spoofen. Wenn also Opfer nach Ressourcen wie z.B. einer WPAD per DNS-Anfrage suchen, liefert der Angreifer eine falsche Ablage-Adresse (erneut die eigene IP) an das Opfer. Hierüber wird dann eine falsche WPAD an das Opfer ausgeliefert, und dadurch kann in den Browsern eines Opfers ein Proxy konfiguriert werden, über den im weiteren Schritt eine NTLM-Authentifizierung forciert werden kann. Dies geschieht, in dem der Angreifer auf Anfragen, die über den neu eingetragenen falschen Proxy eingehen, mit dem http-Status-Code HTTP 407 Proxy Authentication required antwortet. Diese unterscheidet sich von dem üblicherweise verwendeten Code 401. Alle gängigen Browser werden sich daraufhin gegenüber dem Proxy automatisch ohne Zutun des Nutzers per NTLM authentifizieren, sofern NTLM genutzt wird und die Browser nicht explizit gegen dieses Verhalten gehärtet werden. Die NTLM-Authentifizierung kann nun für Relay-Angriffe oder andere Angriffstechniken verwendet werden. Der Angriff war bis hier hin erfolgreich und IPv6 wurde erfolgreich ausgenutzt.
Alle Netzwerkteilnehmer, die im selben Netzwerk wie der Angreifer kommunizieren. Windows-Clients, Windows-Server, Switches.
An Windows-Systemen kann IPv6 per Registry Änderung deaktiviert werden. Hierbei muss jedoch geprüft werden, ob das Protokoll ggf. notwendig ist.
Als alternative oder zusätzliche Lösung kann der Angriff durch Konfiguration der Switche unterbunden werden. Hierfür muss jeder Switch die Optionen IPv6 RA Guard und IPv6 DHCP Guard zu aktivieren.
Zur Prüfung kann das Tool mitm6 verwendet werden. ACHTUNG! Da das Tool die Netzwerk-Konfigurationen des Opfers verändert, kann es während und nach dem Angriff zu Beeinträchtigungen an Systemen kommen. Dies kann dazu führen, dass Netzwerkressourcen nicht mehr erreichbar sind. Die wahrscheinlichste Ursache hierfür ist, dass DNS-Anfragen von Opfer-Systemen ins Leere laufen, weil kein valider DNS-Server erreichbar ist. Es ist dringend empfohlen, die Option -d mit der lokalen Domäne des Active Directories zu verwenden. Mitm6 wird dann nur Anfragen nach Ressourcen innerhalb dieser Domäne spoofen.
Befehl:
mitm6 -I INTERFACE -d DOMAIN --ignore-nofqdn
Zur Durchführung muss ein Interface (i.d.R eth0) und die AD-Domäne angegeben werden
Hinweis:
Der Angriff kann auch ohne Angabe der Domäne ausgeführt werden, wodurch jedoch kein Scope für den Angriff gegeben ist. Daraus folgt, dass jegliche Anfrage manipuliert wird, auch z.B. eine Google Suche. Diese Variante kann jedoch ein hohes Maß an Datenverkehr bedeuten, welcher über die Maschine des Angreifers läuft, weshalb die Offensichtlichkeit des Angriffs deutlich erhöht wird. Zudem werden Einschränkungen im Netzwerk für die weiteren Netzwerkteilnehmer spürbar werden, weil die Namensauflösung über DNS nicht mehr funktioniert.
Befehl:
mitm6 -I INTERFACE
Zur Behebung der Findings bieten sich zwei Solutions an. Die favorisierte Solution ist die Deaktivierung von IPv6 an allen Systemen, die dieses nicht benötigen. Sofern in einem Netzwerk IPv6 noch nicht bewusst verwendet wird, spricht viel dafür, dass eine Deaktivierung möglich ist. Einzig neuere Exchange-Server benötigen IPv6 zur Kommunikation untereinander. IPv6 kann effektiv über eine Änderung der Registry per GPO an Windows-Systemen deaktiviert werden. Wenn eine Deaktivierung des Protokolls nicht möglich ist, oder zusätzliche Sicherheitsmaßnahmen getroffen werden sollen, dann ist die Nutzung von zwei Optionen an Switchen möglich. Hierzu müssen die Switche die beiden Funktionen IPv6 RA Guard und IPv6 DHCP Guard besitzen.
Zur Deaktivierung von IPv6 an Windows-Systemen gibt es zwei Möglichkeiten. Aktuell empfehlen wir das Ausrollen einer Registry Änderung per GPO. Hierfür kann eine GPO erstellt werden, in der die nachfolgenden Ergänzungen der Registry durch eine Aktualisierung vorgenommen wird.
Der Angriff mit mitm6 kann zudem am Switch deaktiviert werden. Hierzu muss zunächst die Option RA Guard aktiviert werden.
Konfigurationsbeispiel:
1: SW1(config)#ipv6 nd raguard policy HOSTS
2: SW1(config-nd-raguard)#device-role host
In Zeile 1 wird eine neue Policy für die Funktion „ipv6 nd raguard“ mit dem Namen HOSTS definiert. Der Name ist frei wählbar, sollte aber eindeutig der Rolle von Systemen zugeordnet werden können. Wenn der Switch über diese Funktion nicht verfügt, kann die Solution nicht implementiert werden. In Zeile 2 wird allen Systemen, auf die die Policy angewendet werden, mit dem Befehl device-role die Rolle host zugewiesen. Die device-role host bedeutet, dass das System ein Client ist und nicht als Router fungiert.
3: SW1(config)#interface GigabitEthernet 0/2
4: SW1(config-if)#ipv6 nd raguard attach-policy HOSTS
Im nächsten Schritt wird in Zeile 3 das oder die zu konfigurierenden Interfaces des Switches ausgewählt. Da wir keinerlei IPv6 Router im Netzwerk zulassen wollen, kann die Policy auf alle Interfaces an allen Switchen ausgerollt werden. In Zeile 4 ist der Befehl, um die zuvor definierte Policy mit dem ausgewählten Interface oder der Interface-Range zu verbinden.
5: SW1#show ipv6 nd raguard policy HOSTS
Zeile 5 zeigt den Befehl, um zu überprüfen, ob die Policy mit den Interfaces verknüpft ist. Wenn die Konfiguration erfolgreich war, zählt dieser Befehl sämtliche Interfaces auf, an denen die Policy verknüpft ist.
Neben der Option für RA Guard muss auch die Funktionalität von DHCPv6 eingeschränkt werden. Die hier vorgenommenen Einstellungen haben dabei keine Auswirkungen auf vorhandenen Infrastrukturen für DHCP im Kontext von IPv4 Adressen.
1: SW1(config)#ipv6 dhcp guard policy DHCP_CLIENT
2: SW1(config-dhcp-guard)#device-role client
In Zeile 1 wird eine neue Policy für die dhcp guard-Funktion erstellt. In diesem Fall wird diese als DHCP_CLIENT benannt. Der Name ist frei wählbar, sollte aber eindeutig sein. In Zeile 2 werden Systeme, auf die diese Policy angewendet wird, mit der device-role client versehen, das bedeutet, dass es sich bei allen Systemen, bei denen die Policy angewendet wird, um DHCP-Clients handelt. Dies hat zur Folge, dass Funktionen eines DHCPv6-Servers bzw. Netzwerk-Pakete, die von einem solchen System ausgesendet werden, durch den Switch verworfen werden, wenn diese Policy angewendet wird.
3: SW1(config)#interface range GigabitEthernet 0/2 - 3
4: SW1(config-if-range)#ipv6 dhcp guard attach-policy DHCP_CLIENT
In Zeile 3 werden Interfaces ausgewählt. Analog wie beim RA Guard können hier sämtliche Interfaces ausgewählt werden, weil es keinen legitimen DHCPv6 Server im Netzwerk gibt. Mit dem Befehl aus Zeile 4 wird die erstellte Policy DHCP_Client mit den ausgewählten Interfaces verknüpft.
5: SW1#show ipv6 dhcp guard policy
Zeile 5 zeigt den Befehl zur Überprüfung, ob die erstellte Policy angewendet wird. Wenn die Konfiguration funktioniert hat, werden sämtliche Interfaces am Switch hier angezeigt.
