In questo articolo Indice dei contenuti 2 sezioni
Quasi il 10% degli exit node Tor era finito sotto il controllo di un gruppo di attaccanti che intercettava le connessioni SSH, e a far emergere tutto è stato un singolo avviso di OpenSSH. All’inizio di ottobre 2026 un ricercatore stava eseguendo una normale connessione SSH attraverso Tor quando il client ha segnalato che la chiave del server remoto non corrispondeva più a quella memorizzata. Il traffico era stato dirottato su un’infrastruttura gestita dagli aggressori, costruita apposta per condurre un attacco man in the middle contro le sessioni SSH.
Da quel campanello d’allarme è partita un’indagine che ha portato a individuare 333 exit relay compromessi. Un numero tutt’altro che marginale, visto che in quel momento la rete Tor contava circa 3.000 nodi di uscita. I responsabili del Tor Project sono intervenuti marcando i relay sospetti con il flag BadExit e contattando gli operatori coinvolti. Il protocollo Tor in sé non presenta alcuna falla. Il problema nasce dalla compromissione dei server Linux che ospitavano i relay e dall’impiego di Ebury, una backdoor per OpenSSH attiva da molti anni.
Come funzionava l’intercettazione delle sessioni SSH
Un circuito Tor passa di norma attraverso più relay e l’ultimo, il nodo di uscita, apre la connessione verso il server di destinazione. Il servizio remoto vede quindi l’indirizzo IP dell’exit relay e non quello dell’utente. Quando il traffico usa TLS o un altro protocollo crittografico autenticato in modo corretto, il nodo può osservare qualche metadato ma non dovrebbe riuscire a leggere il contenuto cifrato.
Anche SSH garantisce cifratura e autenticazione del server tramite le host key. Nel caso in questione la connessione diretta alla porta 22 è finita su uno dei 12 server allestiti dagli aggressori per l’intercettazione. Quella macchina intermedia presentava una chiave diversa dall’originale e OpenSSH ha mostrato il messaggio “REMOTE HOST IDENTIFICATION HAS CHANGED!”. Si tratta di una delle difese fondamentali del protocollo, perché al primo contatto con un host il client salva la chiave nel file known_hosts e nelle connessioni successive la confronta in automatico con quella ricevuta.
Chi ignorava l’avviso e procedeva con il login consegnava la password al sistema di intercettazione. L’attaccante apriva allora una seconda connessione verso il server vero, inoltrava i comandi e poteva seguire la sessione. Nel frattempo cercava di ottenere privilegi sufficienti per installare Ebury sulla macchina appena raggiunta, trasformando così ogni relay compromesso in uno strumento per scovare e infettare altri server Linux.
Le ExitPolicy modificate e il nodo dell’accesso iniziale
Il resoconto tecnico di uno degli operatori colpiti mostra che gli aggressori avevano messo mano anche alla configurazione di Tor. Le ExitPolicy stabiliscono quali connessioni un exit relay accetta di inoltrare verso Internet e per impostazione predefinita bloccano alcune porte legate a servizi facilmente sfruttabili per abusi. Sui sistemi violati i file torrc erano stati alterati per ottenere una politica quasi aperta, con poche esclusioni mirate. In un caso risultavano bloccate le porte 25, 465, 587, 993 e 995. Le porte 465 e 587 sono associate all’invio di posta con cifratura o autenticazione, mentre 993 e 995 corrispondono di solito a IMAPS e POP3S. Restavano invece raggiungibili servizi in chiaro come POP3 e IMAP sulle porte 110 e 143, un dettaglio coerente con l’idea di aumentare le probabilità di intercettare traffico non cifrato.
Sull’ingresso iniziale nei server non esiste ancora una spiegazione unica e verificata. Alcune macchine risultavano compromesse già diverse settimane prima dell’avvio coordinato delle intercettazioni. In uno dei casi ricostruiti gli aggressori sembravano conoscere una password valida fin dal primo accesso osservato, ed è plausibile che provenisse da un altro sistema già violato. Ebury infatti raccoglie password, chiavi SSH e altre informazioni utili per spostarsi da una macchina all’altra.
La backdoor è studiata da ESET Research da oltre un decennio. Secondo l’azienda, dal 2009 Ebury avrebbe colpito circa 400.000 server Linux, FreeBSD e OpenBSD e oltre 100.000 risultavano ancora compromessi alla fine del 2023. Le versioni più recenti includono componenti userland rootkit capaci di nascondere agli amministratori processi, file, socket e memoria mappata. Un’altra pista porta ai provider di hosting, dato che precedenti indagini di ESET hanno documentato casi in cui gli attaccanti avevano compromesso infrastrutture dei fornitori per poi raggiungere da lì i server dei clienti.
Fonte: TecnoAndroid