Luka w Tailscale SSH grozi całej sieci

Tailscale SSH pod lupą

W pakiecie odkrytych problemów bezpieczeństwa związanych z Tailscale i Headscale najpoważniej wygląda luka dotycząca Tailscale SSH. W określonej konfiguracji kompromitacja jednego urządzenia może otworzyć drogę do pozostałych systemów w tej samej sieci.

Badanie objęło klienta Tailscale v1.104.2 oraz Headscale v0.29.5, czyli samodzielnie hostowany serwer kontroli. W sumie opisano 11 podatności, z czego 6 oceniono jako poważne.

Na czym polega ryzyko

Tailscale to mesh VPN oparty na WireGuard, który łączy urządzenia w prywatną sieć bez klasycznego, centralnego tunelu. Ruch nie przechodzi przez serwer kontrolny, ale to właśnie on zarządza kluczami, trasami i politykami dostępu.

W przypadku Tailscale SSH model działania różni się od klasycznego SSH. Zamiast opierać się na haśle lub kluczu użytkownika, system bierze pod uwagę przede wszystkim tożsamość urządzenia i reguły dostępu. To wygodne, ale w tej konfiguracji może stać się problemem.

Najgroźniejszy scenariusz wymaga dwóch warunków:

• Tailscale SSH musi mieć włączone przekierowanie portów.
• Atakujący musi już kontrolować urządzenie, które ma dostęp do celu.

W praktyce oznacza to, że po przejęciu jednego zaufanego hosta napastnik może próbować przejść dalej, nawet bez kradzieży haseł czy kluczy SSH.

Jak może dojść do eskalacji

Opisany błąd wynika z tego, że proces tailscaled działa z uprawnieniami root. Przy przekierowaniach socketów Unix możliwe jest więc doprowadzenie do sytuacji, w której zwykły użytkownik wywołuje operacje na zasobach zarezerwowanych dla roota.

Badanie wskazuje też na race condition typu TOCTOU: ścieżka jest najpierw sprawdzana, a później ponownie rozwiązywana w momencie operacji. Tę lukę można wykorzystać, bardzo szybko podmieniając nazwę katalogu między jednym a drugim etapem.

W testach wykorzystano pętlę, która zmieniała nazwę ścieżki około 170 tysięcy razy na sekundę. Efekt? Możliwe było skierowanie operacji na socket dostępny tylko dla roota i uzyskanie uprawnień superużytkownika na maszynie testowej.

W jednym z przypadków udało się nawet odczytać plik z hasłami systemowymi niemal od razu, bez posiadania praw administracyjnych.

Jedna maszyna, cały tailnet

Problem nie kończy się na lokalnej eskalacji uprawnień. W opisie ataku pojawia się także możliwość przechwycenia klucza enrolmentu i dołączenia kontrolowanej maszyny do tailnetu. Co ważne, Tailnet Lock jest domyślnie wyłączony.

To oznacza, że zmiana może rozprzestrzeniać się bardzo szybko do wszystkich urządzeń objętych polityką SSH. W testach mowa była o czasie krótszym niż jedna sekunda.

Inne wykryte problemy

Poza główną luką badanie objęło też inne słabe punkty w ekosystemie Tailscale i Headscale. Dotyczą one m.in.:

• App connectors – eksperymentalnej funkcji, która może pozwolić zaufanemu urządzeniu łączyć się z dowolnym celem, także z usługą metadanych chmurowych;
• Headscale – instancji wystawionej do internetu, która może być narażona na atak DoS blokujący rejestrację nowych urządzeń;
• Tailscale Serve – przekierowania TCP, które mogą ujawniać lokalne API administracyjne węzła.

Brak CVE i brak łatki

Na moment publikacji nie wydano jeszcze oficjalnego biuletynu bezpieczeństwa, nie przypisano też numeru CVE. Co najważniejsze, poprawki nie były jeszcze dostępne.

Jednocześnie pojawiły się sygnały, że prace nad łagodzeniem problemu już trwają. Wspomniano o zmianach w kodzie, które mają ograniczyć ryzyko związane z Tailscale Serve oraz sprawić, by przekierowania SSH działały podobnie jak w klasycznym OpenSSH, czyli z uprawnieniami bieżącego użytkownika, a nie roota.

Co można zrobić teraz

Do czasu wydania oficjalnych poprawek warto ograniczyć ryzyko możliwie szybko:

• przejrzeć polityki dostępu SSH;
• wyłączyć SSH forwarding, jeśli nie jest potrzebny;
• w środowisku SaaS wyłączyć przekierowania dla poszczególnych reguł;
• w przypadku Headscale zadbać o ograniczenie ekspozycji instancji;
• jeśli to możliwe, wyłączyć Tailscale SSH;
• utrzymywać oprogramowanie w najnowszej wersji.

Dlaczego to ważne

Tailscale jest cenione za prostotę i bezpieczeństwo zdalnego dostępu, ale ten przypadek pokazuje, że nawet rozwiązania budowane wokół nowoczesnych mechanizmów autoryzacji mogą stać się wektorem ataku, jeśli zaufanie do urządzenia zostanie wykorzystane przeciwko całej sieci.

Największe zagrożenie polega tu nie na wycieku pojedynczych danych, lecz na eskalacji z jednego hosta do całego środowiska.