Tailscale remediază breșe SSH prin care un dispozitiv compromis devine root pe celelalte servere

Tailscale a lansat versiunea 1.104.4 a clientului pentru a închide un set de slăbiciuni din Tailscale SSH, serverul SSH integrat în agentul său de mesh-VPN. Pe un nod Linux neactualizat, un atacator care controlează deja un dispozitiv de încredere pentru politica rețelei putea abuza de forwarding-ul SSH ca să ajungă la resurse rezervate utilizatorului root de pe o altă mașină, iar în laborator asta a fost de ajuns pentru a obține un shell de root.

Ce s-a întâmplat

Tailscale SSH nu autentifică prin parole sau chei. Decide cine se poate conecta pe baza identității dispozitivului și a regulilor din fișierul de politică al tailnet-ului. Designul este comod, dar înseamnă și că un intrus nu are nevoie de credențiale furate. Un punct de sprijin pe orice dispozitiv căruia politica îi permite deja să deschidă o sesiune SSH, cu forwarding activat în acea regulă, este singura condiție.

Punctul slab este forwarding-ul pe socket. Daemonul tailscaled rulează ca root, iar atunci când o sesiune SSH permisă îi cerea să redirecționeze o conexiune către un socket Unix de pe server, daemonul valida calea cerută și apoi executa redirecționarea cu propriile privilegii de root. O condiție de cursă între verificare și utilizare permitea sesiunii să înlocuiască calea cu alta după ce validarea trecuse, anulând mecanismul care trebuia să limiteze ce socket-uri pot fi atinse.

În teste, redirecționarea către socket-ul de control Docker de pe nodul țintă a produs un shell de root și acces de citire la fișierul shadow cu parolele sistemului, fără niciun drept administrativ pe acea mașină. Avizul Tailscale descrie impactul mai restrâns, ca acces la socket-uri rezervate root-ului precum socket-ul Docker sau API-ul local tailscaled, însă ambele rezultate echivalează cu controlul total asupra nodului.

Compania subliniază că breșele nu permit unui străin neautentificat să se conecteze la servere Tailscale SSH arbitrare. Raza de acțiune este delimitată de politică: atacatorul ajunge doar la mașinile pe care politica i le permite deja dispozitivului compromis. Serverul SSH există doar în build-ul de Linux și în build-ul open-source de macOS, deși dispozitivul atacator poate rula orice platformă.

Versiunea 1.104.4 schimbă serverul astfel încât forwarding-ul să fie executat ca utilizatorul autentificat, nu ca root, și se bazează pe permisiunile obișnuite de fișiere ale sistemului de operare în locul vechii verificări de cale. Lansarea acoperă patru buletine de securitate Tailscale:

• TS-2026-014: slăbiciunile de forwarding pe socket descrise mai sus, care lasă o sesiune permisă să ajungă la socket-uri rezervate root-ului.
• TS-2026-015: o metodă prin care o sesiune SSH permisă poate epuiza memoria serverului și prăbuși tailscaled, întrerupând toată conectivitatea Tailscale pe acel nod.
• TS-2026-016: o breșă în tailscale serve, unde o redirecționare către un socket Unix putea ajunge la API-ul local tailscaled și prelua controlul de la distanță asupra nodului, plus o problemă asociată de înlocuire a socket-ului.
• TS-2026-017: cu TLS serve și două sau mai multe mount-uri configurate, o cerere putea primi antetele de permisiuni ale altui mount.

La momentul publicării, buletinele nu au identificatori CVE sau scoruri de severitate și niciunul nu precizează cea mai veche versiune afectată. Tailscale spune că a reprodus principalele probleme de escaladare a privilegiilor, le consideră serioase și încă stabilește ce configurații sunt afectate.

De ce contează

Dezvăluirea a stârnit o dispută în jurul cuvântului „wormable”. Cercetătoarea care a raportat problemele a demonstrat un lanț în care un singur dispozitiv compromis s-a propagat către fiecare nod permis de politică, fără parole, fără chei furate și fără nicio acțiune a utilizatorului, fiecare salt durând mult sub o secundă. Tailscale respinge această încadrare: nu este vorba de malware care se autoreplică, susține compania, ci de mișcare laterală limitată la conexiunile pe care politica le permite deja. Ambele părți pot avea dreptate simultan. În multe tailnet-uri reale, politica este suficient de permisivă încât „fiecare dispozitiv permis de politică” înseamnă pur și simplu fiecare dispozitiv.

Două aspecte merită atenție suplimentară:

• Patch-ul nu evacuează un atacator deja intrat. O cheie de dispozitiv furată rămâne valabilă până când nodul este șters din planul de control. Reinstalarea mașinii nu o revocă, iar notificările Tailscale nu acoperă acest scenariu.
• Headscale auto-găzduit stă mai prost. Pe headscale, forwarding-ul SSH este acordat la fiecare sesiune acceptată și nu poate fi dezactivat din politică, așa că fiecare drept SSH de acolo trebuie tratat ca drept de root. Cea mai recentă versiune headscale, 0.29.5 din 13 octombrie, nu rezolvă problemele raportate.

Dezvăluirea a fost raportată, dar nu coordonată. Tailscale spune că a primit raportul în dimineața zilei de sâmbătă, 24 octombrie, cu aproximativ două ore înainte de publicare, și că inginerii săi analizau deja aceeași zonă de cod. Niciuna dintre părți nu știe de exploatare în atacuri reale, iar codul de tip proof-of-concept a fost transmis doar echipei de securitate Tailscale. O breșă separată din aceeași cale de forwarding pe socket Unix fusese remediată în iunie, în versiunea 1.98.9, iar raportul a acoperit și conectorii de aplicații ai Tailscale, precum și funcțiile serve și funnel. Problema conectorilor se află în conn25, o funcție experimentală nelansată, deci conectorii folosiți azi de clienți nu sunt afectați. Din cele cinci constatări legate de serve și funnel, Tailscale a remediat trei și consideră că celelalte două funcționează conform designului.

Ce ai de făcut

1. Actualizează fiecare nod Linux și macOS open-source la 1.104.4 sau mai nou, începând cu serverele care expun socket-ul Docker sau rulează alte servicii deținute de root.
2. Dacă un nod nu poate fi actualizat încă, setează TS_SSH_DISABLE_FORWARDING=1 în mediul serviciului tailscaled și repornește serviciul. Astfel dezactivezi forwarding-ul fără a opri Tailscale SSH și blochezi mai multe dintre constatările grave.
3. Restrânge secțiunea SSH din fișierul de politică. Acordă SSH doar utilizatorilor și dispozitivelor care au nevoie reală și preferă perechi explicite dispozitiv-la-dispozitiv în locul regulilor largi pe grupuri. Regulile pe perechi au fost unul dintre cele două controale care au oprit lanțul de mișcare laterală în teste.
4. Leagă cheile dispozitivelor de hardware, de exemplu de un TPM, acolo unde platforma permite, ca o identitate furată să nu poată fi reutilizată din altă parte. Acesta a fost celălalt control care a rezistat.
5. Nu te baza pe modul check al SSH ca remediu. Reautentificarea protejează începutul sesiunii; abuzul de forwarding are loc în interiorul unei sesiuni deja aprobate. Modul check merită totuși activat pentru sistemele sensibile.
6. Dacă bănuiești că un nod a fost compromis, șterge-l din planul de control și reînrolează-l. Doar patch-ul sau reinstalarea îi lasă cheia utilizabilă.
7. Operatorii headscale ar trebui să presupună că fiecare drept SSH echivalează cu root până la apariția unei versiuni corectate și să reducă aceste drepturi în consecință.

Astfel de slăbiciuni apar rar într-o scanare de porturi: expunerea stă în politica de acces și în ce poate atinge o mașină de încredere pornind de la alta. Un test de penetrare intern care pleacă de la un singur nod presupus compromis și cartografiază cât de departe poate ajunge este cea mai sigură metodă de a afla dacă tailnet-ul tău ar limita raza exploziei sau i-ar preda cheile. Acest tip de exercițiu de mișcare laterală face parte din serviciul de penetration testing pe care echipa noastră îl oferă.