NAT Slipstreaming oder: wie das Schmuggeln von Datenpaketen zu offenen Ports führen kann

Mit der JavaScript basierten Attacke „NAT Slipstreaming“ können Dienste in lokalen Netzwerken von Angreifern aus dem Internet heraus verwendet werden. Im Folgenden wird dargestellt, wie der Angriff funktioniert und welche Technologien dabei benutzt werden.

Der amerikanische Datenschutz- und Sicherheitsforscher, Hardwarespezialist und Hacker Samy Kamkar ist zunächst bekannt geworden, als er den MySpace Wurm „samy“ in 2005 erstellte. Samy hat seitdem viele weitere interessante Projekte wie SkyJack, MagSpoof oder Evercookie veröffentlicht und ist regelmäßig Redner auf Konferenzen wie BlackHat, DEF CON oder bei OWASP Meetups. Bereits 2010 veröffentliche Samy auf seinem privaten Blog eine Anleitung, wie eine Netzwerkadressübersetzung ausgenutzt werden kann, um lokale Ports aus dem Internet zu nutzen. Elf Jahre später veröffentlicht Samy zusammen mit Forschen der IoT-Sicherheitsfirma Armis eine weitere Methode, die verschiedene Web-Schnittstellen ausnutzt, um LAN-Ports aus dem WAN zu erreichen.

Hintergrund

Netzwerkadressübersetzung oder im Englischen „Network Address Translation (NAT)“ ist eine Technologie, die mit der RFC 2663 im August 1999 eingeführt worden ist. Da die Menge der unterschiedlichen IPv4-Adressen mit vier Milliarden relativ begrenzt ist und um die Jahrtausendwende immer mehr Geräte mit dem Internet verbunden wurden, brauchte es eine technische Lösung, um die Anzahl der verfügbaren IP-Adressen zu regulieren.

Gateways wie Router oder Firewalls benutzen deshalb unter anderem NAT, um die gleichzeitige Verwendung einer öffentlichen IP-Adresse durch mehrere interne Hosts zu ermöglichen. In Abbildung-1 wird dargestellt, wie private Adressen durch NAT geändert werden und wie externer WAN-Traffic mithilfe von NAT-Tabellen wieder zu einem internen Host im LAN gelangt.

Abbildung-1: Kommunikation zwischen LAN und WAN durch NAT

Wie bereits erwähnt, kann NAT helfen, die Verknappung der IPv4-Adressen zu verlangsamen, da sich mehrere private Geräte eine öffentliche IP-Adresse teilen können. Dank des quasi unendlichen IPv6 128-Bit Adressraums mit  3,4*10^38 unterschiedlichen IP-Adressen könnten in Zukunft alle Geräte eine eigene IP-Adresse erhalten, was das klassische NAT obsolet machen würde. Adressübersetzung bietet jedoch einen weiteren Vorteil: IP-Adressen eines Netzes werden vor einem anderen externen Netz verborgen. Durch das Maskieren von Quell IP-Adressen können interne Rechner nicht von außen direkt angesprochen werden. Dieser Nebeneffekt steigert daher die Sicherheit in privaten Netzen, doch generell sollten NAT-Lösungen allein nicht zur Trennung von Netzen verwendet werden.

Hosts hinter NAT-fähigen Routern haben keine Ende-zu-Ende-Konnektivität[1] und können deshalb (in der Theorie) an einigen Diensten nicht teilnehmen. Dienste, die die Initiierung von TCP-Verbindungen aus dem externen Netzwerk erfordern, oder zustandslose Protokolle, die UDP verwenden, können durch NAT gestört werden. Die Verwendung von NAT erschwert zudem auch Tunneling-Protokolle wie IPsec, weil NAT Werte in den Headern verändert, die die Integritätsprüfungen von IPsec und anderen Tunneling-Protokollen stören. Da interne Adressen alle hinter einer öffentlich zugänglichen Adresse versteckt sind, ist es für externe Hosts unmöglich, eine Verbindung zu einem bestimmten internen Host zu initiieren, ohne dass eine spezielle Konfiguration auf dem Gateway zur Weiterleitung von Verbindungen zu einem bestimmten Port hinterlegt ist. Netzwerkprotokolle, die Out-of-Band-Signalisierung und Rückkanäle einsetzen, wie etwa IP-Telefonie-Protokolle (VoIP), Videokonferenzen und andere Peer-to-Peer-Anwendungen müssen ebenfalls NAT-Traversal Techniken verwenden, um generell zu funktionieren.

NAT-Traversal oder NAT Hole-Punching ist ein allgemeiner Begriff für Techniken, die TCP/IP-Netzwerk- bzw. TCP-Verbindungen aufbauen und aufrechterhalten und so NAT-Gateways durchqueren können. Dies ist bei einigen Anwendungsprotokollen wie erwähnt per Protokolldesign nötig. Viele Peer-to-Peer Anwendungen erfordern zwei Verbindungen, um zu funktionieren. Die erste Verbindung kommt aus dem internen Netzwerk, geht ins Internet und wird daher standardmäßig vom NAT zugelassen. Eine zweite Verbindung geht in die entgegengesetzte Richtung: vom Internet ins interne Netzwerk. Da die zweite Verbindung normalerweise vom NAT blockiert würde, analysiert das NAT den Datenverkehr der ersten Verbindung und versucht zu erkennen, wann eine zweite Verbindung erforderlich sein könnte.

Eine Möglichkeit NAT-Traversal zu realisieren, ist es, ein Application-Level-Gateway (ALG) einzusetzen. Das ALG ist ein protokollspezifisches Stück Software, welches den Payload eintreffender Pakete auf gewisse Informationen durchsucht und sie durch Werte aus der NAT-Tabelle ersetzt bzw. Ports auf dem Router für die Anwendung öffnet. Legitime Anwendungsdaten können so die Sicherheitsprüfungen des Routers bzw. des NAT passieren, die sonst den Verkehr eingeschränkt hätten, weil er ihren begrenzten Filterkriterien nicht entspricht. Neben ALGs können auch Traversal Using Relays around NAT (TURN), Session Traversal Utilities for NAT (STUN) oder Interactive Connectivity Establishment (ICE) benutzt werden um ähnliches zu erreichen und Peer-to-Peer Verbindungen hinter NATs einzurichten.

[1] Adressübersetzung ändert Header Informationen in der IP-Schicht

NAT-Angriffe

Die ursprüngliche NAT-Traversal Attacke von 2010[1] nutzte eine Schwachstelle im Internet Relay Chat (IRC) Protokoll aus, um interne Ports aus dem WAN zu erreichen. Nachdem ein Opfer eine bösartige Website geöffnet hat, sendet der Browser des Clients ein Formular an einen vom Hacker kontrollierten IRC Server. Client und Server teilen eine HTTP-Verbindung, die auch genutzt wird, um eine Direct Client-to-Client (DCC) Nachricht an den Angreifer zu senden. Der Inhalt dieser Nachricht wird vom Router bzw. dem ALG, obwohl Teil einer HTTP-Nachricht als IRC-Telegramm ausgewertet und öffnet dem Angreifer beliebige Ports im LAN. Die DCC-Nachricht wird im HTTP-Payload nur durch einfache Zeilenumbrüche getrennt. Nach erfolgreicher Attacke besteht dann eine Route aus dem Internet zu einer internen Applikation wie FTP oder SSH. Neben IRC kann auch das FTP-Protokoll ausgenutzt werden, um denselben Effekt zu erzielen. Moderne Browser unterbinden diese Art von Verbindungsaufbau, indem sie eine Liste von beschränkten ausgehenden Ports konsultieren und gegebenenfalls die Verbindung blockieren. Der IRC Port 6667 wurde nach Samys Bekanntmachung mit in die Liste der restriktiven Ports aufgenommen.

NAT Slipstreaming

Samy Kamkar veröffentlichte dann am 31. Oktober 2020 eine weitere Methode, die NAT-Traversal missbraucht. Er taufte seine Technik „NAT Slipstreaming“ und war mit der ersten Version in der Lage, beliebige Ports eines bestimmten Hosts zu öffnen. Nach Veröffentlichung der Idee kollaborierte er mit Ben Seri und Gregory Vishnipolsky, und zusammen entwickelten sie die zweite Version des Exploits. Mit NAT Slipstreaming v2 ist es möglich, dass Angreifer aus der Ferne auf jeden TCP oder UDP-Dienst zuzugreifen können, der an einem beliebigen Host im NAT des Opfers gebunden war. Der Angreifer muss das Opfer nur auf eine von ihm kontrollierte Website locken bzw. muss das Opfer eine Website mit bösartiger Werbung besuchen.

NAT-Slipstreaming nutzt eine Reihe von Technologien aus, um sein Ziel zu erreichen. Allem voran zielt die Attacke auf den Browser des Opfers und verwendete Schwachstellen in ALG–Implementierungen von Gateway Geräten. Außerdem wird die Maximum Transport Unit (MTU) bzw. Maximum Segment Size (MSS) aus der Ferne vom Angreifer automatisch identifiziert und ermittelte Werte werden genutzt, um die IP-Fragmentierung seitens des Browsers zu verwirren und so beliebige Nachrichten in eine HTTP(S)-Verbindung zu schmuggeln. Letztlich werden interne IP-Adressen über Seitenkanäle der Verbindung bzw. durch WebRTC-Befehle ausgelesen, die bei der Attacke gebraucht werden, um die Routen in der NAT-Tabelle anzulegen.

Im Detail kann der Angriff wie folgt beschrieben werden: Er beginnt damit, dass ein Computer oder ein Mobiltelefon, auf dem ein Webbrowser läuft, eine vom Angreifer kontrollierte Website besucht. Dies führt dazu, dass im Browser des Opfers Javascript-Code ausgeführt wird, der zusätzlichen Datenverkehr an den Server des Angreifers sendet. Da dieser Datenverkehr vom Client ausgeht, werden entsprechende Regeln in die NAT-Tabelle des Routers oder der Firewall eingetragen. Der Verkehr der zweiten Phase ist dann so gestaltet, dass dem Browser vorgetäuscht wird, dass dieser Verkehr tatsächlich von einer normalen Anwendung stammt. In Wirklichkeit wird im Hintergrund die Attacke gegen das NAT ausgeführt. Der Verkehr das Ziel ein ALG zu missbrauchen und imitiert dafür bestimmte Protokolle (wie FTP, SIP, H.323, IRC oder Peer-to-Peer Protokolle), welche aufgrund des Protokolldesigns von einem ALG analysiert werden, um eingehende Verbindungen aus dem WAN, wie bereits beschrieben, im NAT gegebenenfalls einzutragen. Um die Attacke im Speziellen auszunutzen, fing Samy zunächst an, die Implementierung verschiedener ALGs in kommerziellen Routern zu studieren, mit dem Ziel, potentielle Schwachstellen zu identifizieren. Dazu lud er die neueste Version einer Router-Firmware vom Hersteller herunter und extrahierte die Implementierung mit binwalk und Ghidra.

Da das Opfer nur eine HTTP(S)-Verbindung zum Angreifer aufbaut und keine echten TCP- bzw. UDP-Sockets kreiert, muss eine weitere Schwachstelle ausgenutzt werden, um den ALG-Parser des Routers zu täuschen. Die Idee ist es, beliebige Anwendungsprotokolle über HTTP POST Pakete abzubilden. Dies wird erreicht, in dem die Fragmentierung von IP-Paketen so kontrolliert wird, dass der Payload eines weiteren textbasierten Protokolls wie bspw. SIP im HTTP-Body enthalten ist und am Anfang des zweiten Teilpaketes steht. Die große HTTP-Anfrage wird so segmentiert, dass der SIP-Payload dann genau an der Segmentierungsgrenze liegt, sodass ein ALG-Parser getäuscht wird, ihn zu verarbeiten, obwohl er eigentlich Teil einer HTTP-Nachricht ist. Wichtig ist, dass der Server auf dem Standard SIP-Port 5060 agiert, damit der ALG-Parser das IP-Packet überhaupt erst verarbeitet. Diese Technik erlaubt es, mit dem ALG zu kommunizieren, solange der Angreifer Pakete korrekt manipulieren kann.

[1] https://samy.pl/natpin/

Abbildung-2: HTTP-Paket mit SIP-Payload

Der rote SIP-Payload (Abbildung-2) wird in ein HTTP-Paket verpackt und genau an die Stelle platziert, an der der Browser das Paket fragmentieren muss (siehe MSS). Das Applikation Layer Gateway kontrolliert zunächst den grünen Teil-Payload und verwirft ihn aufgrund der unerwarteten Zeichenketten. Als Nächstes wird das zweite (rote) Paket mit SIP-Payload verarbeitet. Da nun kein HTTP-Header am Anfang des Payloads steht, sondern eine korrekte SIP-Nachricht, wird vom Opfer der lokale Port 8834 des Hosts 192.168.32.1 geöffnet.

Um die Segmentierungsgrenzen der Client-Pakete innerhalb der Verbindung zu ermitteln, wird der Client dazu gebracht, ein 6.000 Byte großes POST-Paket an den Server des Angreifers zu senden. Auf dem Angriffsserver werden die eingehenden Pakete gelesen und nach Mustern untersucht, die Segmentgrenzen andeuten. Der Angreifer kann so leicht die MTU-Größe (Maximum Transmission Unit), die IP-Header-Größe, potenzielle IP-Optionen, die TCP-Header-Größe, potenzielle TCP-Optionen und die Datenpaketgröße des Payloads bestimmen. Außerdem kann der Angreifer versuchen, die maximale Datengröße von TCP-Paketen zu kontrollieren, indem er während der anfänglichen SYN-Antwort eine Maximum Segment Size (MSS) TCP Option[1] setzt, welche die Größe der ausgehenden Pakete des Opfers manipuliert. Damit wird der Opferrechner angewiesen, TCP-Pakete auf eine bestimmte Größe zu beschränken. Der Angreifer kann die ermittelten Werte dem Opfer zurücksenden, damit der Client die korrekte Größe eines Padding bestimmen kann, so dass ein beliebiger Payload genau an der Grenze der Segmentierung liegt.

[1] RFC 793

Die letzte Information, die ein Angreifer ermitteln muss, um die Attacke erfolgreich durchzuführen, sind die IP-Adressen von internen Hosts, zu denen NAT-Einträge erstellt werden sollen. Diese Information wird durch die HTTP-Verbindung nicht preisgegeben, doch durch Ausnutzung des WebRTC-Standards können interne IP-Adressen doch ermittelt werden.

WebRTC wird normalerweise benutzt, um verschiedene Hosts zu verbinden, die eine direkte Kommunikation zwischen NATs aufbauen wollen. Der Angreifer kann Interactive Connectivity Establishment (ICE) Anfragen nutzen, um die interne IP des Hosts auszulesen[1]. Falls WebRTC nicht unterstützt wird[2], können auch HTML Image-Tags missbraucht werden, um IPs im NAT zu ermitteln. Der Client wird vom Server aufgefordert, Bilder per HTML zu laden, dabei werden die JavaScript Event Attribute „onSuccess“ bzw. „onError“ spezifiziert, mit deren Hilfe der Angreifer aufgrund der Verzögerung in Antwortzeiten valide IP-Adressen im LAN identifizieren kann. Die Adresse, die am schnellsten eine „onSuccess“ Antwort liefert, ist mit großer Wahrscheinlichkeit die lokale IP-Adresse des Opfers. Alle anderen identifizierten Adressen, die das „onSuccess“ Event auslösen, gehören zu weiteren Hosts im LAN.

Schafft es ein Angreifer korrekte private Adressen herauszufinden und gelingt es ihm, SIP-Pakete so zu kapseln, dass der Payload an einem neuen Segment anfängt, kann er das ALG ausnutzen, um Routen zu lokalen Diensten im NAT einzutragen. Sobald das SIP-Paket auf der Paketgrenze landet, wird das NAT getäuscht und glaubt, dass es sich um eine legitime SIP-Registrierung handelt und von einem SIP-Client auf dem Rechner des Opfers stammt. Sobald der Server mit einer ordnungsgemäßen SIP-Nachricht antwortet und auch eine HTTP-Antwort für den Browser liefert, öffnet das NAT den Port im ursprünglichen Paket, das vom Opfer gesendet wurde. Das NAT leitet nun jeden im SIP-Payload spezifizierten Port an den Angreifer weiter, da die Funktionalität vom VoIP-Protokoll durch den Router ermöglicht wird. Der Angreifer hat damit die NAT-Traversal Technik erfolgreich missbraucht, um interne Dienste zu erreichen.

Durch die Zusammenarbeit mit Forschen von Armis, konnte Samy die Möglichkeiten des Angriffs erweitern und zusammen erstellten sie ein Konzept, was die Attacke auf beliebige Hosts im NAT ermöglichte. Die Erweiterung von NAT Slipstreaming benutzt ein anderes Protokoll, um Ports zu öffnen, welches ebenfalls von einem ALG geprüft wird. Das Telekommunikationsprotokoll H.323 war besonders geeignet, da standardmäßig das ALG für H.323 meist aktiviert ist und das Protokoll einen Mechanismus besitzt, um Telefonate weiterzuleiten (call-forwarding). Durch call-forwarding können Sessions zu dritten IP-Adressen im NAT aufgebaut werden (Siehe Abbildung-3). Diese Logik kann jedoch ausgenutzt werden, um zu beliebigen Systemen des LANs Routen zum WAN zu etablieren.

[1] Samy hat auf seinem Blog mehr zu dem Thema veröffentlicht: www.samy.pl/webscan

[2] Microsoft und Apple unterstützen in ihren Browsern kein WebRTC

Abbildung-3: Schematische Darstellung des Call Forwarding Szenarios in H.323-Protokoll

Folgen von unfreiwilligem NAT-Traversal

Falls ein Nutzer Opfer eine Phishing-Attacke wird und ein Angreifer es durch NAT-Slipstreaming schafft, die NAT-Tabelle zu manipulieren, kann es sein, dass interne Systeme durch weitere Angriffe auf veraltete Software oder durch Ransomware-Attacken massiv zu Schaden kommen. Außerdem sind schwach verwaltete oder generell nicht-authentifizierte Dienste sowie Embedded Devices, die normalerweise vom NAT versteckt sind, in Gefahr missbraucht zu werden.

Bei Geräten, die nicht ständig aktiv von Administratoren verwaltet werden, kann es sein, dass Sicherheitslücken bekannt sind, die benutzt werden können, um jene zu attackieren. Mögliche Ziele könnten so beispielsweise sein: nicht authentifizierte Bürodrucker, IP-Kameras mit Standardpasswörtern, sonstige IoT-Geräte oder industrielle Netzwerkkomponenten und Prozesssteuerungsgeräte (SPS). Da regelmäßiges Patchen von nicht verwalteten Geräten zumeist eine größere Herausforderung darstellt, verlassen sich viele Unternehmen auf die reine Perimetersicherheit ihrer Netzwerke (durch Firewalls/NATs), um ihre ungepatchten Geräte vor dem Zugriff potenzieller Angreifer aus dem Internet zu schützen. Sobald der Perimeter aber durchbrochen wird, können diese unzureichend gepatchten Geräte bzw. nicht verwalteten Geräte ein leichtes Ziel für Angreifer sein, um sie zu übernehmen oder als Remote Access Tools zu fungieren, mit deren Hilfe weitere Angriffe erfolgen können.

Wie einfach die Attacke in der Theorie ablaufen kann, wird von den Armis‘ Forschen in einem Video demonstriert. Ein ahnungsloser Nutzer besucht eine Website von seinem Mobiltelefon aus und löst damit die NAT-Slipstreaming Attacke aus. Nachdem der Angreifer eine speicherprogrammierbare Steuerung im Netzwerk identifiziert hat, für die das Opfer ihm unwissend eine NAT-Eintrag erstellt hat, kann der Angreifer anfangen, den Controller zu manipulieren und so unmittelbar auf die Produktivumgebung einzuwirken.

Abbildung-4: Demonstrative Ansicht des Opfers, nachdem er den Server des Angreifers aufgerufen hat. (Oben). Terminal des Angreifers, welches eine SPS im Netz des Clients entdeckt hat (Unten).

Schutz vor NAT-Slipstreaming

Die Forscher haben ihre Attacken gegen verschiedene NAT-fähige Router und Firewalls getestet und konnten NAT-Slipstreaming bei Geräten von Fortinet, Cisco und HPE durchführen. Auf der anderen Seite haben sie auch alle gängigen Browser-Varianten benutzt, um ihr Konzept zu verifizieren. Nach Veröffentlichung der Attacke zogen die Browser-Hersteller nach und vergaben CVE-Einträge[1], die die Schwachstelle in dem jeweiligen Browser verfolgen. Eine relativ triviale Lösung ist es, die Standard SIP- und H.323-Anwendungsports als restriktiv einzustufen und so Verbindungen zu externen Servern generell zu unterbinden. Auf Seiten der Hersteller werden in den kommenden Monaten Firmware-Updates erwartet, die die Parser-Logik der ALGs ausbauen, um fragmentierte Pakete adäquat zu behandeln. Weitere mögliche IoCs (Indicator of Compromise) sind überdurchschnittlich große POST-Pakete, die wie beschrieben genutzt werden, um Segmentierungsgrenzen zu ermitteln. Wenn möglich sollten außerdem vorübergehend nicht benutzte ALGs abgeschaltet werden, um ungewolltes NAT-Traversal zu verhindern. Des Weiteren ist die Regulation von nicht vertrauenswürdigem JavaScript-Code aufseiten von Clients ein weiteres Mittel, um sich gegen NAT-Slipstreaming zu schützen.

Fazit

Die gut 20 Jahre alte Brückentechnologie NAT ist dank der ungewollten Privatsphäre-Eigenschaft und der langsamen IPv6-Adaptionsrate auch heute noch weit verbreitet. Peer-to-Peer Protokolle funktionieren oft nicht mit den Mechanismen der Netzwerkadressübersetzung. Es wird zusätzliche Software benötigt, um sie mit der Legacy-Technologie kompatibel zu machen. Es ist deshalb nicht verwunderlich, dass diese Schnittstelle erneut eine kritische Sicherheitslücke enthält, die die Funktionalität von ALGs missbraucht. Mit NAT-Slipstreaming wird gezeigt, wie das komplexe Zusammenspiel von verschiedenen Technologien ausgenutzt werden kann, um gezielt Schwachstellen zu verwenden, die die Sicherheit von privaten Netzen beeinträchtigt.

Autor: Fabian Kopp (GAI NetConsult GmbH)

Quellen
samy.pl/slipstream/
armis.com/natslipstreaming
Abbildung-1: commons.wikimedia.org/wiki/File:NAT_Concept-en.svg
Abbildung-3: people.netfilter.org/zhaojingmin/h323_conntrack_nat_helper/
Abbildung-4: youtube.com/watch?v=ZAEDu3kLR1o

[1] CVE-2020-16043, CVE-2021-1799 & CVE-2021-23961