Pe unele sisteme Linux, o parolă foarte lungă poate deschide prin SSH conturi care, în teorie, nu acceptă deloc autentificarea cu parolă. Problema, botezată „*sshole”, afectează OpenSSH pe distribuțiile care folosesc biblioteca musl, cea mai cunoscută fiind Alpine Linux, atunci când autentificarea prin PAM este dezactivată. Pe Alpine, PAM este dezactivat implicit.
OpenSSH a publicat pe 5 noiembrie versiunea 10.6p2, care repară problema. Dacă ai un server, un container sau un echipament cu Alpine accesibil prin SSH, verifică acum dacă ești afectat. Mai jos ai comenzile.
Actualizare, 10 noiembrie: bug-ul e exploatat activ
Bug-ul, înregistrat oficial ca CVE-2026-123158, este folosit deja în atacuri reale. Un exploit demonstrativ a apărut la circa patru ore după reparație, iar firma GreyNoise a înregistrat prima exploatare reușită pe 7 noiembrie, la aproximativ 40 de ore după lansarea OpenSSH 10.6p2.
- GreyNoise a văzut 16 atacuri reușite asupra rețelelor-capcană pe care le monitorizează, venite de la șase adrese IP. Atacatorii au cercetat sistemul, au încercat să citească amprentele parolelor și cheile SSH ale contului root și să-și adauge propriile chei în
authorized_keys, ca să poată reveni. - Unul dintre atacatori a obținut drepturi de root și a instalat un program de control de la distanță scris în Python, numit „TAC Agent”. Comentariile din cod erau în chineză.
- watchTower a legat exploatarea de rețele de dispozitive infectate (botnet-uri) și de minare de criptomonede.
- Alte firme, precum Defused, vorbesc deocamdată de un număr mic de atacatori, nu de un atac în masă.
Pe lângă verificările de mai jos, caută chei SSH pe care nu le recunoști în fișierele authorized_keys și fișiere sau servicii de pornire legate de „TAC Agent”. Dacă serverul tău e afectat și nu l-ai actualizat încă, fă-o acum.
Cine a descoperit problema
Bug-ul a fost găsit de cercetătorul în securitate Ozgun Kultekin, care a publicat detaliile pe 5 noiembrie. Kultekin a folosit agenți AI ca să ruleze aproximativ 17.600 de teste de autentificare, cu diferite configurații OpenSSH, amprente de parolă deformate și parole supradimensionate. Problema există, potrivit lui, din 2016.
Cum funcționează, pe înțelesul tuturor
Pe Linux, parolele utilizatorilor nu sunt păstrate ca atare, ci sub forma unei amprente criptografice, în fișierul /etc/shadow. Conturile care nu trebuie să se poată autentifica cu parolă au adesea în acel loc un simplu asterisc, *. Niciun text introdus de un utilizator nu ar trebui să producă vreodată amprenta „*”.
Lanțul care duce la problemă are trei verigi:
- Corecția din 2016. Ca să nu poată afla un atacator ce conturi există pe server (vulnerabilitatea CVE-2016-6210), OpenSSH a început să calculeze amprenta parolei introduse chiar și pentru conturile fără parolă, folosind pentru calcul datele unui alt cont, care are o parolă reală. Astfel, răspunsul durează la fel de mult indiferent dacă utilizatorul există sau nu.
- Comportamentul musl. Funcția din musl care calculează amprenta returnează exact textul
*când calculul eșuează. Calculul eșuează, de exemplu, când parola are peste 256 de octeți. - Comparația. OpenSSH compară rezultatul, adică „*”, cu ce scrie în
/etc/shadowpentru acel cont, adică tot „*”. Cele două se potrivesc, iar autentificarea reușește.
Important: bug-ul nu permite ocolirea parolei la conturile care au o parolă reală. Afectează doar conturile marcate cu „*”.
Ești afectat dacă toate condițiile de mai jos sunt adevărate
| Condiție | Exemple |
|---|---|
| Sistem Linux bazat pe musl | Alpine Linux, OpenWrt, sisteme construite cu Buildroot sau Yocto |
| Serverul SSH este OpenSSH, fără PAM | pachetul openssh-server din Alpine nu folosește PAM implicit |
| Autentificarea cu parolă este permisă în SSH | PasswordAuthentication yes |
| Cel puțin un cont are „*” în loc de parolă | pe Alpine, inclusiv contul root |
| Cel puțin un alt cont are o parolă reală | orice utilizator obișnuit cu parolă |
Nu sunt afectate distribuțiile care folosesc biblioteca glibc, adică Debian, Ubuntu, Fedora și majoritatea serverelor Linux obișnuite, nici sistemele care folosesc PAM și nici serverul SSH Dropbear. OpenWrt folosește implicit Dropbear, deci routerele sunt expuse doar dacă cineva a instalat OpenSSH în locul lui.
Cel mai periculos caz semnalat de cercetător sunt imaginile oficiale Alpine pentru cloud, pe AWS și Azure. Ele vin cu un cont numit alpine care poate obține drepturi de administrator prin doas fără parolă. Un atacator care intră în acest cont poate ajunge, practic, la control total asupra serverului.
Cum verifici
Comenzile de mai jos se rulează ca administrator (root), pe sistemul pe care vrei să-l verifici.
- Ce sistem ai:
cat /etc/os-release. Dacă apare Alpine sau alt sistem bazat pe musl, continuă. - Ce versiune de OpenSSH: pe Alpine,
apk info -v openssh-server. Versiunile mai vechi de 10.6p2 sunt vulnerabile, dacă sunt îndeplinite și celelalte condiții. Distribuțiile pot publica reparația și ca revizie nouă a pachetului lor, așa că important e să rulezi actualizarea, nu doar să compari numărul versiunii. - Dacă e permisă parola:
sshd -T | grep -i passwordauthentication. Dacă răspunsul eyes, serverul acceptă parole. - Ce conturi au „*”:
awk -F: '$2=="*" {print $1}' /etc/shadow. - Dacă a fost deja exploatat: pe Alpine, caută autentificările reușite cu parolă:
grep "Accepted password" /var/log/messages. Dacă apare o autentificare cu parolă pe un cont care are „*” în/etc/shadow, de exemplu contulalpine, e foarte probabil ca problema să fi fost folosită.
Ce faci
- Actualizează OpenSSH. Pe Alpine:
apk update && apk upgrade openssh, apoi repornește serviciul SSH. - Dacă nu poți actualiza imediat, dezactivează autentificarea cu parolă: setează
PasswordAuthentication noîn/etc/ssh/sshd_configși repornește SSH. Înainte de asta, asigură-te că ai o cheie SSH funcțională, ca să nu rămâi blocat în afara serverului. - Dacă găsești urme de exploatare, tratează sistemul ca fiind compromis: schimbă cheile și parolele, verifică ce s-a instalat și, ideal, reinstalează-l de la zero.
Containerele Docker bazate pe Alpine nu rulează, de obicei, un server SSH, deci majoritatea nu sunt expuse. Verifică totuși imaginile proprii în care ai instalat openssh-server.
AI-ul găsește bug-uri vechi de ani de zile
Problema a stat ascunsă zece ani într-unul dintre cele mai verificate programe de securitate din lume și a ieșit la iveală abia când un cercetător a pus agenți AI să încerce mii de combinații. Este același tipar ca la GPT-6 Cyber, modelul OpenAI care a găsit 81 de vulnerabilități în Firefox, lansat în aceeași zi. Pentru administratori, concluzia e aceeași: bug-urile vor fi găsite mai repede, deci și actualizările trebuie instalate mai repede.
Surse: BleepingComputer (5 noiembrie: cercetătorul Ozgun Kultekin, cele circa 17.600 de teste făcute cu agenți AI, vechimea problemei, mecanismul, condițiile, sistemele afectate și neafectate, imaginile Alpine pentru AWS și Azure, comenzile de detectare, actualizarea și soluția temporară) și Start With Identity (5 noiembrie: lansarea OpenSSH 10.6p2 și formularea din notele de versiune, Dropbear neafectat, lipsa PAM implicit pe Alpine). Actualizarea din 10 noiembrie folosește BleepingComputer (9 noiembrie: numărul CVE, cronologia exploatării, observațiile GreyNoise, watchTower și Defused, activitatea atacatorilor, TAC Agent, recomandările). Comenzile de verificare a sistemului, a versiunii, a configurației și a conturilor cu „*”, precum și observațiile despre OpenWrt și Docker, sunt ale redacției.
Fii primul care comentează acest articol!