Tra il 2 e il 5 ottobre 2026, una campagna ha reindirizzato connessioni SSH attraverso relay di uscita di Tor compromessi. Il 20 ottobre il volontario Tor Kaba ha riferito che un test su circa 3.000 relay ne aveva individuati 333 che inviavano il traffico SSH a 12 server di intercettazione.
Che cosa contano 333 e 377 relay
Kaba ha usato exitmap e due server di test: uno controllava l’impronta della chiave host SSH, l’altro verificava se la connessione arrivasse dal relay scelto o da un server di intercettazione. La scansione ha rilevato 333 relay che reindirizzavano SSH. In circa una dozzina compariva un’impronta falsa; oltre 300 inoltravano le connessioni senza modificarla.
Un’analisi distinta dei dati di directory ha contato 377 relay con policy di uscita compatibili con lo schema dell’attacco. Quel conteggio riguarda corrispondenze di policy, non connessioni SSH dirottate verificate con la scansione di Kaba.
| Misurazione | Numero | Metodo e significato |
| Relay che reindirizzavano SSH | 333 | Test exitmap su circa 3.000 relay, con controlli sull’impronta SSH e sulla provenienza della connessione. |
| Relay con policy di uscita corrispondente | 377 | Analisi dei dati di directory; la corrispondenza della policy non verifica da sola una redirezione SSH. |
Quando una password SSH poteva essere esposta
Il rischio descritto riguardava chi, dopo essere stato reindirizzato, accettava la chiave host del server di intercettazione e inseriva una password. La chiave host serve a riconoscere il server: se cambia una chiave già registrata, SSH mostra un avviso; alla prima connessione può invece apparire la normale richiesta di accettarla.
L’autenticazione del client con chiave pubblica è un passaggio diverso. La firma è legata alla sessione SSH e non può essere semplicemente riutilizzata per autenticarsi al server reale. Questo è il motivo per cui il metodo descritto non permetteva di sottrarre la password in quel modo tramite un’autenticazione a chiave pubblica. La distinzione è descritta anche nell’RFC 4252.
La campagna riguardava connessioni SSH che uscivano da Tor verso destinazioni non onion. Una connessione SSH a un servizio onion resta all’interno di Tor e non passa da un relay di uscita.
Le porte email e il riscontro su due server
Nel post-mortem pubblicato il 7 ottobre, l’operatore Zimmer ha descritto una policy modificata su due relay Switzerland2: bloccava le porte 25, 465, 587, 993 e 995, ma consentiva POP3 sulla porta 110 e IMAP sulla porta 143, protocolli utilizzabili senza cifratura. La modifica poteva quindi esporre le email se una connessione fosse passata a una modalità in chiaro; il resoconto dell’incidente non documenta un’intercettazione riuscita.
Zimmer ha riferito di aver trovato Ebury 1.8.3 su due server: una macchina di gestione e Switzerland2. Secondo la sua ricostruzione, il 28 agosto un aggressore aveva usato una password riutilizzata per accedere al server di gestione, dove era attiva anche l’autenticazione SSH con password. Questi riscontri riguardano i due server esaminati da Zimmer, non tutti i relay coinvolti nella campagna.
Che cosa ha raccomandato il Tor Project
Il Tor Project ha segnalato il 4 ottobre relay compromessi e ha riferito che quelli interessati venivano contrassegnati e respinti dalle autorità di directory. Nell’avviso agli operatori pubblicato il 5 ottobre, ha raccomandato di controllare la configurazione di Tor, le policy di uscita, le regole di rete, i processi, le connessioni in uscita, i pacchetti installati, gli account e i meccanismi di avvio automatico.
Per un relay Linux sospettato di compromissione, il Tor Project ha indicato di interromperne l’attività, conservare disco e log, reinstallare il sistema, sostituire l’identità del relay e cambiare le credenziali presenti sull’host. L’avviso del Tor Project agli operatori riporta la sequenza di controlli e interventi.
