New Linux Bug Lets Attackers Hijack Encrypted VPN Connections
VPN Schwachstelle in vielen (Linux-)Systemen
New Linux Bug Lets Attackers Hijack Encrypted VPN Connections
VPN Schwachstelle in vielen (Linux-)Systemen
Neue VPN Schwachstelle - Nix ist sicher (ausser den Renten natürlich)? Schau mal ob du hier fündig wirst!
Die Schwachstelle liegt aber nicht zwangsläufig begründet im Linux oder in OpenVPN, sondern vorrangig im schlecht konfigurierten VPN. Wer TCP als Protokoll wählt, die Verbindungssicherheit nicht auf TLS 1.3 begrenzt und nicht-authentifizierte Pakete im unverschlüsselten Control-Channel zulässt, ist selber schuld. Nach meinem Verständnis kann ein Angreifer bei einem sicher konfigurierten VPN nur Müll "injizieren", ohne dabei aber die Sitzungsschlüssel zu kennen... und wobei der Müll dann mit aktiver Authentifizierung auf beiden Kanälen schlichtweg verworfen wird... also letztlich ist das allenfalls störend, aber nicht wirklich schädlich. Wer's besser machen will, nimmt halt kein TCP.
Wer TCP als Protokoll wählt, .... Wer's besser machen will, nimmt halt kein TCP.
Es geht ja um das Zwischennetz. Aber auch das kann man so konfigurieren, dass auf syn+ack (als NEW) nie mit rst geantwortet wird.
:~$ sudo nping -c 3 --tcp --flags syn,ack --delay 1s -g 12345 -p 11111 10.4.0.1
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2019-12-06 17:03 CET
SENT (0.0269s) TCP 10.4.0.6:12345 > 10.4.0.1:11111 SA ttl=64 id=2291 iplen=40 seq=452014447 win=1480
RCVD (0.2130s) TCP 10.4.0.1:11111 > 10.4.0.6:12345 R ttl=64 id=0 iplen=40 seq=144299849 win=0
SENT (1.0272s) TCP 10.4.0.6:12345 > 10.4.0.1:11111 SA ttl=64 id=2291 iplen=40 seq=452014447 win=1480
RCVD (1.2130s) TCP 10.4.0.1:11111 > 10.4.0.6:12345 R ttl=64 id=0 iplen=40 seq=144299849 win=0
SENT (2.0290s) TCP 10.4.0.6:12345 > 10.4.0.1:11111 SA ttl=64 id=2291 iplen=40 seq=452014447 win=1480
RCVD (2.2130s) TCP 10.4.0.1:11111 > 10.4.0.6:12345 R ttl=64 id=0 iplen=40 seq=144299849 win=0
Max rtt: 186.003ms | Min rtt: 183.940ms | Avg rtt: 185.239ms
Raw packets sent: 3 (120B) | Rcvd: 3 (120B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 2.24 seconds
Alles anzeigen
:~$ sudo nping -c 3 --tcp --flags syn,ack --delay 1s -g 12345 -p 11111 10.4.0.1
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2019-12-06 17:04 CET
SENT (0.0257s) TCP 10.4.0.6:12345 > 10.4.0.1:11111 SA ttl=64 id=50315 iplen=40 seq=723296056 win=1480
SENT (1.0260s) TCP 10.4.0.6:12345 > 10.4.0.1:11111 SA ttl=64 id=50315 iplen=40 seq=723296056 win=1480
SENT (2.0265s) TCP 10.4.0.6:12345 > 10.4.0.1:11111 SA ttl=64 id=50315 iplen=40 seq=723296056 win=1480
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (120B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 3.05 seconds
iptables -I INPUT 1 -t security -i tun+ -p tcp --tcp-flags SYN,ACK SYN,ACK -d 10.4.0.0/8 -m state --state NEW,INVALID -j DROP
(oder gleichwertig).
Es geht ja um das Zwischennetz. Aber auch das kann man so konfigurieren, dass auf syn+ack (als NEW) nie mit rst geantwortet wird.
Via Paketfilter? Wobei ich mir das "kritisch" vorstelle... denn es muss ja dabei unterschieden werden, ob es sich um einen legaln Verbindungsaufbau meines eigenen Gerätes handelt oder um die genannte Attacke.
Evtl. analog zu https://lists.zx2c4.com/pipermail/wire…ber/004679.html
eine Regel erstellen, die Pakete verwirft, die nicht aus dem Tunnel stammen.
Via Paketfilter? Wobei ich mir das "kritisch" vorstelle... denn es muss ja dabei unterschieden werden, ob es sich um einen legaln Verbindungsaufbau meines eigenen Gerätes handelt oder um die genannte Attacke.
Auch bei einem legalen Verbindungsaufbau meines eigenen Gerätes, wird ein syn-ack als NEW nicht benötigt und deshalb kann man das blocken.
Auch bei einem legalen Verbindungsaufbau meines eigenen Gerätes, wird ein syn-ack als NEW nicht benötigt und deshalb kann man das blocken.
Wie geht das? Eine TCP/IP-Verbindung ohne syn/ack ...?... das kenne ich nicht.
eine Regel erstellen, die Pakete verwirft, die nicht aus dem Tunnel stammen.
Solche Pakete kommen ja nie aus dem Tunnel... würden sie das, wäre dem Angreifer ja der Sitzungsschlüssel bekannt. Ich denke, bei TCP/IP kriegt man das mit einem Filter -wie in dem von Dir genannten Link- hin. Bei UDP/IP, was ja stateless ist, geht das imho nur via Paket-Auth.... was aber auch bei TCP funktionieren würde.
iptables -I INPUT 1 -t security -i tun+ -p tcp --tcp-flags SYN,ACK SYN,ACK -d 10.4.0.0/8 -m state --state NEW,INVALID -j DROP
Was soll das bringen? Verstehe ich im Moment nicht. Aus dem Tunnel selber kann das ja nicht kommen, allenfalls geforwarded vom normalen Internface. Und da kann man das doch schon vorher töten. Aber wie gesagt, mit dem Statement auf dem regulären Interface wäre auch mit eigenen Geräten kein Verbindungsaufbau mehr möglich.... denn aller Anfang des VPNs via TCP/IP beginnt mit syn/ack.
Verstehe ich im Moment nicht.
Siehe das Szenario in: https://seclists.org/oss-sec/2019/q4/122
vom AP aus.
Ja, das habe ich verstanden... ich habe nur nicht das Regel-Beispiel verstanden. Ich denke, dass gehört in die Prerouting-Chain rein und behandelt sofort Pakete mit SADDR abweichend der eigenen und DADDR zum VPN-Lan. Allerdings weiss ich im Moment noch nicht, wie das genau zu unterscheiden ist, damit sich der Client nicht selber blockiert. Wenn ich Zeit habe, teste ich das morgen mal aus.
... ich habe nur nicht das Regel-Beispiel verstanden. Ich denke, dass gehört in die Prerouting-Chain rein und behandelt sofort Pakete mit SADDR abweichend der eigenen und DADDR zum VPN-Lan.
Das verstehe ich nicht. Es spielt hier keine Rolle ob ich es in der INPUT chain oder in der PREROUTING chain blocke. Es geht ja um das eigene Gerät (Host) und nicht um etwas das durch die FORWARD chain muss.
Es geht ja um das eigene Gerät (Host) und nicht um etwas das durch die FORWARD chain muss.
Das habe ich zunächst mal anders verstanden. Die Zieladresse (DADDR) des Paketes liegt ja im VPN-LAN, nicht im AP-LAN, und somit in einem anderen Netzwerk als das, in dem das reguläre NIC arbeitet. Ich weiss im Moment auch nicht, wie sich das lokale Client-Openvpn verhält, weil es ja gar nicht auf einen einem Port lauscht. Gleichermaßen könnte der Angreifer sich selber auch eine IP aus dem VPN-Netz gegeben haben und einfach alle Adressen durchprobieren, bis vielleicht der Server gefunden wurde und auch antwortet.
Im Moment denke ich immer noch, dass gehört nach Prerouting oder gar Mangle... ich bin ja neugierig... vielleicht schaff ichs, das morgen mal zu testen.
Im Moment denke ich immer noch, dass gehört nach Prerouting oder gar Mangle... ich bin ja neugierig... vielleicht schaff ichs, das morgen mal zu testen.
Es ist kein Unterschied ob in der PREROUTING oder in der INPUT chain. Die Routing-Entscheidung wird nach der PREROUTING chain getroffen. D. h. von dort geht es entweder in die FORWARD chain (... nicht zum Opfer) oder in die INPUT chain (... zum Opfer).
mangle ist eine table bzw. keine chain und wird in iptables verwendet, um Datenpakete auf unterschiedlicher Art und Weise zu verändern.
Es ist ja beschrieben wie der Angreifer an die Datenpakete kommen kann:
ZitatAlles anzeigenThere are 4 components to the reproduction:
1. The Victim Device (connected to AP, 192.168.12.x, 10.8.0.8)
2. AP (controlled by attacker, 192.168.12.1)
3. VPN Server (not controlled by attacker, 10.8.0.1)
4. A Web Server (not controlled by the attacker, public IP in a real-
world scenario)
The victim device connects to the access point, which for most of our
testing was a laptop running create_ap. The victim device then
establishes a connection with their VPN provider.
The access point can then determine the virtual IP of the victim by
sending SYN-ACK packets to the victim device across the entire virtual
IP space (the default for OpenVPN is 10.8.0.0/24). When a SYN-ACK is
sent to the correct virtual IP on the victim device, the device
responds with a RST; when the SYN-ACK is sent to the incorrect virtual
IP, nothing is received by the attacker.
Quelle: https://seclists.org/oss-sec/2019/q4/122
EDIT:
Ich habe es bei mir im (W)LAN getestet und das funktioniert, zwar nicht mit rst, dafür aber mit icmp:
:~ # nping --tcp --flags SA --source-ip 192.168.178.40 --dest-ip 10.4.0.6 --rate 3 -c 3 -e ue0 --dest-mac 48:02:2a:17:62:b4
Starting Nping 0.7.70 ( https://nmap.org/nping ) at 2019-12-07 01:08 CET
SENT (0.0382s) TCP 192.168.178.40:17182 > 10.4.0.6:80 SA ttl=64 id=34225 iplen=40 seq=3199300433 win=1480
RCVD (0.0572s) ICMP [10.4.0.6 > 192.168.178.40 Port 80 unreachable (type=3/code=3) ] IP [ttl=64 id=21925 iplen=68 ]
SENT (0.3900s) TCP 192.168.178.40:17182 > 10.4.0.6:80 SA ttl=64 id=34225 iplen=40 seq=3199300433 win=1480
RCVD (0.3938s) ICMP [10.4.0.6 > 192.168.178.40 Port 80 unreachable (type=3/code=3) ] IP [ttl=64 id=22012 iplen=68 ]
SENT (0.7441s) TCP 192.168.178.40:17182 > 10.4.0.6:80 SA ttl=64 id=34225 iplen=40 seq=3199300433 win=1480
RCVD (0.7482s) ICMP [10.4.0.6 > 192.168.178.40 Port 80 unreachable (type=3/code=3) ] IP [ttl=64 id=22069 iplen=68 ]
Max rtt: 18.877ms | Min rtt: 3.291ms | Avg rtt: 8.738ms
Raw packets sent: 3 (162B) | Rcvd: 3 (204B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 0.75 seconds
Alles anzeigen
:~ # nping --tcp --flags SA --source-ip 192.168.178.40 --dest-ip 10.4.0.5 --rate 3 -c 3 -e ue0 --dest-mac 48:02:2a:17:62:b4
Starting Nping 0.7.70 ( https://nmap.org/nping ) at 2019-12-07 01:09 CET
SENT (0.0376s) TCP 192.168.178.40:28322 > 10.4.0.5:80 SA ttl=64 id=41258 iplen=40 seq=1584540921 win=1480
SENT (0.3905s) TCP 192.168.178.40:28322 > 10.4.0.5:80 SA ttl=64 id=41258 iplen=40 seq=1584540921 win=1480
SENT (0.7349s) TCP 192.168.178.40:28322 > 10.4.0.5:80 SA ttl=64 id=41258 iplen=40 seq=1584540921 win=1480
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (162B) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Nping done: 1 IP address pinged in 1.78 seconds
mangle ist eine table bzw. keine chain und wird in iptables verwendet, um Datenpakete auf unterschiedlicher Art und Weise zu verändern.
Das war eine überflüssige Belehrung, die auch nicht im Geringsten weiterhilft. Mit meinem Hinweis wollte ich klar machen, dass ich die Input-Chain für den falschen Ort halte und stattdessen eine Prerouting-Chain für die richtige erachte ... dabei ist es egal, ob das in der Tabelle nat oder mangle passiert. Sogar die Tabelle raw (also noch vorher) halte ich für angemessen (was ich aber nicht getestet habe). Außerdem ist das sowieso eine obsolete Sichtweise, dieses imho beschränkende Tabellendenken gibts bei nftables nicht mehr.
Du gehst davon aus, dass das Opfer der VPN-Client ist. Ich gehe hingegen von einem worst-case-Szenario aus (was ich aber nicht technisch belegen kann), und zwar das sich der Angreifer (nach dem er das VPN-Netz ermittelt hat) selber eine IP aus dem VPN-Netz vergibt und dass dann von dort ggf. auch Pakete zum VPN-Server geroutet werden ... ich weiss das schlichtweg nicht... aber wenn das möglich wäre, befürchte ich, dass das von der Input-Chain nicht beachtet wird und das Paket schlichtweg geforwarded wird. Ich wiederhole mich, ich weiss es nicht, ob es so ist, dass Traffic anderer Clients mit dem Ziel wieder andere Hosts trotzdem immer den lokalen Prozess als Ziel hat oder ob das auf dem verbundenen VPN-Client einfach nur geroutet wird.
Aber weil ich das nicht weiss, ist 'prerouting' imho besser geeignet, weil es beide Fälle beachtet, somit in jedem Fall erfolgreich ist und alle Zweifel beseitigt. Und das unabhängig davon, ob meine Befürchtung zutrifft oder nicht. Außerdem ist das keine Religion, welche Tabelle man für was verwenden darf oder auch nicht. Hier zählt nur eins: Wirksamkeit! Mit anderen Worten, ist es wirksam, war es richtig.
Ich teile diese Aussage:
https://seclists.org/oss-sec/2019/q4/123
"* You can solve the problem generally for IPv6 by using the rpfilter iptables or nftables module in *mangle PREROUTING[1]."
table ip filter {
chain prerouting {
type nat hook prerouting priority -100; policy accept;
ip protocol tcp ct state new ip daddr 10.4.0.0/24 drop
}
}
Und es bleibt das Fazit, dass TCP hier an der Stelle eh nur eine Not-Lösung sein sollte und das man besser UDP verwendet.... da gibts beim Verbindungsaufbau erst gar keine Syn-Flag-Kommunikation.
BTW, ist das gewollt, dass in Deinem Beispiel 2 verschiedene --dest-ip verwendet werden, und zwar 10.4.0.5 und 10.4.0.6? Wenn das die Ursache für unterschiedliche Ergebnisse ist, ist das aber ohne ergänzende Erklärung wenig ausssagefähig.
Das war eine überflüssige Belehrung, ...
Du gehst davon aus, dass das Opfer der VPN-Client ist. Ich gehe hingegen von einem worst-case-Szenario aus (was ich aber nicht technisch belegen kann), und zwar das sich der Angreifer (nach dem er das VPN-Netz ermittelt hat) selber eine IP aus dem VPN-Netz vergibt und dass dann von dort ggf. auch Pakete zum VPN-Server geroutet werden ... ich weiss das schlichtweg nicht... aber wenn das möglich wäre, befürchte ich, dass das von der Input-Chain nicht beachtet wird und das Paket schlichtweg geforwarded wird. Ich wiederhole mich, ich weiss es nicht, ob es so ist, dass Traffic anderer Clients mit dem Ziel wieder andere Hosts trotzdem immer den lokalen Prozess als Ziel hat oder ob das auf dem verbundenen VPN-Client einfach nur geroutet wird.
Und es bleibt das Fazit, dass TCP hier an der Stelle eh nur eine Not-Lösung sein sollte und das man besser UDP verwendet.... da gibts beim Verbindungsaufbau erst gar keine Syn-Flag-Kommunikation.
Das war keine Belehrung, sondern nur ein Hinweis. Und ich habe doch geschrieben, dass man es in der INPUT chain und/oder in der PREROUTING chain blocken/ignorieren kann. Aber das ist unwesentlich.
Das Opfer kann der VPN-Client oder auch der VPN-Server im LAN des AP/Router sein. Der Angreifer muss keine IP-Adresse aus dem VPN-Zwischennetz haben. Er kommt via LAN-Interface (MAC-Adresse) an die IP-Adresse des tunx-Interfaces vom VPN-Client/-Server (Opfer). Z. B.:
nping --tcp --flags SA --source-ip 192.168.178.40 --dest-ip 10.4.0.6 --rate 3 -c 3 -e ue0 --dest-mac 48:02:2a:17:62:b4
192.168.178.40 ist die IP-Adresse des Angreifers im LAN des AP/Router, ue0 ist das Interface des Angreifers im LAN des AP/Router, 10.4.0.6 ist die IP-Adresse vom tunx-Interface (Zwischennetz) des Opfers und 48:02:2a:17:62:b4 ist die MAC-Adresse im LAN des AP/Router vom Opfer.
BTW: Benutzt Du im Zwischennetz nur UDP bzw. ist TCP bei dir im Zwischennetz blockiert? Es geht nicht um die UDP-Verbindung zwischen VPN-Client und VPN-Server, sondern um das Zwischennetz.
..., sondern nur ein Hinweis.
Zitat
Das verstehe ich auch nicht.... "er kommt"... in dem Beispiel ist doch die VPN-IP-Adresse schon vorgegeben... also muss er doch gar nicht "dran kommen"... hier ist sie doch bekannt. Eigentlich kennt er doch nur die IP des NICs, das mit dem AP verbunden ist, die VPN-IP steht doch da gar nicht drin.
Benutzt Du im Zwischennetz nur UDP bzw. ist TCP bei dir im Zwischennetz blockiert?
Damit kann ich jetzt gar nix anfangen. Was ist denn ein Zwischennetz?
Das habe ich doch nur zur Vereinfachung schon so geschrieben (... d. h. die bekannte IP-Adresse aus dem Zwischennetz). Der Angreifer wird hier ganze Subnetze (z. B. 10.8.0.0/8 oder gleichwertig) scannen/probieren um die IP-Adresse zu ermitteln:
ZitatThe access point can then determine the virtual IP of the victim by
sending SYN-ACK packets to the victim device across the entire virtual
IP space (the default for OpenVPN is 10.8.0.0/24).
Der Angreifer kennt nicht nur die IP-Adresse der NIC die mit dem AP/Router verbunden ist, sondern auch die zugehörige MAC-Adresse (z. b. mit Hilfe eines arp-scan oder gleichwertig).
EDIT:
Ja, aber das alles hat wenig bis gar nichts mit OpenVPN oder einem VPN an sich zu tun, sondern ist schlichtweg das Ausnutzen eines mangelhaft konfigurierten Systems, auf dem ein VPN-Client betrieben wird. Gleich der erste Expand-Punkt in Deinem Link "No flaws found in OpenVPN-Software" erklärt alles, was man zu diesem Exploit wissen muss. Mit anderen Worten, was man daraus freimütig ableiten kann: tippst 'Du' einfach nur 'ne Config aus dem Web ab oder machst Copy&Paste, haste keine Garantie über Sicherheit. So einfach ist das.
Die einzige Unsicherheit, die ich jetzt noch habe, resultiert aus der Frage: "Welchen Vorteil hat 'reverse path filter’ im Vergleich zu meiner radikalen Methode, alles CT-State New mit Ziel VPN-LAN zu verwerfen?" Ich habe diese 'Funktion' noch nicht so richtig verstanden, was genau da ablaufen und passieren muss, dass eine solche Regel matcht.
Fakt ist, 'wir' befinden uns ja alle im gleichen AP-LAN, also sowohl mein Road-Warrior-Laptop als auch der Rechner des Angreifers. Angenommen der verwendet ne Spoof-IP aus meinem VPN-LAN, und angenommen, ich bin gleichzeitig auch noch mit meinem Smartphone im VPN verbunden, dann gibts am Ort des AP im LAN des AP gleichzeitig 3 Geräte mit VPN-IPs.... woran erkennt man, dass die gespoofte IP des Angreifers nicht routable ist, wir hängen doch alle am gleichen Router?
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!