Schwachstellen in Tailscale SSH könnten über Netzwerke hinweg root access ermöglichen
Von einem Forscher der Cyberdione Labs dokumentierte Schwachstellen in Tailscale SSH könnten es einem Angreifer, der ein Gerät kontrolliert, ermöglichen, auf anderen zulässigen Servern root access zu erlangen, also die höchste Stufe der Systemkontrolle. Der Angriff setzt voraus, dass Tailscale SSH, eine auf Secure Shell basierende Funktion für die Fernanmeldung, port forwarding erlaubt, wodurch eine Verbindung Datenverkehr an ein anderes lokales oder entferntes Ziel übertragen kann. Das kompromittierte Gerät muss außerdem durch die Zugriffsregeln des Netzwerks autorisiert sein, eine Verbindung zu seinem Ziel herzustellen.
Die Erkenntnisse erschienen am 25. Oktober in einem Bericht mit dem Titel Tailworm. Der Forscher testete Tailscale 1.104.2 und headscale 0.29.5, einen selbst gehosteten Server, den einige Organisationen anstelle des gehosteten Dienstes von Tailscale verwenden. Die Tests fanden über drei Tage in einem Labor statt. Der Bericht beschreibt keine Angriffe, die in Produktivnetzwerken beobachtet wurden, und kein anderer Forscher hat die Ergebnisse öffentlich reproduziert. Zum Zeitpunkt der Veröffentlichung gab es weder ein Security Bulletin noch einen CVE identifier oder eine korrigierte Version, und Tailscale hatte die einzelnen technischen Behauptungen nicht bestätigt.
Tailscale erklärte öffentlich, das Unternehmen habe den Bericht erhalten und untersuche dieselben Bereiche bereits gemeinsam mit externen Sicherheitsspezialisten. Der Vice President of Engineering des Unternehmens sagte, man habe Probleme identifiziert, an deren Behebung gearbeitet werde, ermittle jedoch noch, welche Konfigurationen betroffen seien. Das Unternehmen riet nicht allen Kunden dazu, Tailscale SSH zu deaktivieren.
Das Risiko ergibt sich daraus, wie Tailscale SSH Sitzungen autorisiert. Ein herkömmlicher SSH-Server überprüft normalerweise das Passwort oder den kryptografischen Schlüssel eines Benutzers. Tailscale SSH identifiziert stattdessen das Gerät, das die Verbindung herstellt, und entscheidet anhand einer Zugriffsregel, ob dieses Gerät eine SSH-Sitzung starten darf. Der gemeldete Angriff erfordert daher nicht, dass der Angreifer ein SSH-Passwort oder einen Schlüssel stiehlt. Er setzt weiterhin eine anfängliche Kompromittierung voraus, die dem Bericht zufolge über eine anfällige Webanwendung, ein bösartiges Softwarepaket, Phishing oder gestohlene Anmeldedaten erfolgen könnte. Tailscale selbst verschafft diesen ersten Zugang nicht.
Im ersten Labortest führte standardmäßiges SSH port forwarding dazu, dass der mit root-Berechtigungen ausgeführte Tailscale-Prozess eine Verbindung zu einem System-Socket herstellte. Ein Socket ist ein lokaler Kommunikationskanal, den Software verwendet, und dieser spezielle Socket hätte nur für root zugänglich sein dürfen. Die Sitzung erlangte root access und las die Systempasswortdatei ohne Administratorrechte. Bei einer anderen Methode ersetzte der Forscher einen root gehörenden Socket durch einen vom Angreifer kontrollierten Socket, wodurch direkte root-Befehle gegen bestimmte Dienste möglich wurden.
Eine dritte Technik nutzte eine zeitliche Lücke zwischen der Überprüfung eines Dateipfads und seiner Verwendung aus. Indem das Ziel während dieses kurzen Zeitraums geändert wurde, umging der Test eine Schutzmaßnahme, die einschränken sollte, auf welche Dateien das Forwarding zugreifen konnte. Die daraus resultierende Angriffskette erfasste einen Schlüssel zur Geräteregistrierung und verwendete ihn, um dem Netzwerk eine vom Angreifer kontrollierte Maschine als vertrauenswürdigen Server hinzuzufügen. Diese vollständige Angriffskette funktionierte nur, wenn Tailnet Lock nicht aktiviert war. Bei aktivem Tailnet Lock wurden die Secrets während der Übertragung zwischen Systemen erfasst, der abschließende Registrierungsschritt wurde jedoch nicht abgeschlossen.
Der Forscher bezeichnete die Angriffskette als wormable, da sich ein kompromittiertes Gerät zu jedem anderen durch die Zugriffsregeln erlaubten Gerät bewegen könnte, ohne weitere Passwörter, gestohlene SSH keys oder Benutzerinteraktion zu benötigen. Im Labor dauerte jeder Schritt weniger als eine Sekunde. Einige Forscher, die den Bericht überprüft haben, bezweifelten, dass wormable die richtige Beschreibung ist, während andere das Ergebnis mit root access als schwerwiegend einstuften. Der Bericht enthält keine Belege dafür, dass eine solche Ausbreitung in realen Netzwerken stattgefunden hat.
Zwei Kontrollmaßnahmen stoppten oder begrenzten die Angriffskette im Labor. Zugriffsregeln, die auf eine einzige benannte Quelle und ein einziges Ziel beschränkt waren, verhinderten eine weitere Ausbreitung. An Hardware gebundene Geräteschlüssel, etwa über ein Trusted Platform Module (TPM) oder eine Secure Enclave, begrenzten den Angriff ebenfalls. Ein TPM ist eine geschützte Komponente, die kryptografisches Material an ein bestimmtes Gerät binden kann.
Administratoren haben abhängig von ihrer Bereitstellung unterschiedliche Möglichkeiten. Beim gehosteten Dienst von Tailscale kann port forwarding für jede Regel deaktiviert werden. Headscale 0.29.5 bietet diese Option nicht. Der Bericht empfiehlt deshalb, jede SSH-Berechtigung in dieser Version so zu behandeln, als könnte sie potenziell root auf dem Ziel gewähren. Tailscale empfiehlt außerdem SSH check mode, das einen zusätzlichen Schritt zur Genehmigung der Anmeldung einführt, sowie automatische Updates. Check mode stellt ein zusätzliches Hindernis dar, behebt aber nicht die gemeldete privilege escalation.
Das SSH-Problem ist eine von elf Erkenntnissen in Tailworm. Der Bericht untersucht außerdem app connectors, die serve feature, den DERP relay, der Datenverkehr zwischen Geräten überträgt, sowie headscale. Ein Problem mit einem app connector in der experimentellen conn25 feature soll es einem autorisierten Benutzer ermöglichen, Datenverkehr an Ziele zu senden, die das Sicherheitsteam nicht genehmigt hat. Zu diesen Zielen kann der metadata service eines Cloud-Anbieters gehören, ein interner Dienst, der möglicherweise Serverzugangsdaten bereitstellt. Der Forscher erklärte, dieses Problem könne für manche Organisationen schwerwiegendere Folgen haben als die SSH-Eskalation.
Proof-of-concept code wurde nicht veröffentlicht. Der Forscher erklärte, er sei zusammen mit dem Bericht am Samstag vor der Veröffentlichung privat an den Sicherheitskontakt von Tailscale gesendet worden. Die Disclosure wurde als gemeldet, aber nicht koordiniert beschrieben, und ihr Zeitpunkt stieß öffentlich auf Kritik. Der Forscher sagte außerdem, dass bereits zuvor architektonische Bedenken gegenüber dem Chief Executive von Tailscale geäußert worden seien und dass ein file hash zusammen mit dem Rat, Tailscale SSH zu deaktivieren, öffentlich veröffentlicht worden sei.
Die Erkenntnisse folgen auf frühere Arbeiten an derselben Komponente. Im Laufe des Jahres 2026 behob Tailscale mehrere Probleme bei der Handhabung von SSH und Server-Sockets, darunter eine Schwachstelle, durch die SSH Unix socket forwarding einen privilegierten Socket erreichen konnte. Dieses Problem wurde in Version 1.98.9 behoben.
Bis Korrekturen und betroffene Konfigurationen bestätigt sind, sollten Administratoren weitreichende identitäts- oder tagbasierte SSH-Regeln durch Regeln für jeweils ein einzelnes Gerät und ein einzelnes Ziel ersetzen, Forwarding überall dort deaktivieren, wo der Dienst dies erlaubt, unnötige Berechtigungen für app connectors entfernen und jede Forwarding-Regel von tailscale serve löschen, die auf einen Unix socket gerichtet ist. Node-key expiry sollte aktiviert werden, damit kopierte Geräteschlüssel nicht unbegrenzt gültig bleiben. Wenn ein Gerät kompromittiert wurde, sollte es über die control plane gelöscht werden, also den zentralen Dienst, der die Netzwerkmitgliedschaft verwaltet, da eine Neuinstallation des Geräts keine Schlüssel widerruft, die ein Angreifer möglicherweise bereits kopiert hat.
Für Leser, die die weiterreichenden IT-Auswirkungen dieses Problems beurteilen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen an. Organisationen sollten alle vorübergehend eingeführten Einschränkungen dokumentieren und weiterhin auf ein Security Bulletin des Anbieters, bestätigte betroffene Konfigurationen und eine korrigierte Version achten.