Sicherheitslücke, die es ermöglicht, über VPN-Tunnel hergestellte TCP-Verbindungen zu kapern

Veröffentlicht eine Angriffstechnik (CVE-2019-14899), die es ermöglicht, Pakete in TCP-Verbindungen, die über VPN-Tunnel weitergeleitet werden, zu fälschen, zu ändern oder zu ersetzen. Das Problem betrifft Linux, FreeBSD, OpenBSD, Android, macOS, iOS und andere Unix-ähnliche Systeme. Linux unterstützt den rp_filter-Mechanismus (Reverse Path Filtering) für IPv4. Wenn Sie ihn im „Strict“-Modus aktivieren, wird dieses Problem neutralisiert.

Die Methode ermöglicht die Paketersetzung auf der Ebene von TCP-Verbindungen, die innerhalb eines verschlüsselten Tunnels verlaufen, erlaubt jedoch nicht das Einklemmen in Verbindungen, die zusätzliche Verschlüsselungsebenen verwenden (z. B. TLS, HTTPS, SSH). Die im VPN verwendeten Verschlüsselungsalgorithmen spielen keine Rolle, da die gefälschten Pakete von der externen Schnittstelle stammen und vom Kernel als Pakete von der VPN-Schnittstelle verarbeitet werden. Das wahrscheinlichste Ziel des Angriffs besteht jedoch darin, unverschlüsselte HTTP-Verbindungen zu stören nicht ausgeschlossen und einen Angriff nutzen, um DNS-Antworten zu manipulieren.

Erfolgreiches Paket-Spoofing wurde für Tunnel nachgewiesen, die mit OpenVPN, WireGuard und IKEv2/IPSec erstellt wurden. Tor ist für das Problem nicht anfällig, da es SOCKS zur Weiterleitung des Datenverkehrs verwendet und an eine Loopback-Schnittstelle gebunden ist. Bei IPv4 ist ein Angriff möglich, wenn rp_filter auf den „Loose“-Modus eingestellt ist (sysctl net.ipv4.conf.all.rp_filter = 2). Anfangs verwendeten die meisten Systeme den „Streng“-Modus, aber ab System 240, das letzten Dezember veröffentlicht wurde, wurde der Standardbetriebsmodus auf „Loose“ geändert und diese Änderung spiegelte sich in den Standardeinstellungen vieler Linux-Distributionen wider.

rp_filter-Mechanismus gilt zur zusätzlichen Überprüfung von Paketpfaden, um Spoofing der Quelladresse zu verhindern. Bei der Einstellung 0 wird keine Überprüfung der Quelladresse durchgeführt und jedes Paket kann ohne Einschränkungen zwischen Netzwerkschnittstellen weitergeleitet werden. Modus 1 „Streng“ umfasst die Überprüfung jedes von außen kommenden Pakets auf Übereinstimmung mit der Routing-Tabelle. Wenn die Netzwerkschnittstelle, über die das Paket empfangen wurde, nicht mit der optimalen Antwortzustellungsroute verknüpft ist, wird das Paket verworfen. Modus 2 „Loose“ lockert die Prüfung, damit Load Balancer oder asymmetrisches Routing funktionieren können
Die Antwortroute verläuft möglicherweise über eine andere Netzwerkschnittstelle als die, über die das eingehende Paket angekommen ist.

Im Loose-Modus wird ein eingehendes Paket anhand der Routing-Tabelle überprüft, gilt jedoch als gültig, wenn die Quelladresse über eine verfügbare Netzwerkschnittstelle erreichbar ist. Der vorgeschlagene Angriff basiert auf der Tatsache, dass der Angreifer ein Paket mit einer gefälschten Quelladresse senden kann, die der VPN-Schnittstelle entspricht, und zwar trotz der Tatsache, dass dieses Paket über die externe Netzwerkschnittstelle und nicht über das VPN in das System gelangt Im rp_filter-Modus „Loose“ wird ein solches Paket nicht verworfen.

Um einen Angriff durchzuführen, muss der Angreifer das Gateway kontrollieren, über das der Benutzer auf das Netzwerk zugreift (z. B. über eine MITM-Organisation, wenn das Opfer eine Verbindung zu einem vom Angreifer kontrollierten drahtlosen Zugangspunkt herstellt, oder über Router-Hacking). Durch die Kontrolle des Gateways, über das ein Benutzer mit dem Netzwerk verbunden ist, kann ein Angreifer gefälschte Pakete senden, die im Kontext der VPN-Netzwerkschnittstelle wahrgenommen werden, die Antworten werden jedoch durch den Tunnel weitergeleitet.

Durch die Generierung eines Stroms fiktiver Pakete, in denen die IP-Adresse der VPN-Schnittstelle ersetzt wird, wird versucht, die vom Client aufgebaute Verbindung zu beeinflussen, der Einfluss dieser Pakete kann jedoch nur durch passive Analyse des damit verbundenen verschlüsselten Verkehrsflusses beobachtet werden mit dem Betrieb des Tunnels. Um einen Angriff durchzuführen, müssen Sie die vom VPN-Server zugewiesene IP-Adresse der Tunnel-Netzwerkschnittstelle herausfinden und außerdem feststellen, dass derzeit eine Verbindung zu einem bestimmten Host über den Tunnel aktiv ist.

Um die IP der virtuellen VPN-Netzwerkschnittstelle zu ermitteln, werden SYN-ACK-Pakete an das Opfersystem gesendet, die nacheinander den gesamten Bereich virtueller Adressen auflisten (zunächst werden standardmäßig die im VPN verwendeten Adressen aufgezählt, z. B. OpenVPN). verwendet das Subnetz 10.8.0.0/24). Das Vorhandensein einer Adresse kann anhand des Empfangs einer Antwort mit dem RST-Flag beurteilt werden.

Auf ähnliche Weise wird das Vorhandensein einer Verbindung zu einer bestimmten Site und die Portnummer auf der Clientseite ermittelt – durch Aussortieren der Portnummern wird ein SYN-Paket als Quelladresse an den Benutzer gesendet, in dem die IP des Standorts wird ersetzt und die Zieladresse ist ein virtuelles IP-VPN. Der Server-Port kann vorhergesagt werden (80 für HTTP), und die Portnummer auf der Clientseite kann durch Brute-Force berechnet werden, indem für verschiedene Zahlen die Änderung der Intensität von ACK-Antworten in Kombination mit dem Fehlen eines Pakets mit dem RST analysiert wird Flagge.

Zu diesem Zeitpunkt kennt der Angreifer alle vier Elemente der Verbindung (Quell-IP-Adresse/Port und Ziel-IP-Adresse/Port), aber um ein fiktives Paket zu generieren, das das Opfersystem akzeptiert, muss der Angreifer die TCP-Sequenz bestimmen und Bestätigungsnummern (seq und ack) – Verbindungen. Um diese Parameter zu ermitteln, sendet der Angreifer kontinuierlich gefälschte RST-Pakete und probiert dabei verschiedene Sequenznummern aus, bis er ein ACK-Antwortpaket erkennt, dessen Ankunft anzeigt, dass die Nummer innerhalb des TCP-Fensters liegt.

Als nächstes verdeutlicht der Angreifer die Richtigkeit der Definition, indem er Pakete mit derselben Nummer sendet und das Eintreffen von ACK-Antworten beobachtet. Anschließend wählt er die genaue Nummer der aktuellen Sequenz aus. Die Aufgabe wird dadurch erschwert, dass Antworten innerhalb eines verschlüsselten Tunnels gesendet werden und ihre Anwesenheit im abgefangenen Verkehrsstrom nur mit indirekten Methoden analysiert werden kann. Ob ein Client ein an den VPN-Server adressiertes ACK-Paket sendet, wird anhand der Größe und Latenz der verschlüsselten Antworten bestimmt, die mit dem Senden gefälschter Pakete korrelieren. Bei OpenVPN können Sie beispielsweise mit einer verschlüsselten Paketgröße von 79 genau beurteilen, ob ein ACK enthalten ist.

Bis der Angriffsschutz dem Betriebssystemkernel als vorübergehende Methode zur Blockierung des Problems hinzugefügt wird empfohlen Blockieren Sie mithilfe eines Paketfilters in der „Preroute“-Kette den Durchgang von Paketen, in denen die virtuelle IP-Adresse des Tunnels als Zieladresse angegeben 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 Tabelle IP Raw hinzufügen
NFT Add Chain IP Raw Prerouting '{ Typ Filter Hook Prerouting Priority 0; }'
NFT Regel hinzufügen IP Raw Prerouting 'iifname != "wg0" IP Daddr 10.182.12.8 Fib Saddr Type != Local Drop'

Um sich bei der Verwendung von Tunneln mit IPv4-Adressen zu schützen, stellen Sie rp_filter einfach auf den „Strict“-Modus („sysctl net.ipv4.conf.all.rp_filter = 1“). Auf der VPN-Seite kann die Methode zur Erkennung der Sequenznummer blockiert werden, indem den verschlüsselten Paketen zusätzliche Auffüllung hinzugefügt wird, sodass alle Pakete die gleiche Größe haben.

Source: opennet.ru

Kommentar hinzufügen