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/shadow pentru 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țieExemple
Sistem Linux bazat pe muslAlpine Linux, OpenWrt, sisteme construite cu Buildroot sau Yocto
Serverul SSH este OpenSSH, fără PAMpachetul openssh-server din Alpine nu folosește PAM implicit
Autentificarea cu parolă este permisă în SSHPasswordAuthentication 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 e yes, 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 contul alpine, 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.

💿 Software
← Toate articolele
💬 Comentarii

Fii primul care comentează acest articol!

✍️ Lasă un comentariu
3 + 9 = ?