Neue VPN Schwachstelle - Nix ist sicher (ausser den Renten natürlich)

  • 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.

    Spoiler anzeigen
    Code
    :~$ 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
    Code
    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).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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.

  • 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.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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.

  • Wie geht das?

    Z. B. mit:

    Code
    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)

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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:

    Spoiler anzeigen

    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:

    Spoiler anzeigen
    Code
    :~ # 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

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    3 Mal editiert, zuletzt von rpi444 (7. Dezember 2019 um 09:52)

  • 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]."

    Code
    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.

    2 Mal editiert, zuletzt von WinterUnit16246 (7. Dezember 2019 um 12:22)

  • 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.:

    Code
    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.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • ..., sondern nur ein Hinweis.

    ;)


    Zitat

    Er kommt via LAN-Interface (MAC-Adresse) an die IP-Adresse des tunx-Interfaces vom VPN-Client/-Server (Opfer). Z. B.:

    Code
    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

    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 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.

    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:

    Zitat

    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).

    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:

    https://openvpn.net/security-advisories/

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    3 Mal editiert, zuletzt von rpi444 (7. Dezember 2019 um 14:00)

  • 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).

    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?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!