Il 10% degli exit node Tor era compromesso: intercettavano connessioni SSH

Un singolo avviso di OpenSSH ha permesso di scoprire una compromissione che coinvolgeva centinaia di nodi di uscita della rete Tor. A inizio ottobre 2026, un ricercatore racconta di aver effettuato una normale connessione SSH attraverso Tor quando il client ha segnalato che la chiave del server remoto non coincideva più con quella memorizzata: il traffico era finito su un’infrastruttura controllata da attaccanti, predisposta per eseguire un attacco man-in-the-middle contro le sessioni SSH.

L’indagine che da lì si è dipanata ha portato all’individuazione di 333 exit relay compromessi, un numero particolarmente rilevante perché in quel momento Tor disponeva di circa 3.000 nodi di uscita. Gli aggressori avevano ottenuto il controllo di una quota vicina al 10% degli exit relay disponibili.

I responsabili del Tor Project sono intervenuti marcando i relay sospetti con il flag BadExit e contattando gli operatori coinvolti. La vicenda non riguarda quindi una vulnerabilità del protocollo Tor bensì nasce dalla compromissione dei server Linux che ospitavano i relay e dall’uso di Ebury, una backdoor per OpenSSH attiva da molti anni.

Come i nodi Tor compromessi intercettavano le connessioni SSH

Un circuito Tor attraversa normalmente più relay; l’ultimo nodo, quello di uscita, apre la connessione verso il server Internet di destinazione.

Il servizio remoto vede quindi l’indirizzo IP dell’exit relay, non quello dell’utente. Se il traffico applicativo utilizza TLS o un altro protocollo crittografico correttamente autenticato, il nodo di uscita può osservare alcuni metadati ma non dovrebbe riuscire a leggere il contenuto cifrato.

SSH offre a sua volta cifratura e autenticazione del server tramite le host key. Nella vicenda emersa in questi giorni, quando il ricercatore ha tentato di collegarsi alla propria macchina passando attraverso uno degli exit relay compromessi, la connessione diretta alla porta 22 è finita su uno dei 12 server predisposti dagli aggressori per l’intercettazione. Il server intermedio presentava una chiave diversa da quella autentica, quindi OpenSSH ha mostrato il messaggio “REMOTE HOST IDENTIFICATION HAS CHANGED!”

Quel controllo è una delle difese fondamentali di SSH: la prima volta che un client contatta un host, salva la relativa chiave in known_hosts. Durante le connessioni successive, la chiave ricevuta è automaticamente confrontata con quella nota e già salvata.

Nel caso di specie, chi procedeva comunque con il login consegnava la password al sistema di intercettazione. L’attaccante apriva quindi una seconda connessione verso il vero server, inoltrava i comandi e poteva osservare la sessione. In parallelo tentava di ottenere privilegi sufficienti per installare Ebury sulla macchina appena raggiunta: un exit relay compromesso diventava anche uno strumento per trovare e infettare nuovi server Linux.

Perché modificare le ExitPolicy dei relay Tor

Il resoconto tecnico di uno degli operatori colpiti mostra che gli aggressori avevano modificato anche la configurazione Tor. Le ExitPolicy stabiliscono quali connessioni un exit relay accetta di inoltrare verso Internet. Per impostazione predefinita Tor blocca già alcune porte associate a servizi che generano facilmente abusi, lasciandone disponibili molte altre.

Sui sistemi compromessi gli aggressori hanno alterato l’assetto dei file torrc in modo da ottenere una politica quasi aperta, ma con alcune esclusioni mirate. In uno dei casi analizzati risultavano bloccate le porte 25, 465, 587, 993 e 995. La scelta è evidente: 465 e 587 sono comunemente associate all’invio di posta con cifratura o autenticazione, mentre 993 e 995 corrispondono tipicamente a IMAPS e POP3S. Al tempo stesso potevano rimanere raggiungibili servizi in chiaro come POP3 e IMAP sulle porte 110 e 143.

Il sospetto, coerente con quanto osservato dagli operatori, è che gli attaccanti volessero aumentare la probabilità di intercettare traffico non cifrato.

Resta aperta la domanda più importante: come sono entrati nei server?

Come hanno fatto gli attaccanti a ottenere l’accesso iniziale a così tanti relay Tor?

Le informazioni rese pubbliche indicano che almeno alcuni server risultavano compromessi già diverse settimane prima dell’attivazione coordinata delle intercettazioni SSH. Non esiste però, al momento, una spiegazione unica e verificata per l’accesso iniziale.

In uno dei casi ricostruiti dagli operatori coinvolti, gli aggressori sembravano già conoscere una password valida al momento del primo accesso osservato. È quindi plausibile che la credenziale provenisse da un altro sistema precedentemente compromesso: Ebury può infatti raccogliere password, chiavi SSH e altre informazioni utili per spostarsi da una macchina all’altra.

Citata nell’introduzione, Ebury è una backdoor per OpenSSH con funzioni di furto delle credenziali, studiata da ESET Research da oltre un decennio: gli aggressori la utilizzano per intercettare password e chiavi SSH, mantenere accesso ai server compromessi e propagarsi verso altre macchine. Secondo ESET, dal 2009 Ebury avrebbe interessato circa 400.000 server Linux, FreeBSD e OpenBSD; oltre 100.000 risultavano ancora compromessi alla fine del 2023. Le versioni più recenti includono inoltre componenti userland rootkit, capaci di nascondere processi, file, socket e memoria mappata agli amministratori.

Un’altra ipotesi riguarda i provider di hosting. Non sarebbe una novità per gli operatori di Ebury: precedenti indagini di ESET hanno documentato casi nei quali gli attaccanti erano riusciti a compromettere infrastrutture utilizzate dai provider e, da quella posizione, avevano poi raggiunto i server dei clienti.