Tor, 333 exit relay dirottati per intercettare SSH: scoperta Ebury

🛡️ Executive Summary

• Un ricercatore identifica 333 exit relay Tor che deviano le connessioni SSH verso 12 server di intercettazione. Un’analisi indipendente rileva 377 relay con configurazioni sospette riconducibili a 59 operatori.
• Il malware Ebury 1.8.3 viene individuato su due server dell’operatore Quetzalcoatl, compromessi attraverso credenziali SSH riutilizzate. Non è dimostrato che tutti i relay coinvolti ospitassero la stessa backdoor.
• Il Tor Project esclude i relay sospetti dalla funzione di uscita entro il 5 ottobre. Restano sconosciuti il numero di credenziali effettivamente sottratte e l’identità degli aggressori.

Oltre 300 nodi di uscita della rete Tor sono stati dirottati per intercettare connessioni SSH, raccogliere credenziali e potenzialmente acquisire comunicazioni email non cifrate. La scoperta arriva dal ricercatore indipendente kaba, che il 2 ottobre 2026 ha identificato 333 exit relay capaci di reindirizzare le connessioni verso dodici server controllati dagli aggressori. L’indagine, pubblicata il 20 ottobre, ha permesso al Tor Project di individuare e isolare i nodi sospetti, mentre gli accertamenti successivi hanno confermato la presenza di Ebury 1.8.3, una backdoor Linux specializzata nel furto delle credenziali OpenSSH, su due server utilizzati da un importante operatore della rete. Non si tratta della compromissione dell’intero sistema Tor, ma di un attacco contro le infrastrutture di uscita che mette in discussione la sicurezza delle comunicazioni quando vengono accettate identità crittografiche non verificate.

Tor, 333 exit relay reindirizzavano le connessioni SSH verso dodici server

L’operazione è stata individuata quando kaba, durante una connessione SSH effettuata attraverso Tor, ha ricevuto un avviso relativo alla modifica della chiave crittografica del server remoto. Il ricercatore ha quindi utilizzato exitmap, uno strumento che permette di verificare il comportamento dei nodi di uscita, per esaminare circa 3.000 exit relay della rete. Nel rapporto originale pubblicato il 20 ottobre descrive un sistema di controllo costruito attraverso due server: il primo avviava le connessioni utilizzando uno specifico nodo Tor, mentre il secondo verificava l’indirizzo dal quale proveniva effettivamente il traffico.

L’indagine ha identificato 333 relay che reindirizzavano SSH verso dodici server di intercettazione. Circa una dozzina presentava una chiave pubblica diversa da quella del server legittimo; negli altri casi era osservabile il reindirizzamento, senza che la scansione mostrasse sempre una sostituzione della chiave. L’analisi successiva dei registri pubblici Tor ha individuato 377 relay riconducibili a 59 operatori che avevano adottato configurazioni di uscita compatibili con la campagna, raggiungendo il 7,46% della capacità complessiva degli exit relay, misurata attraverso il peso nel consensus. I 377 nodi costituiscono un insieme individuato mediante indicatori di configurazione e non altrettante compromissioni dimostrate singolarmente. La portata dell’operazione supera quella dei precedenti attacchi contro la rete Tor che avevano esposto infrastrutture utilizzate da gruppi ransomware, perché colpisce direttamente la fiducia nelle connessioni in uscita.

Leggi anche: TorNet: nuova backdoor nascosta nella rete TOR per cyberattacchi mirati

Il man-in-the-middle contro SSH: password sottratte dopo l’accettazione della chiave

La tecnica sfruttava una caratteristica fondamentale di Tor: il nodo di uscita rappresenta l’ultimo passaggio prima della destinazione esterna, e può quindi osservare o manipolare il traffico che non dispone di adeguate protezioni crittografiche end-to-end. Gli aggressori hanno modificato le regole ExitPolicy nei file di configurazione torrc, abilitando la porta 22 di SSH su relay che precedentemente la bloccavano e, in alcuni casi, trasformando nodi intermedi in nodi di uscita. Il traffico veniva poi reindirizzato verso server capaci di presentare una propria chiave SSH, inducendo l’utente a stabilire la sessione con l’intermediario anziché direttamente con il server desiderato. Il furto della password richiedeva che l’utente accettasse la chiave sconosciuta o modificata e utilizzasse l’autenticazione tramite password. In queste condizioni l’intercettatore poteva autenticarsi al server reale, mantenendo apparentemente funzionante la sessione e osservando i comandi eseguiti. L’autenticazione SSH basata su chiavi pubbliche non poteva essere inoltrata nello stesso modo, perché la firma del client è vincolata alla specifica sessione crittografica. Gli aggressori hanno inoltre modificato le policy per escludere le porte della posta cifrata IMAPS e POP3S, mantenendo disponibili in molti casi IMAP e POP3, protocolli che possono trasportare dati in chiaro. Non esiste però una quantificazione verificata delle email o delle password effettivamente intercettate. L’episodio ripropone il problema tecnico già esaminato nelle differenze tra attacchi man-in-the-middle e compromissioni interne al browser: la cifratura protegge soltanto quando anche l’identità dell’interlocutore viene verificata correttamente.

Ebury 1.8.3 sui server Linux: la backdoor era nascosta dentro OpenSSH

Le indagini hanno individuato un elemento particolarmente significativo nella famiglia di relay Quetzalcoatl, gestita da un operatore identificato come Zimmer. Nel resoconto tecnico pubblicato sulla mailing list del Tor Project viene documentata la compromissione di due server Linux attraverso Ebury 1.8.3: un sistema di gestione ospitato presso Contabo, utilizzato come gateway VPN e jump host SSH, e un server FranTech che gestiva due exit relay. L’accesso iniziale risaliva al 28 agosto 2026, quando un aggressore aveva utilizzato una password valida, ottenendo privilegi root in pochi minuti. La ricostruzione individua come fattori determinanti il riutilizzo della stessa password per SSH, sudo e cifratura dei backup, oltre alla presenza di autenticazione SSH tramite password sul sistema esposto.

Una volta compromesso il server di gestione, gli aggressori avevano potuto raggiungere ulteriori infrastrutture attraverso credenziali e chiavi conservate nei backup. Ebury si nascondeva mediante una libreria Linux non appartenente ai pacchetti installati, identificata nel percorso /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, collegata al nome utilizzato normalmente dal sistema attraverso un symlink. Questa tecnica rendeva insufficienti alcune verifiche tradizionali dell’integrità dei pacchetti, mentre la backdoor era capace di nascondere accessi SSH e sottrarre credenziali. Il malware era già stato associato a una campagna di compromissione che aveva raggiunto circa 400.000 server Linux dal 2009. Il ritrovamento conferma Ebury sui due server esaminati, ma non dimostra che la stessa backdoor fosse installata su tutti i nodi Tor coinvolti.

Il Tor Project blocca i relay: restano dubbi sull’accesso iniziale degli aggressori

La risposta del Tor Network Health Team è iniziata dopo le segnalazioni del 2 ottobre, proseguendo con il contatto degli operatori interessati e l’esclusione progressiva dei nodi sospetti. Nel comunicato ufficiale del 5 ottobre rivolto agli operatori Tor il gruppo conferma la modifica non autorizzata dei file di configurazione e invita a controllare processi, connessioni, moduli del kernel e impostazioni dei relay. Le autorità della directory hanno applicato i contrassegni BadExit e MiddleOnly, impedendo ai client di utilizzare i nodi segnalati come uscite. Entro le 17:00 UTC del 5 ottobre nessun relay con le policy sospette risultava più presente nel consensus utilizzabile, mentre le statistiche pubbliche registravano una riduzione di circa 370 exit relay. La ricerca successiva ha evidenziato che una parte significativa dei nodi coinvolti apparteneva a infrastrutture ospitate da FranTech/BuyVM, alimentando l’ipotesi di un fattore di compromissione condiviso. Tuttavia, la concentrazione presso un provider non dimostra che il fornitore sia stato violato, così come non chiarisce se gli aggressori abbiano ottenuto l’accesso attraverso credenziali rubate, altri server precedentemente compromessi o vulnerabilità ancora sconosciute. Il problema riguarda la capacità di distinguere gli accessi malevoli nei sistemi Linux, una criticità ricorrente anche nelle campagne SSHStalker che utilizzano servizi SSH compromessi per mantenere infrastrutture criminali persistenti. L’identità degli operatori della campagna rimane sconosciuta e non emergono prove pubbliche sufficienti per attribuirla a uno Stato o a un gruppo criminale specifico.

Continua con:

Una sola pagina malevola può compromettere Firefox e Tor Browser

Oniux: lo strumento Tor per instradare le applicazioni Linux nella rete anonima

Utenti Tor e amministratori Linux: quali controlli servono dopo l’attacco

Gli utenti che hanno effettuato accessi SSH attraverso Tor tra il 1° e il 5 ottobre 2026 devono verificare soprattutto l’eventuale accettazione di una chiave host sconosciuta o modificata. Se durante quel periodo è stata ignorata una segnalazione di OpenSSH e successivamente inserita una password, la credenziale dovrebbe essere considerata potenzialmente compromessa, sostituita e accompagnata da un controllo degli accessi al server. Il file known_hosts può contenere la chiave accettata durante la connessione, ma l’assenza di un identificatore noto non consente di escludere ogni possibile intercettazione. Per gli operatori Tor, le priorità comprendono la verifica delle modifiche non autorizzate a torrc, il confronto con le policy pubblicate nella directory, l’analisi dei servizi SSH, dei file setuid, dei collegamenti simbolici alle librerie di sistema e delle comunicazioni di rete anomale. In presenza di indicatori Ebury, la semplice rimozione di un file non può essere considerata una bonifica affidabile: occorrono isolamento, acquisizione forense e ricostruzione del sistema da una base attendibile, insieme alla rotazione delle credenziali e delle chiavi coinvolte. Le raccomandazioni devono essere lette nel contesto della sicurezza delle implementazioni OpenSSH e dei precedenti problemi che hanno esposto server Linux. L’attacco non dimostra che Tor abbia perso le proprie garanzie di anonimato per tutti gli utenti, né che le normali connessioni HTTPS siano state automaticamente decifrate. Dimostra piuttosto che la sicurezza della rete dipende anche dall’integrità degli operatori che la compongono e che l’utilizzo di Tor non sostituisce la verifica delle identità crittografiche, soprattutto quando vengono gestiti accessi amministrativi e credenziali sensibili.