SSHole consente già di accedere ai server Linux con configurazioni vulnerabili di OpenSSH: gli aggressori possono aggirare l'autenticazione, eseguire comandi, cercare credenziali e tentare di mantenere l'accesso. Diverse società di sicurezza hanno rilevato tentativi e sfruttamenti riusciti fin dai primi giorni di novembre, e GreyNoise ha registrato un caso in cui l'intruso ha ottenuto i privilegi di root.
La vulnerabilità, identificata come CVE-2026-123158, interessa i sistemi che soddisfano condizioni specifiche, non qualsiasi installazione di OpenSSH. La correzione è arrivata con OpenSSH 10.6p2, pubblicato il 5 novembre. Gli amministratori che non possono ancora aggiornare possono disattivare l'autenticazione tramite password, anche se ciò impedisce l'accesso a chi ne dipende ancora.
Una vulnerabilità legata a musl e agli account con password disabilitata
Il ricercatore di sicurezza Özgün Kültekin ha divulgato SSHole la settimana scorsa. Il problema riguarda il modo in cui OpenSSH interpreta il risultato di una funzione della libreria musl libc durante la verifica delle password. Può interessare distribuzioni come Alpine Linux, utilizzata anche in ambienti cloud e virtualizzati.
Perché l'attacco sia possibile devono verificarsi contemporaneamente diversi requisiti: OpenSSH deve essere eseguito con musl, la verifica deve avvenire senza PAM e l'autenticazione tramite password deve essere abilitata. Inoltre, il campo della password dell'account bersaglio in /etc/shadow deve contenere un asterisco e deve esistere un altro account locale con un hash SHA-crypt valido, secondo la descrizione pubblicata da RedesZone.
L'errore si attiva con una password eccezionalmente lunga. Quando supera i 256 byte, la funzione di hash delle password di musl può restituire un asterisco come segnale di errore. OpenSSH interpreta quel valore come una corrispondenza con l'asterisco memorizzato per l'account bersaglio e accetta l'autenticazione. Debian Security Tracker descrive un intervallo compreso tra 256 e 1.024 caratteri in cui alcune configurazioni possono accettare qualsiasi password; RedesZone indica per l'intervallo documentato valori tra 257 e 1.024 byte.
La differenza tra queste soglie emerge dalle descrizioni disponibili, ma entrambe concordano sul meccanismo e sul fatto che la vulnerabilità dipenda dalla configurazione. Gli account con hash di password validi non possono essere aggirati sfruttando questa vulnerabilità. Kültekin ha inoltre osservato che sono necessarie specifiche opzioni di autenticazione e che l'accesso può essere elevato a root se l'account compromesso dispone di privilegi amministrativi senza password.
GovCERT.HK ha classificato l'avviso come ad alta minaccia il 6 novembre e ha raccomandato di applicare immediatamente l'aggiornamento. L'allerta identifica come vulnerabili i sistemi con versioni di OpenSSH precedenti alla 10.6p2 e descrive l'impatto come un aggiramento delle restrizioni di sicurezza.
I primi indizi sono emersi il 5 novembre
Il codice proof-of-concept è stato pubblicato il 5 novembre, circa quattro ore dopo che i manutentori di OpenSSH avevano rilasciato la versione corretta. BleepingComputer riferisce che diverse società hanno collocato l'inizio dei tentativi di sfruttamento nella stessa giornata e che alcune hanno registrato accessi riusciti il giorno seguente.
I dati degli honeypot raccolti da Johannes Ullrich, ricercatore del SANS Internet Storm Center, mostrano un brusco aumento delle richieste sospette. I suoi sistemi Cowrie hanno registrato 232 richieste con password composte dalla lettera «A» ripetuta il 5 novembre; il giorno successivo sono state 713. Queste cifre si riferiscono alle richieste, non ad attacchi confermati né ad autori unici: un singolo indirizzo IP può ripeterle.
Ullrich ha rilevato attività dal 1° novembre, ma ha ritenuto che i primi tentativi sembrassero script di forza bruta configurati male, non necessariamente attacchi deliberati con SSHole. Alcuni avrebbero inserito comandi di download direttamente nel campo della password. Cowrie conserva solo i primi 255 caratteri di ogni input, quindi non consente di esaminare completamente le password più lunghe. Ullrich ha ipotizzato che qualche accesso ai suoi honeypot possa essere riuscito, anche se i suoi registri non hanno confermato l'apertura di una sessione.
Gli indirizzi che hanno generato più tentativi in questi dati sono stati 213.86.169.133, con 48; 152.233.50.185, con 44; e 92.255.57.7, con 43. RedesZone ha inoltre riferito che alcune fonti sostenevano di aver confermato l'accesso root a un honeypot con Alpine Linux, citando la CVE in una pubblicazione del 6 novembre. SANS ha mantenuto un atteggiamento prudente riguardo alla portata dello sfruttamento nei server di produzione esposti a Internet.
GreyNoise ha documentato l'accesso root e un agente TAC
GreyNoise ha collocato il primo caso di successo osservato sulla rete il 7 novembre alle 00:46 UTC, circa 40 ore dopo la pubblicazione della correzione. I suoi ricercatori hanno conteggiato 16 stringhe di exploit riuscite contro reti protette dai suoi sensori, provenienti da sei indirizzi IP associati ad attività successive all'accesso. L'azienda ha avvertito che le sue osservazioni non rappresentano necessariamente l'insieme degli attacchi legati a SSHole.
Dopo essere entrati, gli aggressori hanno eseguito ricognizioni del sistema e dei container, consultato servizi di metadati cloud e tentato di leggere gli hash delle password e le chiavi SSH di root. Hanno anche cercato di modificare i file authorized_keys per mantenere l'accesso.
In uno degli incidenti, un aggressore ha ottenuto i privilegi di root e installato TAC Agent, un agente di comando e controllo scritto in Python. L'impianto non è riuscito a connettersi al proprio server C2, tac.vpnla[.]org, e non ha ricevuto alcun compito. Pertanto, sebbene l'accesso e l'installazione siano avvenuti, GreyNoise non ha osservato l'agente eseguire istruzioni provenienti da quel server.
L'analisi del programma mostra funzioni per eseguire comandi shell, raccogliere informazioni dettagliate sul sistema, caricare e scaricare file e aggiornarsi. TAC Agent non integra meccanismi di persistenza; nell'attività osservata, gli aggressori hanno tentato di garantirne l'esecuzione configurando un servizio di avvio.
I commenti, i registri e gli errori dell'agente erano in cinese, un indizio che GreyNoise indica come un elemento che potrebbe essere combinato con altre prove per indagare sull'origine dell'aggressore. L'azienda ha inoltre segnalato l'assenza di un controllo degli strumenti: il programma poteva restituire un errore che aiutasse un pianificatore automatizzato a correggere i comandi e proseguire l'attacco. Questo dettaglio suggerisce una possibile operazione automatizzata, ma da solo non identifica i responsabili.
GreyNoise ha inoltre conteggiato 27,5 milioni di scansioni della porta 22 e 20,1 milioni di tentativi di sessione SSH. L'azienda chiarisce che queste cifre non corrispondono ad attacchi SSHole confermati. Separatamente, la società finlandese Defused ha comunicato nel fine settimana di aver visto «un piccolo numero di attori» tentare di sfruttare la vulnerabilità e ha descritto l'attività come limitata.
Previdian, un'altra società di sicurezza di rete, ha confermato a sua volta sfruttamenti riusciti. I suoi dati di telemetria hanno mostrato 20 tentativi provenienti da 13 indirizzi IP di aggressori distribuiti in nove paesi. La società di sicurezza offensiva watchTower ha segnalato il 6 novembre attacchi associati a botnet e attività di mining di criptovalute.
Quali sistemi ha corretto Debian e come ridurre il rischio
Debian Security Tracker indica come vulnerabili i pacchetti OpenSSH inclusi in bookworm, nelle versioni 1:9.2p1-2+deb12u10 e 1:9.2p1-2+deb12u9, e in trixie, nelle versioni 1:10.0p1-7+deb13u4 e 1:10.0p1-7+deb13u2. In forky e sid, il pacchetto 1:10.6p2-1 risulta corretto. La situazione dipende dalla distribuzione e dal pacchetto installato; il numero di versione visibile non sempre riflette un backport, perciò RedesZone consiglia di verificare la revisione specifica del pacchetto.
La raccomandazione principale di BleepingComputer e GovCERT.HK è aggiornare OpenSSH. Alpine aveva già pubblicato pacchetti corretti nei propri repository, secondo RedesZone, che consiglia di installare l'aggiornamento della distribuzione e riavviare sshd. Se non è possibile applicare subito la patch, disattivare PasswordAuthentication chiude questa via di attacco. Prima di farlo, è necessario verificare se ci sono utenti che hanno ancora bisogno di accedere tramite password, poiché non potranno più farlo.
È inoltre opportuno esaminare i registri di accesso alla ricerca di accessi riusciti con password per account il cui campo in /etc/shadow contiene un asterisco, nonché di chiavi SSH non autorizzate o file e servizi di avvio associati a TAC Agent. RedesZone consiglia di prestare particolare attenzione ai tentativi falliti seguiti da un'autenticazione accettata nella stessa sessione.
La correzione è disponibile, ma le osservazioni di GreyNoise, Previdian e watchTower mostrano che la vulnerabilità è già passata dalla prova di concetto a tentativi e accessi in ambienti reali. Per i sistemi che non possono ancora applicare la patch, la decisione immediata è stabilire se possono rinunciare temporaneamente all'accesso SSH tramite password.
Fonti: BleepingComputer, RedesZone, GovCERT.HK, Debian Security Tracker
