Ebury su 333 nodi di uscita Tor: password SSH intercettate

A inizio ottobre 2026 una parte consistente dei relay di uscita della rete Tor è stata usata per un attacco man-in-the-middle contro le connessioni SSH. La notizia è riportata da The Hacker News, Ars Technica e Insicurezza Digitale; secondo le ultime due i relay coinvolti sono 333, compromessi con Ebury, la backdoor per Linux documentata dal 2014. I dettagli che seguono vengono da Ars Technica e Insicurezza Digitale, che riprendono il rapporto pubblicato il 20 ottobre da un volontario di Tor che si firma Kaba e le informazioni del Tor Project.

Cosa è successo

Secondo Ars Technica l’intrusione è cominciata a fine agosto: l’attaccante è entrato nel server di gestione di un operatore di relay con una password valida e riutilizzata. Insicurezza Digitale data l’accesso al 28 agosto 2026 e aggiunge che la stessa password serviva per SSH, per sudo e come passphrase dei backup, ed era salvata in chiaro su due macchine; i privilegi di root sono arrivati in cinque minuti.

Da lì l’attaccante si è collegato in SSH a un secondo server, «Switzerland2», con una chiave RSA che non risulta tra le chiavi autorizzate, e vi ha installato Ebury. Come sia arrivato a controllare tutti i 333 relay non è stato chiarito: entrambe le testate citano l’ipotesi, non confermata, di un accesso a livello di provider di hosting.

Come funzionava l’intercettazione

I relay compromessi sono stati modificati nel file di configurazione torrc:

• SSH: le connessioni verso la porta 22 venivano dirottate verso uno di 12 server di intercettazione con una propria chiave host. Chi ignorava l’avviso «REMOTE HOST IDENTIFICATION HAS CHANGED» digitava la password sul server dell’attaccante, che inoltrava poi la sessione al server legittimo. Secondo Insicurezza Digitale alcuni middle relay sono stati anche trasformati in relay di uscita con la porta 22 aperta.
• Posta: venivano bloccate le porte della posta cifrata e lasciate aperte quelle in chiaro. Ars Technica elenca le porte 25, 465, 587, 993 e 995; Insicurezza Digitale cita 465, 587, 993 e 995. Non si sa se qualche downgrade sia riuscito.

Con un honeypot Kaba ha osservato cosa succedeva dopo la cattura della password: una prima connessione al server della vittima per osservare i comandi digitati, poi una seconda per installare Ebury. Insicurezza Digitale riporta i comandi visti (id -u, command -v sudo, sudo -n true), seguiti da un installer Perl con payload in base64 inviato tramite la libreria Python paramiko. Ogni password rubata diventava così un nuovo server infetto.

L’autenticazione a chiave pubblica non è esposta a questo schema: la firma è legata alla singola sessione e non si può inoltrare.

Tempi e risposta del Tor Project

Kaba ha ricevuto l’avviso sulla chiave host il 2 ottobre e ha poi provato uno per uno i circa 3.000 relay di uscita, verificando l’impronta SSH restituita da un server di test. Sulla finestra di attacco le fonti divergono di poco: Ars Technica indica dal 2 al 5 ottobre, Insicurezza Digitale dal 1° ottobre, quando 40 relay di 21 operatori hanno cambiato policy in cinque minuti e mezzo.

Secondo Insicurezza Digitale, il 4 ottobre il Tor Project ha contattato gli operatori e assegnato ai relay coinvolti i flag BadExit e MiddleOnly; il picco di capacità di uscita compromessa, per peso di consenso, è stato del 7,46%. Il 5 ottobre l’ultimo relay con la policy dell’attaccante è uscito dal consenso.

Ebury: cosa cercare sui server Linux

Insicurezza Digitale riferisce che la versione trovata è la 1.8.3, più recente di quella degli indicatori pubblici di ESET (1.8.2). Ebury si presenta come la libreria di sistema libkeyutils.so, non modifica i binari di sshd e sudo, supera i controlli dpkg -V e debsums, non lascia tracce nei log di accesso standard e sopravvive ai riavvii.

Indicatori pubblicati da Insicurezza Digitale:

• file /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 che non appartiene ad alcun pacchetto (hash diverso su ogni host), puntato dal link libkeyutils.so.1;
• socket UNIX astratto @event-0YsOG9WSOE;
• processi falsi rsyslogd, systemd-udevd e arpd, e un processo nascosto snf;
• chiavi SSH dell’infrastruttura dell’attaccante: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E (la stessa dell’avviso riportato da Ars Technica), ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y, RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo;
• indirizzo del primo accesso, il 28 agosto: 185.225.226.62.

Mappatura MITRE ATT&CK indicativa, ricavata dai fatti riportati: T1078 (Valid Accounts), T1021.004 (Remote Services: SSH), T1557 (Adversary-in-the-Middle), T1014 (Rootkit), T1036 (Masquerading).

Impatto per le aziende europee e italiane

Il rischio diretto riguarda chi ha amministrato server con password SSH passando da Tor nei primi giorni di ottobre, compresi consulenti e fornitori: la password intercettata ha portato a una backdoor sul server raggiunto. La causa di fondo, una password riutilizzata tra SSH, sudo e backup, riguarda però qualsiasi parco Linux. Per i soggetti NIS2, autenticazione, igiene informatica e sicurezza dei fornitori rientrano nelle misure dell’articolo 21. E le caselle che accettano ancora IMAP e POP3 in chiaro espongono le credenziali su qualunque rete non fidata, non solo su Tor.

Cosa fare subito

1. Chiedi chi usa Tor per raggiungere i server aziendali. Se qualcuno ha accettato una chiave host sconosciuta tra l’1 e il 5 ottobre, considera la password compromessa, cambiala ovunque sia stata riutilizzata e controlla il server raggiunto.
2. Disattiva l’accesso SSH con password (PasswordAuthentication no) e usa chiavi o certificati. Non riutilizzare la stessa password per SSH, sudo e backup.
3. Non ignorare mai l’avviso di chiave host cambiata: StrictHostKeyChecking yes con known_hosts gestiti centralmente, oppure certificati host.
4. Cerca gli indicatori: verifica con dpkg -S o rpm -qf a quale pacchetto appartiene libkeyutils e cerca il socket astratto con ss -xa. Insicurezza Digitale suggerisce di aprire la shell con H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash per aggirare il rootkit; dove possibile, analizza il disco a macchina spenta.
5. Host compromesso: il Tor Project indica agli operatori di metterlo offline, conservare disco e log, reinstallare da zero e ruotare tutte le credenziali presenti.
6. Posta: rifiuta IMAP e POP3 in chiaro e accetta l’autenticazione solo su TLS.

Come aiuta ARXDOME

ARX Expose mostra le porte aperte e la configurazione della posta visibili da fuori. Sui server Linux l’agent di ARX Sentry raccoglie l’inventario di processi e porte e controlla l’integrità dei file nelle cartelle stabilite, mentre ARX Shield verifica l’hardening secondo i benchmark CIS. ARX Horizon arricchisce ogni connessione con paese, operatore e liste di minacce, così un accesso SSH da un indirizzo insolito si distingue subito.

Ultimo aggiornamento: 22 ottobre 2026