Sicherheitsanfälligkeit, die es ermöglicht, sich in TCP-Verbindungen einzuschleusen, die über VPN-Tunnel hergestellt werden.

Veröffentlicht Angriffstechnik (CVE-2019-14899), die es ermöglicht, Pakete in TCP-Verbindungen, die durch VPN-Tunnel geleitet werden, zu ersetzen, zu modifizieren oder einzuschleusen. 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 es, Pakete auf der Ebene von TCP-Verbindungen, die innerhalb eines verschlüsselten Tunnels verlaufen, zu ersetzen, lässt jedoch keinen Eingriff in Verbindungen zu, die zusätzliche Verschlüsselungsebenen (z. B. TLS, HTTPS, SSH) verwenden. Die verwendeten Verschlüsselungsalgorithmen in VPNs sind irrelevant, da die gefälschten Pakete von der externen Schnittstelle stammen und vom Kernel wie Pakete von der VPN-Schnittstelle verarbeitet werden. Das wahrscheinlichste Ziel des Angriffs ist die Manipulation von unverschlüsselten HTTP-Verbindungen, aber ein Einsatz der Attacke zur Manipulation von DNS-Antworten ist nicht ausgeschlossen. und die Verwendung von Angriffen zur Manipulation von DNS-Antworten.

Erfolgreiche Paketmanipulation wurde für Tunnel demonstriert, die mit OpenVPN, WireGuard und IKEv2/IPSec erstellt wurden. Tor ist von diesem Problem nicht betroffen, da es SOCKS für das Traffic-Forwarding und die Bindung an das Loopback-Interface verwendet. Bei IPv4 ist ein Angriff möglich, wenn der rp_filter in den Modus "Loose" überführt wird (sysctl net.ipv4.conf.all.rp_filter = 2). Ursprünglich wurde in den meisten Systemen der Modus "Strict" verwendet, aber seit systemd 240, das im Dezember letzten Jahres veröffentlicht wurde, wurde der Standardbetriebsmodus auf "Loose" geändert, und diese Änderung spiegelt sich in den Standardeinstellungen vieler Linux-Distributionen wider.

Der rp_filter-Mechanismus verwendet zur zusätzlichen Überprüfung der Pfade zur Verhinderung von Quelladressen-Spoofing. Wenn auf 0 gesetzt, erfolgt keine Überprüfung der Quelladresse, und jedes Paket kann ohne Einschränkungen zwischen den Netzwerkinterfaces weitergeleitet werden. Modus 1 "Strict" beinhaltet die Überprüfung jedes eingehenden Pakets auf Übereinstimmung mit der Routing-Tabelle; wenn das Netzwerkinterface, über das das Paket empfangen wurde, nicht mit der optimalen Route für die Antwort verbunden ist, wird das Paket verworfen. Modus 2 "Loose" lockert die Überprüfung, um den Betrieb mit Lastenausgleich oder asymmetrischem Routing zu ermöglichen, bei dem
der Rückweg nicht über das Netzwerkinterface führen muss, über das das eingehende Paket empfangen wurde.

Im „Loose“-Modus wird das eingehende Paket auf Übereinstimmung mit der Routingtabelle überprüft, jedoch als zulässig angesehen, wenn die Quelladresse über eines der verfügbaren Netzwerkinterfaces erreichbar ist. Der vorgeschlagene Angriff basiert darauf, dass der Angreifer ein Paket mit einer gefälschten Quelladresse senden kann, die zum VPN-Interface passt. Obwohl dieses Paket über das externe Netzwerkinterface und nicht über das VPN in das System gelangt, wird ein Paket im „Loose“-Modus des rp_filter nicht verworfen.

Um den Angriff durchzuführen, muss der Angreifer das Gateway kontrollieren, über das der Benutzer mit dem Netzwerk verbunden ist (zum Beispiel durch eine MITM-Organisation, wenn das Opfer mit einem vom Angreifer kontrollierten Zugangspunkt verbunden ist, oder durch das Hacken eines Routers). 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-Netzwerkinterfaces wahrgenommen werden, die Antworten jedoch über den Tunnel zurückgesendet werden.

Durch die Generierung eines Stroms von gefälschten Paketen, in denen die IP-Adresse des VPN-Interfaces eingesetzt wird, wird versucht, das vom Kunden hergestellte Verbindung zu beeinflussen. Die Auswirkungen dieser Pakete können jedoch nur durch eine passive Analyse des verschlüsselten Datenverkehrs, der mit dem Betrieb des Tunnels verbunden ist, beobachtet werden. Für einen Angriff ist es notwendig, die vom VPN-Server zugewiesene IP-Adresse des Tunnel-Netzwerkinterfaces zu erfahren und zu bestimmen, dass derzeit eine Verbindung zu einem bestimmten Host über den Tunnel aktiv ist.

Um die IP des virtuellen Netzwerkinterfaces des VPN zu bestimmen, werden SYN-ACK-Pakete an das Zielsystem gesendet, wobei der gesamte Bereich der virtuellen Adressen nacheinander durchprobiert wird (zunächst werden Adressen verwendet, die im VPN standardmäßig genutzt werden, wie zum Beispiel das Subnetz 10.8.0.0/24, das in OpenVPN verwendet wird). Das Vorhandensein einer Adresse kann an der Rückmeldung mit dem RST-Flag festgestellt werden.

Auf ähnliche Weise wird die Verbindung zu einer bestimmten Website und die Portnummer auf der Clientseite festgestellt — indem die Portnummern des Nutzers durchlaufen werden, wird ein SYN-Paket gesendet, dessen Quelladresse die IP der Website ist und die Zieladresse die virtuelle IP des VPN. Der Serverport kann vorhergesagt werden (80 für HTTP), während die Portnummer auf der Clientseite durch Analyse der Veränderungen in der Intensität der ACK-Antworten in Kombination mit dem Fehlen eines RST-Flag-Pakets ermittelt werden kann.

In diesem Stadium kennt der Angreifer alle vier Elemente der Verbindung (IP-Adressen/Ports der Quelle und des Ziels), aber um ein gefälschtes Paket zu generieren, das vom System des Opfers akzeptiert wird, muss der Angreifer die Sequenz- und Bestätigungsnummern (seq und ack) der TCP-Verbindung bestimmen. Um diese Parameter festzustellen, sendet der Angreifer kontinuierlich gefälschte RST-Pakete, wobei er verschiedene Sequenznummern ausprobiert, bis er ein zurückkommendes ACK-Paket feststellt, dessen Eingang anzeigt, dass die Nummer innerhalb des TCP-Fensters liegt.

Anschließend prüft der Angreifer die Richtigkeit der Identifizierung, indem er Pakete mit derselben Nummer sendet und den Eingang von ACK-Antworten beobachtet, woraufhin er die genaue Nummer der aktuellen Sequenz ermittelt. Die Aufgabe wird dadurch erschwert, dass die Antworten innerhalb eines verschlüsselten Tunnels gesendet werden und ihre Existenz 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 lässt für OpenVPN ein verschlüsseltes Paket mit der Größe 79 genau darauf schließen, dass es sich innerhalb um eine ACK-Bestätigung handelt.

Bevor der Angriffsschutz in den Kernel des Betriebssystems aufgenommen wird, kann als vorübergehende Methode zur Blockierung des Problems es empfohlen wird mithilfe eines Paketfilters in der Kette „preroute“ Pakete blockieren, deren Zieladresse die virtuelle IP-Adresse des Tunnels anzeigt.

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’

Um beim Einsatz von IPv4-Tunneln Schutz zu gewährleisten, genügt es, den rp_filter in den Modus „Strict“ zu versetzen („sysctl net.ipv4.conf.all.rp_filter = 1“). Auf der VPN-Seite kann die Methode zur Bestimmung der Sequenznummer blockiert werden, indem Zusatzdaten zu den verschlüsselten Paketen hinzugefügt werden, die dafür sorgen, dass alle Pakete gleich groß sind.

Quelle: opennet.ru