Una campagna ha compromesso 333 nodi di uscita della rete Tor e li ha usati per deviare connessioni SSH verso server controllati dagli aggressori, con l'obiettivo di sottrarre password e osservare le sessioni. L'operazione e stata individuata all'inizio di ottobre da un ricercatore che pubblica con il nome kaba e collegata alla backdoor Linux Ebury.

I relay interessati rappresentavano circa un decimo dei nodi di uscita Tor analizzati durante la scansione. Il Tor Project ha rimosso i sistemi segnalati entro il 5 ottobre, ma gli utenti che hanno accettato una chiave host SSH inattesa o modificata durante quel periodo devono considerare compromesse le credenziali inserite.

Il dirottamento delle connessioni SSH

Il ricercatore ha notato un avviso relativo a una chiave host diversa durante una connessione SSH instradata attraverso Tor. La successiva verifica dei circa 3.000 exit relay disponibili il 2 ottobre ha mostrato che 333 nodi reindirizzavano il traffico sulla porta 22 verso lo stesso gruppo di 12 server di intercettazione.

Il cambio della chiave host era il segnale di un attacco man-in-the-middle: invece di raggiungere direttamente il server previsto, il client stabiliva la sessione con un sistema controllato dagli aggressori. Chi ignorava l'avviso e proseguiva con l'autenticazione poteva consegnare la password al server intermedio.

Il legame con Ebury

L'analisi di due server compromessi ha rilevato Ebury 1.8.3, una versione recente della famiglia malware attiva sui sistemi Linux da oltre un decennio. Ebury modifica componenti legati a OpenSSH, ruba credenziali e offre agli operatori accesso persistente ai sistemi infetti.

Secondo le ricostruzioni disponibili, gli aggressori potevano monitorare i comandi eseguiti nelle sessioni intercettate e tentare di estendere l'infezione ai server raggiunti. La presenza del malware su relay amministrati da soggetti diversi indica che la campagna sfruttava server gia compromessi per costruire un'infrastruttura di intercettazione distribuita.

Perche Tor non protegge da questo scenario

Tor nasconde l'origine del traffico e lo cifra all'interno della propria rete, ma il nodo di uscita gestisce l'ultimo tratto verso la destinazione. La sicurezza end-to-end deve quindi essere garantita dal protocollo applicativo. SSH offre questa protezione verificando l'identita del server attraverso la chiave host, ma l'utente deve fermarsi quando la chiave cambia senza una spiegazione valida.

L'episodio non dimostra una compromissione della crittografia di Tor. Mostra invece il rischio di affidarsi a un exit relay ostile e di ignorare i controlli di autenticita previsti dal protocollo usato sopra la rete anonima.

Le azioni raccomandate

Chi ha utilizzato SSH attraverso Tor nel periodo interessato e ha accettato una chiave nuova o modificata dovrebbe cambiare immediatamente la password, controllare le chiavi autorizzate e cercare accessi anomali sul server. Se la stessa credenziale e stata riutilizzata, deve essere ruotata anche sugli altri sistemi.

L'autenticazione SSH con chiavi robuste riduce il rischio rispetto alle password, ma richiede comunque la verifica dell'impronta del server attraverso un canale affidabile. Gli amministratori dei relay devono aggiornare i sistemi, disabilitare l'accesso SSH con password quando non necessario e verificare indicatori di Ebury e modifiche ai binari o alle librerie OpenSSH.