L’incidente dei relay Tor mostra perché un avviso SSH richiede una pausa
Un ricercatore ha individuato 333 nodi di uscita coinvolti. Il caso distingue anonimato del percorso, autenticazione della destinazione e sicurezza dei server intermedi.
Un avviso inatteso sulla chiave SSH di un server ha portato un ricercatore a individuare 333 relay di uscita Tor coinvolti in una campagna di intercettazione. L’indagine pubblicata da Kaba il 20 ottobre descrive traffico deviato attraverso server controllati dagli aggressori durante un episodio avvenuto all’inizio del mese. I nodi interessati sono stati successivamente rimossi dal servizio, ma l’avviso che ha rivelato l’attacco resta una decisione quotidiana per chi amministra macchine remote.
La distinzione centrale è tra nascondere l’origine di una connessione e autenticarne la destinazione. Tor modifica il percorso del traffico. Non rende affidabile una chiave sconosciuta e non trasforma un protocollo applicativo in chiaro in una comunicazione cifrata da un’estremità all’altra.
L’avviso è servito proprio perché ha interrotto il lavoro
SSH ricorda l’identità del server per confrontarla con quella presentata nelle connessioni successive. Una chiave diversa può avere una spiegazione legittima, per esempio la reinstallazione della macchina. Può anche indicare che il collegamento è arrivato altrove. Il programma non può risolvere il dubbio soltanto perché l’utente desidera continuare.
Kaba racconta di aver ricevuto un’impronta differente dopo la deviazione della connessione. L’indagine ha controllato sia la chiave presentata al client sia l’origine del collegamento osservata dal server previsto. Il secondo controllo contava: non tutti i percorsi coinvolti mostravano lo stesso comportamento di intercettazione visibile.
La risposta prudente a una sorpresa è verificare la nuova identità attraverso un canale indipendente e affidabile. Cancellare automaticamente la chiave memorizzata elimina proprio il confronto che ha reso visibile l’anomalia. Il fatto che sia di nuovo comodo collegarsi non dimostra che la differenza fosse innocua.
Anche una rete di relay usa server ordinari
Il resoconto degli operatori coinvolti descrive una password riutilizzata su un server di gestione e la presenza della backdoor Ebury. L’esame dettagliato riguarda due server: gli autori lasciano esplicitamente aperto il modo in cui sia stato raggiunto l’intero gruppo di host coinvolti. Il limite deve restare chiaro anche nel riassumere l’incidente.
La macchina di gestione era particolarmente importante perché collegava amministrazione, automazioni e backup. Credenziali e accessi comodi per il lavoro quotidiano offrivano anche percorsi all’intruso. Cifrare un backup protegge meno quando la password necessaria per leggerlo è lo stesso segreto già disponibile sul sistema compromesso.
Il rapporto spiega inoltre perché il controllo dei checksum dei pacchetti non fosse sufficiente. Il componente malevolo conviveva con una libreria del pacchetto rimasta intatta, mentre cambiava il modo di caricarla. Verificare che i file distribuiti non siano stati modificati risponde a una domanda più limitata rispetto a stabilire se il processo in esecuzione abbia caricato soltanto codice affidabile.
La cifratura deve arrivare alla destinazione giusta
I ricercatori descrivono modifiche alle politiche dei relay che riguardavano anche la posta. Bloccare i percorsi cifrati lasciando disponibili alternative in chiaro crea un’opportunità pericolosa se un’applicazione ripiega su queste ultime. Non dimostra che sia stata letta la posta di ogni utente coinvolto, né che il traffico web cifrato e correttamente autenticato sia stato decifrato.
La distinzione evita due conclusioni sbagliate: considerare esposta qualsiasi comunicazione Tor, oppure presumere che una rete per la privacy compensi ogni scelta dell’applicazione. Percorso di rete, cifratura applicativa e identità della destinazione restano protezioni separate.
Gli operatori hanno ritirato l’infrastruttura interessata e Kaba riconosce l’intervento del gruppo che segue la salute della rete nella rimozione dei nodi identificati. L’attribuzione e l’intera catena di accesso iniziale rimangono irrisolte. Davanti a un’impronta SSH cambiata, però, la lezione pratica non dipende dal nome dell’aggressore. L’interruzione potrebbe essere proprio la parte del collegamento che sta funzionando correttamente.