Tor, 333 exit relay compromessi: SSH deviato e posta spinta verso il testo in chiaro

A inizio ottobre circa un exit relay Tor su dieci è stato trasformato in silenzio in una trappola per password SSH. Un ricercatore che pubblica con lo pseudonimo kaba ha analizzato il 2 ottobre tutti i circa 3.000 exit di Tor e ne ha trovati 333 che reindirizzavano l'SSH verso gli stessi 12 server di intercettazione. Nella crittografia di Tor non si è rotto nulla. Gli attaccanti hanno preso il controllo degli host Linux sottostanti ai relay e hanno riscritto un file di testo.

01Come sono stati manipolati i relay

Un exit relay instrada il traffico solo verso le porte consentite dalla sua exit policy, che risiede nel file di configurazione torrc del relay. A partire dal 1° ottobre gli attaccanti hanno riscritto queste policy per aprire la porta 22. In questo modo l'SSH è stato abilitato su 342 relay che lo bloccavano e 24 relay non-exit sono diventati exit.

L'unica via d'ingresso documentata per intero è l'infrastruttura di un operatore di relay, non i sistemi del Tor Project. Il riepilogo di Ars Technica la definisce «Tor management server», ma il post-mortem la descrive in modo diverso. Si trattava del VPS Contabo dell'operatore, che faceva da gateway WireGuard, jump host SSH e bridge obfs4. Una seconda macchina, Switzerland2, era un VPS FranTech su cui giravano due exit relay dell'operatore. L'attaccante ha usato la password dell'operatore, che ha funzionato al primo tentativo, e cinque minuti dopo aveva i privilegi di root. Ciò coincide con la ricostruzione di Ars, che parla di una password riutilizzata.

Su quel server è stato installato Ebury 1.8.3. Circa un'ora dopo, Switzerland2 ha accettato un login con una chiave RSA che non compariva in nessuno dei suoi file authorized_keys, e Ebury vi è stato installato un secondo più tardi. L'operatore afferma che resta aperta la questione di come quella chiave sia stata accettata. Marc-Etienne Léveillé, che segue Ebury da 13 anni, ha suggerito sulla mailing list che Ebury potesse essere presente già prima e che sia stato aggiornato il 30 settembre. Ha inoltre indicato come possibilità un hosting provider compromesso.

Il post-mortem dell'operatore mostra come l'attaccante abbia riscritto la policy su Switzerland2. La lista di accept di 60 intervalli di porte generata da ansible è stata rimossa. Dopo «# end of torrc» sono state aggiunte cinque righe di reject per le porte 25, 465, 587, 993 e 995. Entrambi i relay di Switzerland2 hanno pubblicato il risultato alle 09:34:04 del 2 ottobre.

Come siano caduti gli altri relay non è ancora chiaro. Ars precisa che gli investigatori non hanno stabilito come siano stati violati tutti i 333 server sottostanti. Un indizio punta però all'hosting: 71 dei 101 relay di terze parti presso FranTech Solutions sono stati alterati, contro 13 dei 9.054 relay ospitati altrove. Si tratta di una correlazione, non della prova di una violazione del provider.

02I due payload: SSH e posta

SSH. Il traffico verso la porta 22 lasciava gli exit compromessi diretto a uno dei 12 server di intercettazione. L'interceptor presentava una propria host key, registrava ogni password digitata e poi si collegava al vero server, in modo che la sessione apparisse normale. Un utente che ignorava l'avviso di host key modificata di OpenSSH esponeva quindi le proprie credenziali e dava all'attaccante una visione in tempo reale della sessione. Ars riferisce anche di un terzo passaggio: l'attaccante apriva un'ulteriore connessione per tentare di installare Ebury sulla destinazione. Nell'honeypot di kaba il client dell'attaccante si identificava come paramiko, verificava l'ID utente e il sudo senza password, poi eseguiva un comando Perl codificato in base64 per installare Ebury.

Il rilevamento è stato più difficile di quanto lasci intendere l'avviso. Solo una dozzina circa di exit presentava una host key falsa. Gli altri 300 o giù di lì instradavano il traffico attraverso gli stessi server senza modificare la chiave. Un utente che raggiungeva un server tramite uno di questi exit non notava nulla di strano, ma il server vedeva una connessione proveniente dall'indirizzo di un interceptor anziché da quello dell'exit.

Posta. La modifica sulla posta è più sottile di quanto suggerisca la sintesi di Ars, perché non tutte le porte bloccate sono solo cifrate. L'analisi dell'operatore classifica come «TLS optional» le porte 25, 587 e la coppia 110/143. Solo 465, 993 e 995 sono porte a TLS implicito. La policy finale bloccava l'invio della posta e la lettura cifrata, ma lasciava aperti POP3 (110) e IMAP (143) in chiaro. L'operatore osserva inoltre che la prima policy provata dall'attaccante era l'opposto: bloccava POP3 e IMAP in chiaro ed è stata sostituita da quella poi andata in produzione.

L'inferenza è che i client configurati per tentare TLS e ripiegare sul testo in chiaro sarebbero stati spinti verso il cleartext. Un exit relay legge tutto ciò che esce in chiaro e può anche eliminare la negoziazione STARTTLS. Sulla maggior parte dei relay la modifica ha anche aperto POP3 e IMAP in chiaro. Se un client di posta abbia effettivamente subìto un downgrade non è noto, come nota Ars.

03Dimensioni, durata e bonifica

Ars colloca il dirottamento tra il 2 e il 5 ottobre. Altre ricostruzioni calcolano in modo diverso la finestra della policy. La policy di Switzerland2 è rimasta attiva per circa 52 ore su due relay Guard+Exit che movimentavano circa 3,4 TiB al giorno. Ebury risale a ben prima della campagna: nel 2024 ESET stimava che avesse infettato circa 400.000 server Linux dal 2009.

• Quota della rete: al picco, il 4 ottobre alle 01:00 UTC, i relay dirottati trasportavano il 7,46% dell'exit weight utilizzabile di Tor.
• Corrispondenza più ampia della policy: un'analisi dei dati delle directory ha contato 377 relay gestiti da 59 operatori che tra il 1° e il 4 ottobre hanno adottato la exit policy dell'attaccante. L'analisi stessa la definisce una corrispondenza di policy, non una prova di compromissione.
• Risposta: kaba ha segnalato il problema la sera del 2 ottobre. Le directory authority hanno iniziato ad applicare il flag BadExit la sera del 4 ottobre e, entro le 17:00 UTC del 5 ottobre, nel consensus non restava alcun relay con la policy dell'attaccante. Quando gli attaccanti hanno riavviato molti relay il 5 ottobre, i flag li hanno limitati al ruolo di middle relay.

Kaba riferisce che il team Network Health di Tor gli ha detto di non aver mai visto prima un attacco simile.

04Cosa dice questo episodio sul modello di fiducia di Tor

Tor separa chi sei da ciò che invii e non protegge il contenuto una volta che esce dall'exit. Il consiglio di lunga data del Tor Project è usare la crittografia end-to-end, come HTTPS, perché l'exit vede il traffico in chiaro. Gli abusi degli exit non sono una novità. Uno studio della Karlstad University del 2014 ha individuato 19 exit relay che usavano certificati autofirmati per attacchi man-in-the-middle su HTTPS e SSH. Nel 2020 il ricercatore nusenu ha segnalato attaccanti che al picco gestivano 380 exit relay, dando agli utenti circa una probabilità su quattro di incappare in un exit malevolo.

Ciò che distingue questo caso è il meccanismo. Erano relay di operatori onesti, alterati tramite una normale compromissione dell'host, e la leva era l'exit policy. Il team Network Health ha descritto l'attaccante come qualcuno che modifica i file torrc per trasformare relay non-exit in exit. La difesa che ha funzionato è stata l'osservazione esterna: la scansione con exitmap, i dati delle directory e un ricercatore che si è rifiutato di ignorare un avviso. Aiuta anche la vista a livello di famiglia: la query Onionoo dell'operatore ha mostrato 168 relay su 57 IP che pubblicizzavano la stessa policy quasi del tutto aperta. La rete Tor si affida al fatto che gli host dei volontari restino integri, e una singola credenziale trapelata può diventare un evento a livello di rete.

05Rilevamento e mitigazione

Per utenti e amministratori SSH:

1. Trattate un avviso di host key modificata come un incidente. Chi ha digitato una password dopo aver accettato una nuova chiave deve considerarla rubata, cambiarla e verificare la presenza di Ebury sulla destinazione.
2. Disattivate l'autenticazione con password a favore delle chiavi, come raccomanda Ars. Un attacco man-in-the-middle non cattura così nulla di riutilizzabile. Fissate le host key con il controllo rigoroso (strict checking) oppure usate i certificati SSH.
3. Dove possibile, raggiungete i servizi amministrativi tramite un onion service, in modo che non sia coinvolto alcun exit. È una pratica generale, non qualcosa che le fonti trattano.
4. Usate il TLS implicito (465, 993, 995) e configurate i client perché rifiutino il cleartext invece di ripiegarvi.

Per gli operatori di relay e i team di rete:

• Impostate un alert su qualsiasi modifica dell'exit policy che il vostro sistema di gestione della configurazione non abbia effettuato. Confrontate il descriptor pubblicato con quello previsto.
• Eseguite sonde canary attraverso gli exit, come ha fatto kaba, verificando sia la chiave presentata sia l'indirizzo sorgente visto dalla destinazione.
• Non riutilizzate le password degli operatori e imponete l'accesso con sole chiavi sui jump host.
• Partite dal presupposto che un host dall'aspetto pulito possa non esserlo. Ebury 1.8.3 è più recente degli indicatori pubblici di ESET e l'operatore non ha trovato alcun redirect NAT, nuovi utenti o binari tor modificati. I login tramite backdoor non lasciano né registri di accesso né cronologia della shell. Gli esperti consigliano di spegnere i relay, fare lo snapshot del disco e ricostruire da zero anziché ripulire sul posto.

06Cosa resta non dimostrato

Diverse questioni restano aperte: come si sia avuto accesso agli altri relay, perché Switzerland2 abbia accettato la chiave non presente nell'elenco e chi ci sia dietro. Kaba sostiene che l'uso di Ebury e la raccolta di dati non cifrati indichino un gruppo con motivazioni finanziarie, ma precisa che si tratta di una speculazione. Secondo Léveillé, data la diffusione di Ebury, è molto probabile che esistano altri relay Tor compromessi. Nessuno ha dimostrato quante password siano state catturate né se sia stata effettivamente declassata qualche comunicazione di posta.