Die Sicherheitsforscherin Erica Windisch von Cyberdione Labs hat Schwachstellen in Tailscale SSH gemeldet. In Labortests konnte ein Angreifer, der ein Gerät kontrolliert, damit Root-Zugriff auf andere erreichbare Server erlangen. Der Angriff setzte voraus, dass SSH-Portweiterleitung erlaubt ist und Netzwerkzugriffsregeln dem kompromittierten Gerät die Verbindung zu seinen Zielen gestatten.
Windisch veröffentlichte die Ergebnisse am 25. Oktober in einem Bericht mit dem Titel Tailworm. Vorausgegangen waren drei Tage Tests mit Tailscale 1.104.2 und headscale 0.29.5, einer selbst gehosteten Alternative zum gehosteten Kontrolldienst von Tailscale. Die Ergebnisse beschreiben Angriffe im Labor; eine Ausnutzung realer Netzwerke wurde nicht gemeldet.
Laut The Hacker News hatte Tailscale zum Zeitpunkt der Veröffentlichung weder eine Sicherheitsmitteilung noch eine CVE-Kennung oder eine korrigierte Version für diese Befunde veröffentlicht. Kein anderer Forscher hatte sie öffentlich reproduziert, und Tailscale hatte die konkreten technischen Behauptungen nicht bestätigt.
Mike Shaver, Vice President of Engineering bei Tailscale, erklärte auf Reddit, das Unternehmen habe den Bericht erhalten und untersuche dieselben Bereiche bereits gemeinsam mit externen Sicherheitsspezialisten. Man habe Probleme identifiziert, an deren Behebung gearbeitet werde. Noch werde ermittelt, welche Konfigurationen betroffen seien. Das Unternehmen empfehle ausdrücklich nicht, dass alle Tailscale SSH deaktivieren, wie Shaver sagte.
Wie die gemeldeten SSH-Angriffe funktionierten
Tailscale SSH nutzt Geräteidentität und Zugriffsregeln, um Verbindungen zu autorisieren, statt ein herkömmliches SSH-Passwort oder einen Schlüssel zu verlangen. Die gemeldeten Angriffe setzten daher keine gestohlenen SSH-Zugangsdaten voraus, wohl aber einen bestehenden Zugriff auf ein autorisiertes Gerät. Die Ergebnisse zeigen nicht, wie dieser initiale Zugriff zu erlangen ist.
Bei einem Test bewirkte laut Windisch eine gewöhnliche SSH-Portweiterleitung, dass der Tailscale-Prozess mit Root-Rechten einen nur für root zugänglichen Systemsocket ansprach. Dadurch erhielt der Test Root-Zugriff und konnte die Systempasswortdatei lesen, ohne dass der verbindende Benutzer Administratorrechte besaß.
Eine zweite Methode soll einen vom Angreifer kontrollierten Socket an die Stelle eines root-eigenen Sockets gesetzt haben. Dadurch ließen sich über bestimmte Dienste Befehle mit Root-Rechten ausführen. Eine dritte Methode nutzte eine Race Condition zwischen einer Sicherheitsprüfung des Dateipfads und der späteren Verwendung dieses Pfads aus. So umging sie die Beschränkungen, auf welche Dateien die Weiterleitung zugreifen darf.
Die dritte Angriffskette erbeutete außerdem einen Schlüssel zur Geräteregistrierung und nutzte ihn, um einen vom Angreifer kontrollierten Rechner als vertrauenswürdigen Server ins Netzwerk aufzunehmen. Diese Sequenz gelang nur, wo Tailnet Lock deaktiviert war. Bei aktiviertem Tailnet Lock wurden laut Bericht die nötigen Geheimnisse auf dem Übertragungsweg abgegriffen, der letzte Registrierungsschritt wurde jedoch nicht abgeschlossen.
Windisch bezeichnete das Gesamtergebnis als „wurmfähig“. Eine Kompromittierung könne sich über Geräte ausbreiten, die Zugriffsregeln erlauben, und zwar in unter einer Sekunde pro Schritt, ohne Passwörter, gestohlene Schlüssel oder Benutzerinteraktion. Diese Geschwindigkeit und Ausbreitung wurden im Labor demonstriert. Einige Forscher stellten die Einstufung als wurmfähig öffentlich infrage, andere bezeichneten den Root-Zugriff als ernstes Problem.
Die Konfiguration bestimmt das Risiko
Der Bericht nennt Zugriffsregeln, die einzelne Quell-Ziel-Gerätepaare festlegen, als Kontrolle, die im Test die Ausbreitung stoppte. Hardware-gebundene Geräteschlüssel, etwa solche, die an ein TPM oder einen Secure Enclave gebunden sind, schränkten die Angriffe ebenfalls ein.
Die Weiterleitungskontrollen unterscheiden sich je nach Bereitstellung. Beim gehosteten Dienst von Tailscale lässt sich die SSH-Portweiterleitung pro Regel deaktivieren. Laut Bericht kann headscale 0.29.5 sie nicht deaktivieren. Windisch argumentierte deshalb, SSH-Freigaben auf dieser Version sollten so behandelt werden, als gewährten sie Root-Zugriff auf die Ziele.
Die SSH-Angriffe sind Teil von elf Befunden zu Tailscale-Funktionen und headscale. Windisch meldete außerdem, dass das experimentelle App-Connector-Feature conn25 einem berechtigten Benutzer ermöglichen könne, Ziele zu erreichen, die Administratoren nicht freigegeben hatten. Dazu gehöre auch ein Cloud-Metadatendienst, der Server-Zugangsdaten liefern kann. Dies bleibt eine Behauptung der Forscherin und ist kein Beleg für Zugangsdaten, die aus einer Produktionsumgebung gestohlen wurden.
Zu den im Bericht genannten Maßnahmen gehören das Einschränken der SSH-Berechtigungen, das Deaktivieren der Weiterleitung, wo unterstützt, das Entfernen unnötiger App-Connector-Berechtigungen und das Entfernen von Weiterleitungen per tailscale serve zu Unix-Sockets. Ein Ablaufdatum für Node-Schlüssel begrenzt die Gültigkeit gestohlener Schlüssel. Wird ein kompromittiertes Gerät auf der Kontrollebene gelöscht, entfällt der Zugriff, den ein bloßes Neuaufsetzen möglicherweise bestehen lässt.
Tailscale empfiehlt außerdem den SSH-Check-Modus, der vor jeder Sitzung einen zusätzlichen Anmeldeschritt hinzufügt, sowie automatische Updates. Der Check-Modus errichtet eine zusätzliche Zugriffshürde, behebt aber nicht die gemeldete Rechteausweitung.
Windisch sagte, der Proof-of-Concept-Code sei ausschließlich an den Sicherheitskontakt von Tailscale weitergegeben worden. Sie bezeichnete die Offenlegung zwar als „gemeldet, aber nicht koordiniert“. Gegenüber The Hacker News erklärte sie jedoch, sie habe dem Unternehmen vor der Veröffentlichung sowohl den Bericht als auch den Code geschickt.
