Noduri de ieșire Tor deturnate au transformat autentificările SSH cu parolă într-o capcană

Timp de aproximativ patru zile, la începutul lui octombrie, oricine se conecta la un server SSH prin Tor folosind o parolă risca să și-o piardă. Un atacator a preluat controlul a peste 300 de noduri de ieșire (exit relays) Tor, a redirecționat traficul SSH către câteva servere de interceptare și a colectat credențialele care treceau pe acolo.

Ce s-a întâmplat

Între 1 și 5 octombrie 2026, sute de noduri Tor au avut politica de ieșire rescrisă astfel încât să permită SSH (portul 22) și Telnet. Pe cele mai multe, porturile de e-mail criptate (IMAPS, POP3S) au fost închise, iar cele necriptate au fost deschise. Unele noduri care nu fuseseră niciodată de ieșire au fost transformate în noduri de ieșire.

Un cercetător independent a descoperit problema pe 2 octombrie, după ce a primit un avertisment de schimbare a cheii de host la o conexiune SSH prin Tor. A testat apoi fiecare nod de ieșire și a găsit 333 de noduri care trimiteau traficul SSH către aceleași 12 servere de interceptare. O analiză separată a datelor publice din directorul Tor a numărat 377 de noduri de la 59 de operatori care au preluat politica atacatorului. La vârf, acestea transportau circa 7,5% din capacitatea de ieșire a rețelei Tor. Analiza precizează că o politică identică nu dovedește că nodul a fost compromis.

Echipa Tor Project responsabilă de sănătatea rețelei a marcat nodurile ca BadExit pe 4 octombrie. Până la ora 17:00 UTC pe 5 octombrie, niciunul nu mai era în consens.

Cum a funcționat interceptarea

Interceptorul termina sesiunea SSH a victimei pe propriul server și deschidea o a doua sesiune către serverul real. Era deci un atac clasic de tip man-in-the-middle:

Autentificările cu parolă erau expuse. Parola circulă în sesiunea criptată până la serverul de la celălalt capăt, care aici era atacatorul. Interceptorul lăsa sesiunea să meargă normal, putea urmări comenzile tastate și se putea autentifica separat cu parola furată pentru a verifica drepturile sudo și a instala un program în Perl.
Autentificările cu cheie nu erau expuse. O semnătură cu cheie publică SSH este legată de sesiunea respectivă și nu poate fi refolosită pe serverul real. În cel mai rău caz, interceptorul putea afișa un shell fals.
Avertismentul de cheie schimbată era semnalul de alarmă. Cei care cunoșteau deja serverul vedeau avertismentul OpenSSH „remote host identification has changed”. Cei care se conectau prima dată vedeau doar cererea obișnuită de a accepta o cheie nouă.

De ce contează: cauza a fost una banală

Cea mai mare familie de noduri afectată a fost compromisă prin serverul său de administrare expus la internet. Operatorul a identificat ulterior cauza: aceeași parolă folosită pentru SSH, sudo și backup-uri, păstrată în clar, plus autentificarea SSH cu parolă lăsată activă. Atacatorul s-a autentificat din prima încercare la sfârșitul lui august, a obținut drepturi root în câteva minute, a instalat backdoor-ul Ebury pentru OpenSSH (versiunea 1.8.3) și a trecut apoi pe un al doilea server.

Această versiune de Ebury se ascunde într-o singură bibliotecă setuid (libkeyutils.so.1.10.2) care nu aparține niciunui pachet. Bibliotecile din pachete rămân neatinse, așa că dpkg -V și debsums nu găsesc nimic, iar versiunea e mai nouă decât indicatorii publici. A rezistat și unei reporniri. Ebury există din 2009 și a infectat sute de mii de servere, deci foarte probabil mai există și alte gazde compromise.

Nu se știe încă cum au fost compromise mașinile celorlalți operatori. Nodurile afectate erau concentrate la un singur furnizor de hosting, ceea ce ridică posibilitatea unei compromiteri la nivelul furnizorului, însă acest lucru nu este confirmat. Nu se știe nici cine se află în spatele campaniei.

Ce trebuie făcut

Dacă folosiți SSH prin Tor (sau prin orice rețea nesigură):

Dacă ați acceptat o cheie de host necunoscută sau schimbată prin Tor între 1 și 5 octombrie, considerați parola tastată ca fiind furată. Schimbați-o și verificați serverul pentru semne de compromitere.
Folosiți autentificarea cu chei și dezactivați PasswordAuthentication pe serverele SSH expuse la internet.
Nu ignorați niciodată avertismentul de cheie de host schimbată. Verificați amprenta pe un canal separat sau publicați-o prin SSHFP/DNSSEC.

Dacă administrați servere Linux (noduri Tor sau nu):

Căutați un fișier setuid libkeyutils.so.1.10.2 care nu aparține niciunui pachet și un link libkeyutils.so.1 care indică spre el. Verificați și socket-uri UNIX abstracte neașteptate, daemoni de sistem falși care rulează în cgroup-ul ssh.service, reguli NAT care redirecționează portul 22, precum și utilizatori, intrări authorized_keys, joburi cron sau unități systemd necunoscute.
Investigați, pe cât posibil, dintr-un sistem de recovery sau dintr-o imagine offline a discului. Pe un server activ, autentificați-vă cu cheie, niciodată cu parolă, pentru că Ebury captează credențialele tastate.
Dacă găsiți implantul: scoateți serverul din funcțiune, păstrați discul și logurile, reinstalați în loc să curățați, schimbați toate credențialele și cheile care au fost pe server și (pentru operatorii Tor) generați o nouă identitate de nod și raportați incidentul pe lista bad-relays a Tor Project.
Renunțați la reutilizarea parolelor și la secretele păstrate în clar, mai ales pe serverele de administrare și jump host-uri.

Campania a pornit de la un server de administrare expus la internet care încă accepta autentificarea SSH cu parolă. Este o expunere ușor de trecut cu vederea și ușor de găsit. Serviciul nostru de Attack Surface Management monitorizează continuu gazdele expuse la internet și semnalează astfel de expuneri riscante înainte ca un atacator să profite de ele.

Știre relatată inițial de The Hacker News. Rezumat realizat de echipa 4Tify.