Un gruppo di hacker ha dirottato 333 nodi di uscita Tor e ne ha modificato la configurazione per intercettare connessioni SSH e favorire il passaggio di email non cifrate. Il caso, ricostruito da un volontario del progetto Tor, ha coinvolto nodi usati tra il 2 e il 5 ottobre.
Il traffico web cifrato sarebbe stato inoltrato normalmente. Il rischio riguardava invece chi avviava una connessione SSH e ignorava l’avviso relativo alla modifica della chiave dell’host, oltre a eventuali servizi email che avessero degradato una connessione protetta a una non cifrata.
Come è iniziata la compromissione
Secondo i volontari di Tor, l’accesso iniziale sarebbe avvenuto alla fine di agosto attraverso una password valida ma riutilizzata, usata per entrare in un server di gestione della rete. Gli aggressori vi avrebbero poi installato Ebury, una backdoor per Linux scoperta dodici anni fa.
Da quel sistema, l’attaccante si sarebbe collegato via SSH a un secondo server Tor, chiamato Switzerland2, usando una chiave RSA. C’è però un punto che gli investigatori non sono riusciti a chiarire: quella chiave non è stata trovata tra le chiavi autorizzate di Switzerland2.
Ottenuto il controllo amministrativo del server, gli aggressori avrebbero installato Ebury anche lì e modificato le impostazioni di due nodi di uscita ospitati dalla macchina. Non è invece ancora noto come abbiano acquisito il controllo di tutti i server coinvolti successivamente nella campagna.
Il dirottamento delle connessioni SSH
Un nodo di uscita Tor è il punto dal quale il traffico lascia la rete Tor per raggiungere Internet. Nel caso ricostruito, una parte delle modifiche reindirizzava le connessioni SSH sulla porta 22 verso uno di 12 server di intercettazione controllati dagli aggressori.
La tecnica non aggirava automaticamente le protezioni di SSH. Il client doveva segnalare che la chiave dell’host remoto era cambiata: chi avesse ignorato quell’avviso e proseguito avrebbe potuto consegnare la propria password SSH al server falso.
Il volontario Tor autore della ricostruzione riferisce di essersi imbattuto personalmente nell’avviso venerdì mattina, dopo essere uscito dalla rete attraverso uno dei 333 nodi compromessi. A prima vista, il comportamento poteva apparire normale perché il traffico web cifrato continuava a essere inoltrato.
Il tentativo contro l’email cifrata
La seconda modifica puntava ai protocolli di posta elettronica. I nodi compromessi bloccavano le porte 25, 465, 587, 993 e 995, associate a varie modalità di invio e ricezione email cifrata, lasciando invece transitare il traffico per la ricezione della posta non cifrata.
L’obiettivo era indurre eventuali servizi email a passare da una connessione protetta a una non protetta. Se il downgrade fosse avvenuto, chi controllava il nodo di uscita avrebbe potuto leggere i messaggi in chiaro. La ricostruzione non stabilisce però se questi tentativi abbiano avuto successo né se siano state sottratte comunicazioni.
È una distinzione importante: l’episodio documenta una campagna progettata per intercettare credenziali SSH e posta non cifrata, ma non conferma che gli aggressori abbiano ottenuto password o contenuti email specifici.
Perché gli avvisi SSH restano decisivi
Tor protegge il percorso del traffico all’interno della propria rete, ma un nodo di uscita è comunque nella posizione di osservare ciò che esce verso Internet quando il protocollo usato non applica una cifratura adeguata. Per SSH, la verifica della chiave dell’host serve proprio a rilevare che il server contattato non corrisponde più a quello atteso.
In questo caso, ignorare l’avviso sulla chiave cambiata avrebbe trasformato un segnale di allarme in una possibile esposizione delle credenziali. Per l’email, il limite era altrettanto netto: l’intercettazione dipendeva dal fatto che una connessione venisse effettivamente degradata e proseguisse senza cifratura.
Domande frequenti
Tutto il traffico passato dai 333 nodi era leggibile?
No. La ricostruzione indica che il traffico web cifrato veniva inoltrato normalmente. L’operazione prendeva di mira in particolare le connessioni SSH reindirizzate e le eventuali email passate a modalità non cifrata.
Che cosa doveva accadere perché venisse intercettata una password SSH?
L’utente doveva ricevere l’avviso di cambio della chiave dell’host, ignorarlo e inserire comunque la password nel collegamento reindirizzato verso un server controllato dagli aggressori.
È confermato che le email siano state lette?
No. I nodi bloccavano alcune porte usate per email cifrata nel tentativo di favorire connessioni non protette, ma non è chiaro se il downgrade sia riuscito in casi concreti.
Considerazioni finali
La parte più preoccupante dell’episodio non è soltanto il numero dei nodi coinvolti, ma il fatto che il dirottamento potesse restare poco visibile finché il traffico usato appariva cifrato e regolare. La campagna sfruttava punti molto concreti: un avviso SSH ignorato e una comunicazione email che rinuncia alla cifratura.
La ricostruzione evita conclusioni non dimostrate su password o messaggi sottratti, ed è un limite informativo corretto. Resta però un dato netto: i 333 nodi di uscita Tor sono stati configurati per spostare connessioni SSH verso server degli aggressori e per cercare di esporre posta elettronica in chiaro.
