Eine Schwachstelle, die das Eindringen in TCP-Verbindungen ermöglicht, die über VPN-Tunnel erfolgen

Veröffentlicht Angriffstechnik (CVE-2019-14899), die es ermöglicht, Pakete in TCP-Verbindungen zu manipulieren, die durch VPN-Tunnel geleitet werden. Das Problem betrifft Linux, FreeBSD, OpenBSD, Android, macOS, iOS und andere Unix-ähnliche Systeme. Linux unterstützt den Mechanismus rp_filter (Reverse Path Filtering) für IPv4, dessen Aktivierung im 'Strict'-Modus dieses Problem neutralisiert.

Die Methode ermöglicht das Einfügen von Paketen auf der Ebene von TCP-Verbindungen, die innerhalb eines verschlüsselten Tunnels verlaufen, erlaubt jedoch nicht, sich in Verbindungen einzuklinken, die zusätzliche Verschlüsselungsschichten anwenden (zum Beispiel TLS, HTTPS, SSH). Die in VPN verwendeten Verschlüsselungsalgorithmen sind irrelevant, da die gefälschten Pakete von der externen Schnittstelle stammen und vom Kernel als Pakete von der VPN-Schnittstelle behandelt werden. Das wahrscheinlichste Ziel des Angriffs ist die Manipulation unverschlüsselter HTTP-Verbindungen, aber es ist nicht auszuschließen dass die Attacke auch verwendet wird, um Antworten im DNS zu manipulieren.

Eine erfolgreiche Paketmanipulation wurde bei Tunnelverbindungen demonstriert, die durch OpenVPN, WireGuard und IKEv2/IPSec erstellt wurden. Tor ist von diesem Problem nicht betroffen, da es SOCKS verwendet, um den Verkehr weiterzuleiten und an die Loopback-Schnittstelle zu binden. Für IPv4 ist der Angriff möglich, wenn rp_filter in den 'Loose'-Modus versetzt wird (sysctl net.ipv4.conf.all.rp_filter = 2). Ursprünglich wurde in den meisten Systemen der 'Strict'-Modus verwendet, aber seit systemd 240, das im Dezember des letzten Jahres veröffentlicht wurde, wurde der Standardbetrieb auf 'Loose' geändert und diese Änderung spiegelt sich in den Standardeinstellungen vieler Linux-Distributionen wider.

Der Mechanismus rp_filter angewendet dient zur zusätzlichen Prüfung der Pfade von Paketen, um die Quellenadressenfälschung zu verhindern. Wenn er auf den Wert 0 gesetzt wird, erfolgt keine Überprüfung der Quellenadresse, und jedes Paket kann ohne Einschränkung zwischen den Netzwerkschnittstellen umgeleitet werden. Modus 1 'Strict' aktiviert die Überprüfung jedes eingehenden Pakets auf Übereinstimmung mit der Routingtabelle, und wenn die Netzwerkschnittstelle, über die das Paket empfangen wurde, nicht mit dem optimalen Antwortlieferungsweg verbunden ist, wird das Paket verworfen. Modus 2 'Loose' lockert die Prüfung, um den Betrieb bei Verwendung von Lastverteilern oder asymmetrischer Routing zu ermöglichen.
Der Antwortpfad kann nicht über das Netzwerk-Interface führen, über das das eingehende Paket empfangen wurde.

Im Modus „Loose“ wird das eingehende Paket mit der Routingtabelle abgeglichen, gilt jedoch als zulässig, wenn die Quelladresse über ein beliebiges verfügbares Netzwerk-Interface erreichbar ist. Der vorgeschlagene Angriff basiert darauf, dass der Angreifer ein Paket mit einer gefälschten Quelladresse senden kann, die dem VPN-Interface entspricht, und obwohl dieses Paket über das externe Netzwerk-Interface in das System gelangt, und nicht über das VPN, wird solch ein Paket im rp_filter-Modus „Loose“ nicht verworfen.

Um einen Angriff durchzuführen, muss der Angreifer das Gateway kontrollieren, über welches der Benutzer ins Netzwerk gelangt (zum Beispiel durch eine MITM-Organisation, wenn das Opfer mit einem vom Angreifer kontrollierten WLAN-Zugangspunkt verbunden ist oder durch Router-Hack). Indem er das Gateway kontrolliert, über das der Benutzer mit dem Netzwerk verbunden ist, kann der Angreifer gefälschte Pakete senden, die im Kontext des VPN-Netzwerk-Interfaces als gültig angesehen werden, aber die Antworten werden über den Tunnel geleitet.

Durch die Generierung eines Stroms gefälschter Pakete, in denen die IP-Adresse des VPN-Interfaces eingesetzt wird, werden Versuche unternommen, die vom Client hergestellte Verbindung zu beeinflussen. Die Auswirkungen dieser Pakete können jedoch nur durch eine passive Analyse des verschlüsselten Datenstroms, der mit dem Betrieb des Tunnels verbunden ist, beobachtet werden. Für den Angriff ist es notwendig, die vom VPN-Server zugewiesene IP-Adresse des Tunnel-Netzwerk-Interfaces zu ermitteln und festzustellen, dass derzeit über den Tunnel eine aktive Verbindung zu einem bestimmten Host besteht.

Zur Bestimmung der IP-Adresse des virtuellen Netzwerks-Interfaces VPN wird das System des Opfers durch das Senden von SYN-ACK-Paketen abgefragt, wobei der gesamte Bereich virtueller Adressen schrittweise durchlaufen wird (zunächst werden die in VPN standardmäßig verwendeten Adressen durchlaufen, z. B. in OpenVPN wird das Subnetz 10.8.0.0/24 verwendet). Ob eine Adresse existiert, kann anhand des Eintreffens einer Antwort mit dem RST-Flag beurteilt werden.

Auf ähnliche Weise wird die Verbindung zu einer bestimmten Website und die Portnummer auf der Client-Seite bestimmt – indem Portnummern durchlaufen werden, wird ein SYN-Paket in Richtung des Benutzers gesendet, wobei die IP der Website als Quelladresse eingesetzt wird und die Zieladresse die virtuelle IP des VPN ist. Der Serverport kann vorhergesagt werden (80 für HTTP), während die Portnummer auf der Client-Seite durch Ausprobieren ermittelt werden kann, indem die Intensität von ACK-Antworten für verschiedene Nummern analysiert wird in Kombination mit dem Fehlen eines Pakets mit dem RST-Flag.

In diesem Stadium kennt der Angreifer alle vier Elemente der Verbindung (Quell-IP-Adresse/Port und Ziel-IP-Adresse/Port), aber um ein gefälschtes Paket zu generieren, das vom Zielsystem akzeptiert wird, muss der Angreifer die Sequenz- und Bestätigungsnummern (seq und ack) der TCP-Verbindung bestimmen. Um diese Parameter zu ermitteln, sendet der Angreifer kontinuierlich gefälschte RST-Pakete, während er verschiedene Sequenznummern durchläuft, bis er ein Antwort-ACK-Paket erhält, dessen Empfang anzeigt, dass die Nummer innerhalb des TCP-Fensters liegt.

Dann präzisiert der Angreifer die Richtigkeit der Bestimmung, indem er Pakete mit derselben Nummer sendet und die ACK-Antworten beobachtet, woraufhin er die genaue aktuelle Sequenznummer ermittelt. Die Aufgabe wird dadurch kompliziert, dass die Antworten innerhalb eines verschlüsselten Tunnels gesendet werden und ihre Anwesenheit im abgefangenen Datenstrom nur indirekt analysiert werden kann. Die Tatsache, dass ein an den VPN-Server adressiertes ACK-Paket vom Client gesendet wird, wird anhand der Größe und der Verzögerung der verschlüsselten Antworten bestimmt, die mit dem Versand gefälschter Pakete korrelieren. Zum Beispiel erlaubt ein verschlüsseltes Paket mit einer Größe von 79 für OpenVPN eine genaue Schlussfolgerung, dass darin ein ACK-Bestätigung enthalten ist.

Bevor ein Schutz gegen den Angriff in den Kern des Betriebssystems integriert wird, kann vorübergehend folgendermassen die Problematik blockiert werden. wird empfohlen Durch Verwendung eines Paketfilters in der „preroute“-Kette wird der Durchlauf von Paketen blockiert, bei denen die Zieladresse die virtuelle IP-Adresse des Tunnels ist.

iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! —src-type LOCAL -j DROP

oder für nftables

nft add table ip raw
nft add chain ip raw prerouting ‘{ type filter hook prerouting priority 0; }’
nft add rule ip raw prerouting ‘iifname != «wg0» ip daddr 10.182.12.8 fib saddr type != local drop’

Zum Schutz bei der Verwendung von Tunneln mit IPv4-Adressen genügt es, den rp_filter in den Modus „Streng“ zu versetzen („sysctl net.ipv4.conf.all.rp_filter = 1“). Auf VPN-Seite kann die Methode zur Bestimmung der Sequenznummer blockiert werden, indem den verschlüsselten Paketen Füllmaterial hinzugefügt wird, das die Größe aller Pakete gleich macht.

Quelle: opennet.ru