Una autenticazione bypassata da un bug di libreria C, non da OpenSSH

Il 5 novembre 2026 il ricercatore di sicurezza Ozgun Kultekin ha reso pubblico un bug di autenticazione in OpenSSH che da allora viene chiamato informalmente SSHole (CVE-2026-123158). Quello che lo rende interessante, oltre alla velocità con cui è stato armato, è la causa radice: non è un bug nel codice di OpenSSH, ma un’interazione inattesa tra OpenSSH e musl libc, la libreria C leggera usata da Alpine Linux e da moltissime immagini container minimali.

Il meccanismo, una volta spiegato, è quasi imbarazzante nella sua semplicità:

• negli account configurati per non accettare login via password, il campo hash in /etc/shadow viene impostato a un singolo asterisco (*) — una convenzione usata da decenni per dire “nessuna password valida, blocca il login”;
• quando un client invia una password eccezionalmente lunga, la funzione di hashing delle password di musl va in errore e, in quel caso, restituisce proprio il carattere * come risultato;
• OpenSSH confronta l’hash calcolato con l’hash memorizzato: se entrambi sono *, il confronto risulta positivo e il login viene autenticato.

In altre parole: una password abbastanza lunga da far fallire l’hashing produce, per un difetto di gestione dell’errore, lo stesso valore “sentinella” usato per dire “accesso negato”, e il controllo lo interpreta come un match. Gli account con un hash password valido e realistico non sono interessati dal bug — il problema riguarda specificamente gli account pensati per essere “senza password”, tipicamente usati per servizio, automazione o accesso solo a chiave.

Chi è esposto

Il bug colpisce le installazioni OpenSSH compilate contro musl libc — quindi in primo luogo Alpine Linux, estremamente diffusa in ambienti cloud e containerizzati per via delle immagini minimali. Perché l’exploit sia utile a un attaccante, l’account preso di mira deve avere privilegi amministrativi passwordless: in quel caso il risultato della falla è un accesso root diretto, senza bisogno di credenziali.

Da proof-of-concept a exploitation in meno di 40 ore

La cronologia ricostruita da più fonti di threat intelligence è sorprendentemente compressa:

• 5 novembre: pubblicazione del proof-of-concept e rilascio contestuale della patch, OpenSSH 10.6p2;
• 6 novembre: i primi tentativi di exploitation riuscita vengono registrati da diversi osservatori indipendenti;
• 7 novembre, 00:46 UTC: GreyNoise registra le prime catene di exploitation “in the wild” andate a buon fine — circa 40 ore dopo la pubblicazione della patch.

I dati raccolti dagli honeypot SSH del progetto Cowrie, analizzati da SANS ISC, confermano il quadro da un’angolazione diversa: i tentativi con password anomalamente lunghe iniziano a comparire il 1° novembre, salgono rapidamente fino a un picco di 713 tentativi il 6 novembre, per poi scendere a 51 l’8 novembre. I primi tentativi che sembrano mirare specificamente alla vulnerabilità — password composte da lunghe sequenze del carattere “A” ripetuto — risalgono al 5 novembre, in coincidenza con la disclosure. Tra i 18 indirizzi IP scanner più attivi identificati, cinque appartengono a Korea Telecom (AS4766), ma la provenienza è distribuita su numerosi hosting provider, VPS e telco nazionali.

Cosa fanno gli attaccanti una volta dentro

Secondo l’analisi di GreyNoise, una volta ottenuto l’accesso root gli attaccanti seguono uno schema piuttosto standard di post-exploitation:

• ricognizione del sistema e dei container in esecuzione, incluse query ai metadata service cloud (utili per risalire a credenziali IAM/instance role);
• tentativi di lettura degli hash delle password e delle chiavi SSH di root;
• modifica dei file authorized_keys per garantirsi persistenza indipendente dal bug originale.

In almeno un caso documentato, l’attaccante ha installato un impianto Python di command-and-control chiamato TAC Agent, capace di eseguire comandi shell, fare ricognizione, trasferire file e auto-aggiornarsi. L’impianto non ha persistenza integrata, quindi gli operatori hanno configurato manualmente un servizio di avvio automatico per sopravvivere ai reboot. Un dettaglio notato dai ricercatori: commenti e log interni del tool erano in cinese, e alcuni indizi comportamentali suggeriscono un’operatività almeno parzialmente automatizzata. Altri osservatori (watchTower) riportano anche attività di tipo botnet e cryptomining collegate alla stessa vulnerabilità.

Un’analisi separata dei log sugli stessi honeypot ha inoltre rilevato, fin dal 1° novembre, script di brute-force “mal scritti” che inserivano per errore comandi shell post-login direttamente nel campo password — alcuni dei quali potrebbero essere stati accettati, eseguendo quindi comandi arbitrari. Un esempio tipico scarica un binario x86_64 da un host remoto sulla porta 8000 in /tmp e lo rende eseguibile: un promemoria che, specie su sistemi esposti, anche bug “collaterali” nei tool degli attaccanti possono tradursi in esecuzione di codice non intenzionale.

Cosa fare subito

• Aggiornare OpenSSH alla versione 10.6p2 o successiva su ogni sistema basato su musl libc, a partire da Alpine Linux e dalle immagini container che la usano come base;
• in alternativa o come misura tampone, disabilitare l’autenticazione via password SSH sui sistemi affetti, lasciando solo l’autenticazione a chiave;
• login con password riuscite su account il cui campo in /etc/shadow è impostato a * — un evento che, per definizione, non dovrebbe mai accadere;
• authorized_keys per chiavi SSH non autorizzate aggiunte di recente;
• TAC Agent o comportamenti di persistenza anomali;

Conclusione

SSHole è un caso di scuola di come una convenzione vecchia di decenni (l’asterisco come “password impossibile”) possa trasformarsi in una falla critica quando una libreria di sistema gestisce male un caso d’errore. La finestra di circa 40 ore tra il rilascio della patch e la prima exploitation riuscita in the wild conferma, ancora una volta, che per vulnerabilità di autenticazione che toccano accessi root passwordless il tempo di reazione utile si misura in ore, non in giorni: chi gestisce flotte Alpine Linux o immagini container basate su musl dovrebbe trattare l’aggiornamento a OpenSSH 10.6p2 come priorità operativa immediata, non come voce in un prossimo ciclo di patching.

Fonti: BleepingComputer, SANS Internet Storm Center