Tailscale pregătea o actualizare de securitate după ce detalii despre vulnerabilitățile „Tailworm” au devenit publice în weekend, înainte ca patch-urile să fie disponibile. Raportul Cyberdione Labs descrie 11 probleme în clientul Tailscale 1.104.2 și în headscale 0.29.5, serverul de control open-source pe care organizațiile îl pot găzdui singure.
Breșa pornea de la un dispozitiv deja compromis
Tailscale oferă o rețea privată de tip mesh VPN, care folosește protocolul WireGuard pentru a conecta dispozitive și servicii ale unei organizații. În loc să se bazeze doar pe o rețea tradițională de tip perimetru, serviciul permite definirea accesului între dispozitive pe baza identității acestora și a politicilor configurate.
Dintre cele 11 constatări prezentate de Cyberdione Labs, șase au fost evaluate ca având severitate ridicată. Patru dintre acestea privesc Tailscale SSH, funcția care acordă acces la servere în funcție de identitatea dispozitivului și de regulile rețelei, nu prin parole sau chei introduse de utilizator.
Potrivit raportului, unele operațiuni de redirecționare din Tailscale SSH se executau cu privilegii root, iar mecanismele menite să le limiteze puteau fi ocolite. În testele de laborator, un atacator care compromisese un dispozitiv a putut exploata problema împotriva serverelor la care acel dispozitiv avea deja drept de acces prin SSH.
Condiția este importantă: vulnerabilitățile nu însemnau că un atacator neautentificat putea să se conecteze arbitrar la orice mașină. Însă, dacă regulile permiteau redirecționarea, exploatarea putea duce la acces root pe serverele-țintă și la furtul unor chei capabile să adauge dispozitive neautorizate în rețea.
Sursă foto: www.securityweek.com
Un vierme fără parole putea trece de la un server la altul
Punctul de pornire al unui atac putea fi o compromitere obișnuită, de exemplu prin phishing, prin exploatarea unei aplicații web vulnerabile sau prin instalarea unui pachet software malițios. Odată obținut accesul la un dispozitiv, atacatorul putea încerca să folosească încrederea deja acordată acelui dispozitiv de politicile Tailscale.
Cercetătorii au descris vulnerabilitățile SSH ca fiind exploatabile într-un scenariu de tip „wormable”, adică susceptibil să se propage automat. Deoarece mecanismul nu se baza pe introducerea unor credențiale de către utilizator, un atac putea înlănțui vulnerabilitățile și se putea deplasa între serverele pe care politica le făcea accesibile.
În demonstrațiile raportate, fiecare salt către o altă mașină dura mai puțin de o secundă și nu necesita interacțiunea utilizatorului. Asta nu înseamnă că orice rețea Tailscale ar fi fost vulnerabilă în aceeași măsură: propagarea depindea de configurația accesului SSH și de faptul că regulile permiteau operațiunile de redirecționare implicate.
Riscul concret era, așadar, mai mare în mediile în care un singur dispozitiv avea acces SSH la numeroase servere, iar regulile de forwarding erau largi sau nu mai erau necesare. O compromitere inițială relativ limitată putea deveni o problemă de privilegii și de mișcare laterală, cu posibilitatea ca cheile furate să faciliteze introducerea unor dispozitive ostile.
Problemele vizau și funcții experimentale, headscale și relee
Raportul nu se limitează la Tailscale SSH. Cyberdione Labs a descris probleme și în funcția experimentală app connector, în funcția Serve, în headscale și în componenta de relay a clientului, cu efecte diferite în funcție de funcție și de configurație.
Printre consecințele menționate se numără posibilitatea de a ajunge la servicii de metadate din cloud și la rețele interne, ocolind regulile de acces. Serviciile de metadate sunt deosebit de sensibile în infrastructurile cloud, deoarece pot expune informații relevante pentru instanțele și serviciile care rulează acolo.
Alte constatări ar fi putut face interfața administrativă a unui nod vizibilă pentru dispozitive aflate la distanță sau provoca condiții de refuz al serviciului (DoS). Materialul disponibil nu oferă, pentru fiecare constatare, toate detaliile tehnice ori indicatori de compromitere; acestea nu trebuie deduse din descrierea generală a impactului.
Cyberdione Labs a publicat raportul înainte ca furnizorul să lanseze remedii, iar calendarul divulgării a fost criticat pe rețelele sociale. Cercetătorii au susținut că publicarea rapidă a informațiilor ar putea accelera remedierea, în timp ce utilizatorii au primit detalii despre riscuri înainte să existe o versiune numerotată cu toate corecțiile.
Tailscale a pregătit patch-uri, dar a cerut verificarea politicilor
Într-un răspuns publicat pe Reddit, Mike Shaver, vicepreședinte pentru inginerie la Tailscale, a spus că firma își desfășura propria investigație, cu contribuția unor specialiști externi în securitate, înainte de a primi raportul. El a precizat că majoritatea problemelor identificate până atunci priveau ce se întâmplă după autorizarea conexiunii, în special privilegiile Unix și redirecționarea SSH.
Shaver a explicat că, în anumite situații, o sesiune putea face mai mult decât permitea utilizatorului local configurat. El a calificat situația drept serioasă, dar a subliniat că nu era echivalentă cu posibilitatea unui atacator neautentificat de a se conecta la orice mașină; impactul depindea de configurarea accesului SSH.
Într-o actualizare comunicată luni, Tailscale a spus că remedii erau deja pregătite pentru majoritatea problemelor și că țintea publicarea unui client corectat până la sfârșitul zilei de marți, 27 octombrie, sub rezerva testării. Compania a anunțat că va publica o avertizare de securitate și o analiză tehnică după apariția actualizării.
Raportul Tailworm, actualizat marți, menționa că remedii pentru mai multe constatări ajunseseră în depozitele publice de cod ale Tailscale. La acel moment, niciuna dintre aceste corecții nu fusese inclusă într-o versiune numerotată a clientului, distincție esențială pentru administratorii care trebuie să verifice dacă au instalat efectiv o versiune reparată.
Ce ar trebui să facă acum administratorii din România și UE
Tailscale nu a recomandat dezactivarea generală a Tailscale SSH, iar sursa nu menționează exploatări observate în atacuri reale. În lipsa unei confirmări privind exploatarea activă, organizațiile nu ar trebui să confunde scenariul demonstrat în laborator cu dovada unui incident, dar nici să trateze riscul ca fiind pur teoretic.
Pentru companiile și instituțiile din România și din Uniunea Europeană care folosesc serviciul, primul pas este inventarierea versiunilor clientului și a instanțelor headscale, urmată de instalarea actualizărilor oficiale imediat ce sunt disponibile. Echipele trebuie să verifice și dacă folosesc funcțiile menționate în raport, inclusiv Serve, app connector și mecanismele de relay.
Până la instalarea patch-ului, recomandarea explicită a Tailscale este revizuirea politicilor de acces SSH și dezactivarea redirecționării acolo unde nu este necesară. Administratorii ar trebui să restrângă accesul la serverele strict necesare și să evite regulile mai largi decât cere activitatea operațională, mai ales pentru dispozitive care pot ajunge la multe sisteme.
În paralel, echipele de securitate pot căuta semne de acces neobișnuit între dispozitive și servere, precum și modificări neașteptate ale dispozitivelor autorizate sau ale cheilor asociate rețelei. Aceste verificări sunt măsuri prudente de telemetrie defensivă, nu indicatori de compromitere publicați de raport; confirmarea unei intruziuni necesită corelarea lor cu jurnalele și configurațiile proprii.
Pentru organizațiile care operează servicii esențiale sau date sensibile, incidentul subliniază importanța controlului privilegiilor și a segmentării accesului, inclusiv în rețelele private de tip mesh. O conexiune criptată și o identitate de dispozitiv verificată nu elimină riscul ca o regulă prea permisivă sau o vulnerabilitate după autorizare să amplifice efectele unei compromiteri inițiale.
