Einer der bekanntesten VPN Dienstleister, Mullvad, hat sich kürzlich einem Audit unterzogen: Wir schauen uns die Ergebnisse genauer an.
Mullvad, für viele die Empfehlung, wenn es um VPN-Anbieter geht, hat heute die Ergebnisse eines externen Audits durch die niederländische Firma Radically Open Security veröffentlicht. Wir schauen uns den Bericht näher an und entlarven fragwürdiges Marketing.
Zwei VPN-Server wurden untersucht
Mullvad hat im Rahmen des Audits Mitte Mai (Bericht und Blog widersprechen sich hier, der Blog spricht von Mitte Juni) zwei ihrer Server – einen mit OpenVPN und einen mit Wireguard – untersuchen lassen und den Abschlussbericht auf seinem Blog veröffentlicht. Eine Verifikation wurde im Juli durchgeführt.
Die Pentester erhielten vollständigen SSH-Zugriff auf die Server, auf denen ein abgespeckter 6.3.2 Linux Kernel in der Geschmacksrichtung Ubuntu läuft. Das Setup war laut Mullvad identisch zu Produktivsystemen, die Server wurden allerdings nie als solche eingesetzt. Aufgabe der Pentester war, die interne und externe Sicherheit der Systeme zu testen und zu prüfen, ob und wie viel Mullvad loggt. Weder der Quellcode der Binaries, noch die Hardware, wurde einem angebotenen Test unterzogen.
Mullvad hatte 25 „Probleme“
Wichtig ist zuerst einmal, dass ein „Issue“ in einem Pentest-Bericht nicht notwendigerweise ein tatsächliches Problem für die Sicherheit darstellen muss. Die Probleme können ggf. durch externe Systeme oder Policies entschärft werden.
Gleich das erste Problem, Dringlichkeit: „Hoch“, straft hier Mullvad Lügen. Die Tester fanden, dass das System Produktivtraffic von Kunden als Hop in einem Multihop-Setup verarbeitete. Dadurch war der Traffic der User für die Pentester sichtbar und wurde – zumindest teilweise – im Rahmen der Beweisaufnahme mitgeschrieben. Dies kam dadurch zustande, dass die Systeme in der API von Mullvad als Hops gelistet waren.
Auch beachtlich ist, dass Nutzer mit Root-Zugriff auf den Servern über Änderungen der IPMI Konfiguration (Remote Management und Monitoring Interface) oder der Firmware persistente Backdoors in die Systeme einbauen könnten, dies wäre über z. B. Secureboot und die Abschaltung von IPMI mitigiert werden. Die Umsetzung dieser Änderungen kann aber länger dauern, da man natürlich keine Downtimes riskieren will.
Fokuspunkt: root werden
Viele der untersuchten Punkte bezogen sich auf Privilege Escalation, da ein Angreifer so möglicherweise persistenten Zugriff auf ein System erhalten konnte. Und hier hat Mullvad wieder ein paar Plus-Punkte sammeln können.
Privilege Escalation war u. a. durch fehlerhafte Berechtigungen auf systemd Timern möglich und die meisten dieser Probleme hat Mullvad bereits gefixt.
Ein bemängelter Punkt war auch, dass ein SSH-Login auf die Systeme überhaupt möglich war, da so z. B. Mitarbeiter Traffic mitschneiden könnten, was natürlich eher weniger im Interesse der Kunden wäre.
Netzwerk-Debug Tools kamen direkt vorinstalliert. Auf den Servern waren tcpdump, nmap, und netcat direkt verfügbar. Was den Testern etwas Arbeit abnahm, aber dennoch nicht sein müsste. Besonders eine Kombination von tcpdump und pastebinit könnte genutzt werden, um bei Systemzugriff Nutzer-Traffic direkt weiterzuschicken.
Mullvad loggt nicht… zumindest keinen DNS und Proxy Traffic
Die Tester untersuchten auch, ob und was auf den Systemen geloggt wird. Das Ergebnis: danted (ein Proxy) und bind (DNS-Server) loggen nicht. Auffällig ist hier die fehlende Erwähnung von OpenDNS und Wireguard.
Ein akuter Fall von Marketing Woo-Woo
Zusammenfassend lässt sich sagen, dass die Liste bei Mullvad noch verhältnismäßig kurz ist und die Verteilung von Problemen sich doch eher in Maßen hält. Listen mit Hunderten von Issues sind gängige Praxis, da Pentester mit Systemzugriff eine Menge Schabernack treiben können. Dennoch ist die Darstellung in Mullvads Blog zumindest von fraglicher Genauigkeit.
Und jetzt für alle Sysadmins die noch keinen Herzinfarkt hatten:
%mad ALL=(ALL:ALL) NOPASSWD: ALLDas heißt, alle Mitglieder der mad Gruppe können alle Administratorbefehle ohne Passworteingabe ausführen. Da schüttelt’s mich schon etwas. Hoffentlich haben wenigstens die SSH-Keys ein Passwort.
