← Tutti gli articoli

Le falle di Tailscale SSH potrebbero consentire root access attraverso le reti

Le falle di Tailscale SSH potrebbero consentire root access attraverso le reti

Le falle di Tailscale SSH documentate da un ricercatore di Cyberdione Labs potrebbero consentire a un attaccante che controlla un dispositivo di ottenere root access, il massimo livello di controllo del sistema, su altri server autorizzati. L'attacco richiede che Tailscale SSH, una funzione di accesso remoto basata su Secure Shell, consenta il port forwarding, che permette a una connessione di trasportare traffico verso un'altra destinazione locale o remota. Il dispositivo compromesso deve inoltre essere autorizzato dalle regole di accesso della rete a connettersi al proprio obiettivo.

I risultati sono apparsi il 25 ottobre in un rapporto intitolato Tailworm. Il ricercatore ha testato Tailscale 1.104.2 e headscale 0.29.5, un server self-hosted utilizzato da alcune organizzazioni al posto del servizio hosted di Tailscale. I test si sono svolti nell'arco di tre giorni in laboratorio. Il rapporto non descrive attacchi osservati su reti di produzione e nessun altro ricercatore ne ha riprodotto pubblicamente i risultati. Al momento della pubblicazione non erano disponibili un bollettino di sicurezza, un identificatore CVE o una versione corretta, e Tailscale non aveva confermato le singole affermazioni tecniche.

Tailscale ha dichiarato pubblicamente di aver ricevuto il rapporto e di stare già esaminando le stesse aree insieme a specialisti di sicurezza esterni. Il suo vicepresidente dell'ingegneria ha affermato che l'azienda aveva individuato problemi su cui stava lavorando, ma che stava ancora determinando quali configurazioni fossero interessate. L'azienda non consigliava a tutti i clienti di disabilitare Tailscale SSH.

Il rischio deriva dal modo in cui Tailscale SSH autorizza le sessioni. Un server SSH convenzionale controlla normalmente la password o la cryptographic key di un utente. Tailscale SSH identifica invece il dispositivo che si connette e utilizza una regola di accesso per decidere se quel dispositivo possa avviare una sessione SSH. L'attacco segnalato non richiede quindi che l'attaccante rubi una password o una SSH key. Richiede comunque una compromissione iniziale che, secondo il rapporto, potrebbe avvenire tramite un'applicazione web vulnerabile, un pacchetto software malevolo, phishing o credenziali di accesso rubate. Tailscale non fornisce di per sé questo primo punto d'appoggio.

Nel primo test di laboratorio, il normale SSH port forwarding ha indotto il processo Tailscale, che viene eseguito con root privileges, a connettersi a un socket di sistema. Un socket è un canale di comunicazione locale utilizzato dal software e, in questo caso specifico, avrebbe dovuto essere accessibile esclusivamente a root. La sessione ha ottenuto root access e ha letto il file delle password di sistema senza diritti di amministratore. Con un altro metodo, il ricercatore ha sostituito un socket di proprietà di root con uno controllato dall'attaccante, rendendo possibile l'esecuzione diretta di comandi root contro determinati servizi.

Una terza tecnica ha sfruttato un intervallo temporale tra il controllo del percorso di un file e il suo utilizzo. Modificando l'obiettivo durante quel breve intervallo, il test ha aggirato una protezione progettata per limitare i file raggiungibili tramite forwarding. La catena risultante ha acquisito una device enrolment key e l'ha utilizzata per aggiungere alla rete, come server attendibile, una macchina controllata dall'attaccante. La catena completa ha funzionato soltanto dove Tailnet Lock non era abilitato. Con Tailnet Lock attivo, i segreti sono stati acquisiti durante il trasferimento tra sistemi, ma la fase finale di registrazione non è stata completata.

Il ricercatore ha descritto la catena come wormable, perché un dispositivo compromesso potrebbe spostarsi verso ogni altro dispositivo consentito dalle regole di accesso, senza ulteriori password, SSH keys rubate o interazioni dell'utente. In laboratorio, ogni passaggio ha richiesto meno di un secondo. Alcuni ricercatori che hanno esaminato il rapporto hanno messo in dubbio che wormable sia la descrizione corretta, mentre altri hanno definito grave il risultato relativo a root access. Nel rapporto non vi sono prove che questa diffusione sia avvenuta su reti reali.

Due controlli hanno bloccato o limitato la catena di laboratorio. Le regole di accesso limitate a un'unica origine e un'unica destinazione specificamente indicate hanno impedito un'ulteriore diffusione. Anche le device keys associate all'hardware, per esempio a un Trusted Platform Module (TPM) o a Secure Enclave, hanno limitato l'attacco. Un TPM è un componente protetto che può mantenere il materiale crittografico vincolato a uno specifico dispositivo.

Gli amministratori hanno diverse opzioni a seconda della loro implementazione. Il servizio hosted di Tailscale consente di disabilitare il port forwarding per ogni regola. headscale 0.29.5 non offre questa opzione, quindi il rapporto raccomanda di considerare ogni autorizzazione SSH su quella versione come potenzialmente in grado di concedere root sulla destinazione. Tailscale raccomanda inoltre SSH check mode, che aggiunge una fase di approvazione dell'accesso, e gli aggiornamenti automatici. Check mode crea un ulteriore ostacolo, ma non corregge la privilege escalation segnalata.

Il problema SSH è uno degli 11 risultati inclusi in Tailworm. Il rapporto esamina anche gli app connectors, la funzione serve, il DERP relay che trasporta il traffico tra dispositivi e headscale. Un problema di un app connector nella funzione sperimentale conn25 consentirebbe, secondo quanto affermato, a un utente autorizzato di inviare traffico verso destinazioni non approvate dal team di sicurezza. Tali destinazioni possono includere il metadata service di un cloud provider, un servizio interno che potrebbe fornire credenziali del server. Il ricercatore ha affermato che, per alcune organizzazioni, questo problema potrebbe avere conseguenze maggiori rispetto alla privilege escalation tramite SSH.

Il codice proof-of-concept non è stato reso pubblico. Il ricercatore ha dichiarato che era stato inviato privatamente al contatto di sicurezza di Tailscale insieme al rapporto, il sabato precedente alla pubblicazione. La divulgazione è stata descritta come segnalata ma non coordinata e le sue tempistiche hanno suscitato critiche pubbliche. Il ricercatore ha inoltre affermato che precedenti dubbi architetturali erano stati segnalati all'amministratore delegato di Tailscale e che un file hash era stato pubblicato insieme al consiglio di disabilitare Tailscale SSH.

I risultati seguono precedenti attività sullo stesso componente. Nel corso del 2026, Tailscale ha corretto diversi problemi relativi a SSH e alla gestione dei server socket, inclusa una falla che consentiva all'SSH Unix socket forwarding di raggiungere un socket privilegiato. Il problema è stato risolto nella versione 1.98.9.

Finché non saranno confermate le correzioni e le configurazioni interessate, gli amministratori dovrebbero sostituire le regole SSH generiche basate sull'identità o sui tag con regole che prevedano un singolo dispositivo e un singolo obiettivo, disabilitare il forwarding ovunque il servizio lo consenta, rimuovere le autorizzazioni non necessarie degli app connectors ed eliminare qualsiasi regola di forwarding di tailscale serve diretta verso un Unix socket. La Node-key expiry dovrebbe essere abilitata affinché le device keys copiate non rimangano valide a tempo indeterminato. Se un dispositivo viene compromesso, dovrebbe essere eliminato tramite il control plane, il servizio centrale che gestisce l'appartenenza alla rete, perché la reinstallazione del dispositivo non revoca le keys che un attaccante potrebbe avere già copiato.

Per i lettori che stanno valutando le implicazioni IT più ampie di questo problema, AEU-I offre servizi IT, infrastrutturali e di consulenza incentrati sulla sicurezza. Le organizzazioni dovrebbero documentare tutte le restrizioni temporanee introdotte e continuare a monitorare la pubblicazione di un bollettino del fornitore, la conferma delle configurazioni interessate e il rilascio di una versione corretta.

Disponibile anche in: EnglishDeutschShqip