Tag Archives: VPN

CVE-2020-8597: Pre-Auth RCE in PPP

Posted on by

Ist Euch mal aufgefallen, daß über eine der dicksten Sicherheitslücken in 2020 so gut wie kein Wort verloren wird?

CVE-2020-8597: Pre-Auth RCE in PPP

Im Point-To-Point-Dienst wurde eine Lücke entdeckt, die es erlaubt Code auszuführen, noch bevor man sich autorisieren muß. Die Brisanz an der Sache ist, daß nicht nur die Server betroffen sind, sondern auch die Clienten. Eingesetzt wird das u.a. bei VPN Systemen.

Was mich an der Sache ein bisschen ärgert ist, daß seit 2 Wochen das Update vom ppp bei Fedora im Bodhi hängt, weil mal wieder keiner zum Testen Zeit & Lust hatte, was mir sehr bekannt vorkommt. Davon mal abgesehen, wurde der aktuelle Chef vom Fedoraprojekt direkt nach entdecken der Lücke über die Brisanz, den Entdecker und die verifizierende Quelle informiert, keine 8 Stunden nach den ersten Gerüchten. Ich weiß das, weil ich das gemacht habe, mit dem Hinweis es an die Security von RH, PPP etc. zu  eskalieren.

Damit mußte eigentlich allen Beteiligten klar sein, daß es sich um ein Critupdate handelt. Kritisch ist das nämlich, weil viele VPN Techniken, außer SSH, auf den ppp setzen und damit eine echt große Angriffsfläche gegeben ist. Die Lücke ist so krass, daß die sogar osübergreifend existiert. Das erlebt man ja auch nicht jeden Tag.

Der, sagen wir mal schweigsame, Umgang mit der Lücke, auch in den Medien führt übrigens dazu, daß Kunden diverser Produkte die den ppp kommerziell einsetzen nicht mal wissen, daß es diese Lücke gibt, was dazu führt, daß es keinen Druck bei den Herstellern gibt. Ich befürchte sogar fast, daß die nicht mal wissen, das es die Lücke gibt, weil das erst heute, 2 Wochen nach bekanntwerden,  über FullDisclosure gelaufen ist und somit auch erst jetzt die Runde macht.

Pro-Linux.de ist übrigens eine der wenigen Seiten in Deutschland, die überhaupt über diesen Bug berichtet haben, aber auch mehr, weil es ein automatisches Advisory von Debian gab und weniger, weil daß jemandem aufgefallen ist. Für eine Pre-Auth RCE mit Eskalation zu Root ist das alles eine sehr seltsame Sache. The Hacker News hat vor 2 Tagen darüber berichtet, aber das wars dann schon. Golem oder Heise vermisst man mal wieder, dabei wäre das ein gefundenes Fressen für die Medien, weil es Millionen betroffener Clients und Server gibt.

Wenn Android hustet, …

…, wo niemand genau weiß, ob jemand wirklich davon betroffen ist, da raschelt es gleich im Blätterwald, aber wenn die Sicherheit von Millionen Hosts in Gefahr ist, dann bleibt alles ruhig?

Dem einen oder anderen stellt sich jetzt vermutlich die Frage, wieso habe ich das nicht gleich im Blog gepostet als ich davon erfuhr? Ich wollte meiner Distro einen kleinen Vorsprung geben, damit der Patch ausgerollt wird, bevor die Masse der Blackhats das mitbekommt. Nachdem Fefe das in seinem Blog rausgehauen hatte, konnte man zu dem annehmen, daß es im Blätterwald sehr schnell die Runde machen würde, was ja dann überraschenderweise nicht passiert ist.

Ihr merkt, bei dieser Lücke ist einiges anders als sonst. Ich frage mir nur gerade, was eigentlich die Lektion ist, die wir daraus lernen sollten: „trotz wager Infos die Posaune rausholen und sofort berichten“ oder „doch abwarten bis es mehr Infos gibt und so riskieren, daß keiner was meldet“? Ich muß gestehen, da bin ich auch überfragt. So etwas wie beim ppp darf sich jedenfalls nicht wiederholen.

Linux – Cannot find device „tun0“

Posted on by

Ihr wollt z.B. mit SSH ein VPN und dazu einen Tunnel aufbauen, könnt aber nicht, weil Ihr diese Fehlermeldung bekommt: Cannot find device „tun0“ ? Ja, na dann auf ins neue Netstackventure!

Tunneldevice mit Linux nutzen

Ihr erinnert Euch noch an den Artikel: SSH VPN mit den iproute2 Tools ? Da haben wir ein SSH VPN aus dem Hut gezaubert und mußten dazu mit Tunneln arbeiten. Da hat sich einiges getan, deswegen müssen wir uns leider erneut damit befassen.

Schritt 1 und 2 sind klar, ein TUN Modul laden und Device erzeugen, aber was ist das…?? :

[root@backup ~]# modprobe tun
[root@backup ~]# ip link set tun0 up;
Cannot find device "tun0"

„Cannot find device „tun0““ ist ein echter Kopfschmerzenerzeuger, weil so unnötig. Also das Modul „tun“ ist wie der Name nahelegt, für Tunneldevices zuständig. Es sollte eigentlich ein Tunneldevice tun0 erzeugen, tuts aber nicht und mit normalen Fedora Bordmitteln ist das auch nicht so einfach machbar.

Ihr braucht das Paket „tunctl“ ( dnf install tunctl ) und müßt Euch erstmal ein tundevice bauen:

tunctl -t tun0

Wie man sieht, ist das nicht schwer. Jetzt, wo das Gerät persistent gemacht wurde, seht Ihr an der Ausgabe von dem Befehl oben, klappt das dann auch mit dem „ip link set tun0 up“ und Ihr könnt der Anleitung aus SSH VPN mit den iproute2 Tools weiter folgen. Ihr müßt nur dran denken, daß Ihr das auch bei Euch auf dem Client PC macht und nicht nur auf dem Server.

Eine Bewertung, wieso das nicht mehr defaultmäßig bei Fedora dabei ist, verkneif ich mir, es wird merkwürdige Gründe haben 🙂

SSH VPN mit den iproute2 Tools

Posted on by

Vor einiger Zeit habe ich gezeigt, wie man ein SSH VPN erstellt. Heute gibt es nun die verbesserte Version, die auch iproute2 Tools benutzt, die ifconfig & Co. abgelöst haben.

Es gelten die gleichen Regeln wie für den alten Beitrag. Als kleine Abweichung nutzen wir diesmal das tun0 Interface, aber das ist reine Kosmetik.

Vorbereitungen

Auf dem VPN Server muß der SSH Tunnel erlaubt sein. Dazu tragen wir „PermitTunnel yes“ in /etc/ssh/sshd_config ein und starten den sshd neu.

Auf dem Clienten

Als erstes öffnen wir den Tunnelverbinder und wie man an den neuen Optionen sehen kann, brauchen wir kein Sleep mehr, denn das macht SSH jetzt für uns von ganz alleine :

ssh -NTCf -w 0:0 root@2te.vpn.server.ip

auf dem VPN Server

 ip link set tun0 up;
 ip addr add 10.0.1.1/32 peer 10.0.1.2 dev tun0;
 echo 1 > /proc/sys/net/ipv4/ip_forward ;iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;

Da der SSH Befehl im Hintergrund anbleibt, können wir auf das Sleep verzichten und direkt zum Clienten wechseln.

Auf dem Clienten

ip link set tun0 up;
ip addr add 10.0.1.2/32 peer 10.0.1.1 dev tun0;
route add 2te.vpn.server.ip gw alte.gw.ip;
route del default gw alte.gw.ip;
route add default gw 10.0.1.1 dev tun0;

Das wars schon wieder, sofern Ihr keine Fehlermeldung bekommen habt. Wichtig ist die Reihenfolge der Aktionen, also daß SSH zuerst gestartet wird, damit das Tunnelinterface auf der Serverseite vorbereitet werden kann. Wenn man nach SSH z.b. „ip link delete tun0“ eingibt, war alles umsonst und es wird nicht funktionieren.

Update:

Falls ihr ein „Cannot find device „tun0““ bekommt, dann führt mal mit Rootrechten “ tunctl -t tun0 -n “ aus.