95 Sicherheitsberichte über 32 Produkte und Konfigurationen ergeben ein eindeutiges Bild: Jede getestete NAT-Implementierung ist verwundbar. Der unabhängige Forscher Malcolm Stagg präsentierte auf der Black Hat USA 2026 die Angriffsklasse NatJack. Sie manipuliert die Verbindungsverwaltung von Network Address Translation (NAT) direkt. Aktive Verbindungen lassen sich entführen, DNS-Antworten vergiften und Denial-of-Service auslösen. Klassische IP-Spoofing-Angriffe oder Zugriff auf den Broadcast-Domänen-Bereich sind nicht nötig.
Wenn du ein Netzwerk betreibst, solltest du genau hinschauen. NatJack funktioniert gegen Windows, Linux und macOS gleichermaßen – obwohl diese Systeme keinen gemeinsamen NAT-Codebase haben. Das deutet auf ein grundlegendes Designproblem hin, nicht auf einen einzelnen Programmierfehler.
Stell dir NAT wie eine Hausverwaltung vor, die alle Briefe für ein Mehrfamilienhaus an einer Adresse annimmt und dann an die Wohnungen weiterleitet. Die Hausverwaltung prüft nicht, ob ein Absender wirklich der ist, der er zu sein behauptet. Sie vertraut darauf, dass niemand böswillig handelt. Genau diese Vertrauenslücke macht NatJack aus.
Die Vertrauensannahme in NAT
NAT entstand in den frühen 1990er-Jahren als Übergangslösung gegen die IPv4-Adressknappheit. Mehrere Geräte teilen sich eine öffentliche IP-Adresse, intern verwenden sie private Adressen. Die Spezifikationen, die dieses Verhalten festlegten, gingen von einer friedlichen Umgebung aus. Stagg erklärt, dass diese Annahme tief in den RFCs verankert ist und bis heute fortbesteht.
Die Unter-Spezifikation erlaubt es der NAT, Verbindungen anhand von Quell- und Zieladressen sowie Ports zu verfolgen. Die dabei entstehende Tabelle, die Connection Tracking Table, ist das Herzstück von NAT. Sie hält fest, welches interne Gerät mit welchem externen Ziel kommuniziert und welche temporären Ports zugeordnet wurden. Wer die Kontrolle über diese Tabelle erlangt, kann praktisch jede Verbindung durch den NAT-Punkt umleiten.
Die Sicherheitslücke ist nicht neu. 2010 zeigte Samy Kamkar mit NAT Pinning, wie sich NAT-Verhalten manipulieren lässt. 2020 folgte NAT Slipstreaming, das das Application Level Gateway (ALG) ausnutzte. Diese Angriffe erforderten aber entweder eine Interaktion des Opfers oder den Einsatz von ALG-Diensten. NatJack umgeht diese Hürden: Es greift direkt auf die Connection Tracking Table zu, benötigt keine ALG-Unterstützung und genügt eine aktive Verbindung, die das Opfer bereits aufgebaut hat.
Layer-2-Isolationen wie VLAN-Segmentierung oder Switch-Port-Isolation bieten keinen Schutz. Die Angriffe finden auf Ebene 3 und 4 statt – in der Vermittlungs- und Transportschicht – und richten sich gegen die gemeinsame NAT-Infrastruktur. Selbst wenn du deine Netzwerksegmente strikt trennst, bleiben alle Geräte, die dieselbe NAT verwenden, verwundbar.
Vier Techniken, ein gemeinsamer Kern
NatJack umfasst vier verschiedene Angriffsvarianten, die alle auf derselben Schwachstelle beruhen: der fehlenden Überprüfung von Paketen, die die NAT-Tabelle verändern können. Stagg hat diese Techniken dokumentiert und veröffentlicht.
Die erste Technik ist die TCP-Verbindungsentführung. Der Angreifer sendet manipulierte Pakete, die eine laufende Verbindung in den Zustand „geschlossen“ versetzen. Dafür nutzt er den RFC-1337-Mechanismus namens TIME-WAIT Assassination. Der Zustand lässt sich mit wenigen Paketen erreichen, ohne auf ein normales Timeout zu warten. Anschließend ersetzt der Angreifer den Tabelleneintrag der Verbindung durch einen eigenen, sodass die Kommunikation über ihn umgeleitet wird. So kann er Daten abfangen oder sich in die Verbindung einschleusen.
Die zweite Technik ist die DNS-Antwort-Vergiftung. NatJack fängt UDP-DNS-Antworten ab, die durch die NAT laufen, und verändert sie. Das Opfer erhält gefälschte IP-Adressen für angefragte Domains, was zu Phishing oder Weiterleitungen auf Malware-Server führen kann. Der Angriff bleibt für den Nutzer unsichtbar: Die DNS-Antworten kommen ja von der NAT, der Browser ahnt nicht, dass sie manipuliert wurden.
Die dritte Technik ist ein Denial-of-Service-Angriff auf die NAT-Tabelle selbst. Der Angreifer sendet massenhaft Verbindungsanfragen oder Pakete mit gefälschten Adressen und füllt die Tabelle, bis keine neuen Verbindungen mehr aufgebaut werden können. Das betrifft nicht nur das einzelne Gerät, sondern alle Geräte hinter derselben NAT. Ein einziges bösartiges Gerät kann das gesamte Netzwerk lahmlegen.
Viertens gibt es die Verbindungs-Port-Identifikation. Der Angreifer findet heraus, welchen externen Port die NAT einem aktiven Datenstrom zugewiesen hat. Diese Information ist die Grundlage für die anderen drei Angriffe – ohne den korrekten Port lassen sich die Tabelleneinträge nicht gezielt manipulieren. Die Identifikation selbst ist nicht schädlich, dient aber als Aufklärungsphase.
Alle vier Techniken sind kombinierbar. Ein Angreifer kann zuerst den Port einer Verbindung ermitteln, dann die Verbindung beenden, den Tabelleneintrag übernehmen und anschließend gefälschte DNS-Antworten einschleusen. Das geht in Sekundenschnelle und erfordert keine besonderen Privilegien – lediglich die Möglichkeit, Pakete durch dieselbe NAT zu senden.
Herstellerreaktionen: Uneinheitlich und teils enttäuschend
Stagg meldete die Schwachstellen an dreizehn Hersteller. Die Antworten fielen sehr unterschiedlich aus. Das Linux-Kernel-Team wies den Bericht zunächst mit den Worten „total bogus“ zurück, wie Stagg in einem Interview berichtete. Er war überrascht und enttäuscht, doch später änderte sich die Lage: Auf Anfrage von Microsoft hin wurde der Fehler im Linux-Kernel behoben, um Azure Kubernetes Service zu unterstützen. Dafür erhielt die Schwachstelle die CVE-2026-63913.
Auch Microsoft selbst war betroffen: Die Windows-NAT-Implementierung für Hyper-V erhielt die CVE-2026-56181. Der Patch wurde im Rahmen eines regulären Sicherheitsupdates ausgeliefert. Andere Anbieter wie Cisco und Apple bewerteten die Ergebnisse jedoch nicht als Sicherheitslücken. Cisco verwies auf dokumentierte Mitigationsmaßnahmen für seine Produkte, Apple auf die Annahme, dass lokale Netzwerke feindlich sein können und End-to-End-Verschlüsselung wie TLS den Schaden begrenzt.
Stagg merkt an, dass Verschlüsselung tatsächlich hilft, aber sie kann nicht alles verhindern. Ein Angreifer, der eine Verbindung entführt, kann den verschlüsselten Datenstrom nicht lesen, aber er kann die Verbindung abrupt beenden oder blockieren. Das führt zu einem Denial-of-Service auf Anwendungsebene. Zudem sind nicht alle Protokolle standardmäßig verschlüsselt, und auch verschlüsselte Verbindungen können durch die Manipulation der NAT-Parameter unterbrochen werden.
Die unterschiedlichen Reaktionen zeigen, wie uneinheitlich die Branche mit Designfehlern umgeht. Einige Hersteller erkennen das Problem an und liefern Patches aus, andere sprechen von „Design-Limitationen“ und verweisen auf Best-Practice-Empfehlungen. Für dich als Netzwerkbetreiber bedeutet das: Du kannst dich nicht darauf verlassen, dass dein NAT-Gerät von Haus aus sicher ist. Du musst selbst aktiv werden.
Schutzmaßnahmen: Was Netzwerkbetreiber jetzt tun können
Auch ohne vollständige Patches gibt es mehrere konkrete Schritte, die das Risiko deutlich reduzieren. Stagg nennt in seinem Vortrag eine Reihe von Empfehlungen, die du direkt umsetzen kannst.
Überwache deine Netzwerk-Infrastruktur auf Auffälligkeiten. Dazu gehören eine vollständige oder fast volle NAT-Tabelle, ungewöhnliche Paketfluten über weite Portbereiche, die gleiche IP-Adresse an zwei physischen Standorten oder anomale SYN- und RST-Paketfolgen. Solche Anzeichen deuten darauf hin, dass ein Angreifer versucht, die Verbindungstabelle zu manipulieren.
Aktiviere den IP-Source-Guard an deinen Routern und Firewalls. Diese Schutzfunktion blockiert Pakete mit gefälschten Quelladressen, was viele NatJack-Varianten erschwert. Zusätzlich solltest du unvertrauenswürdige Geräte in separate Subnetze oder VLANs auslagern und die Verbindungsanzahl pro Client begrenzen – Stagg empfiehlt einen Wert von unter 10.000 gleichzeitig aktiven Verbindungen. Eine solche Begrenzung verhindert, dass ein einzelner Client die NAT-Tabelle überfluten kann.
Prüfe, ob dein NAT-Gerät sogenannte „Loose Connection Tracking“ oder „Port Preservation“ verwendet. Diese Modi erhöhen den Komfort für Anwendungen, schwächen aber auch die Sicherheit. Wenn möglich, deaktiviere sie und verwende striktes Adress- und Port-Mapping. Bei Containern solltest du den Netzwerkzugriff für unvertrauenswürdige Workloads einschränken: keine root-Rechte, keine Standard-Capabilities, und deaktiviere das Netzwerk für Container, die nicht zwingend erreichbar sein müssen.
In Cloud-Umgebungen gilt dieselbe Logik: Halte vertrauenswürdige und unvertrauenswürdige Workloads strikt getrennt, und nutze für Serverless-Funktionen dedizierte öffentliche IPs, anstatt sie über einen gemeinsamen NAT-Gateway laufen zu lassen. Stagg weist darauf hin, dass eine der Angriffsvarianten auch zwischen verschiedenen Subnetzen funktioniert, also eine Trennung auf Subnetzebene nicht ausreicht. Die Isolation muss auf NAT-Ebene erfolgen.
Die Lektion aus NatJack: Historische Annahmen neu bewerten
NatJack ist mehr als nur eine weitere Sicherheitslücke. Es zeigt, wie sehr sich die Bedrohungslandschaft verändert hat, während unsere Netzwerktechnik in den 1990er-Jahren stehen geblieben ist. Die Annahme, dass alle Geräte hinter einer NAT vertrauenswürdig sind, war vielleicht einmal vertretbar – in Zeiten, in denen Netzwerke aus wenigen Rechnern bestanden, die von derselben Administration kontrolliert wurden. Heute jedoch verbinden sich unzählige IoT-Geräte, Gastnotebooks, Smartphones und Cloud-Workloads über denselben NAT-Punkt. Jedes dieser Geräte könnte bereits kompromittiert sein oder böswillig agieren.
Die Tatsache, dass NatJack auf allen drei Betriebssystemfamilien funktioniert, ohne dass der Code geteilt wird, unterstreicht den systemischen Charakter des Problems. Es handelt sich nicht um einen einzelnen Fehler, sondern um ein grundlegendes Vertrauensmodell, das der heutigen Realität nicht mehr standhält. Sicherheitsarchitekten müssen sich daher von der Vorstellung verabschieden, dass eine NAT automatisch Schutz bietet. Sie ist eine Adressumsetzung, keine Firewall.
Für dich als Entscheider im Netzwerk bedeutet das: Du musst deine Sicherheitslösungen auf mehreren Ebenen implementieren. Verschleiere die interne Struktur nicht durch NAT allein, sondern setze zusätzlich auf robuste Firewall-Regeln, Intrusion-Detection-Systeme und eine konsequente Segmentierung. Und überprüfe regelmäßig die Designannahmen deiner Infrastruktur. Was vor zwanzig Jahren sicher war, kann heute ein Einfallstor sein.
Stagg fasst es treffend zusammen: Man dürfe sich nicht auf die historischen Designentscheidungen verlassen, sondern müsse die Bedrohungsmodelle von heute anwenden. NatJack ist ein Weckruf – und eine Chance, die Sicherheitsarchitektur endlich an die Realität anzupassen.
Quelle: networkworld.com
