SSHole in OpenSSH è già sfruttata: la CISA la inserisce nel catalogo KEV

SSHole, la vulnerabilità di OpenSSH tracciata come CVE-2026-123158, è sfruttata in attacchi reali. Il 9 novembre la CISA l’ha aggiunta al catalogo delle vulnerabilità con sfruttamento attivo (KEV) e chiede alle agenzie civili federali statunitensi di applicare le correzioni entro il 12 novembre. Il difetto, valutato 8.1 nella scala CVSS, permette di aggirare l’autenticazione su sistemi Linux basati su musl, la libreria C alternativa alla libc più diffusa, tra cui Alpine, distribuzione molto usata in ambienti cloud e virtuali.

Il problema è stato reso pubblico il 5 novembre dal ricercatore Ozgun Kultekin. Lo stesso giorno i manutentori di OpenSSH hanno rilasciato la versione 10.6p2 con la correzione, e circa quattro ore dopo è circolato un exploit proof-of-concept. I primi tentativi di sfruttamento sono stati rilevati tra il 5 e il 6 novembre. Il primo sfruttamento riuscito registrato da GreyNoise risale al 7 novembre alle 00:46 UTC, circa 40 ore dopo il rilascio della patch.

Defused, società di sicurezza finlandese, ha osservato un piccolo numero di attori che provano a sfruttare SSHole, e precisa che l’attività non è ancora diffusa. watchTowr ha rilevato il 6 novembre sfruttamenti riconducibili a botnet e a cryptomining. I sensori di Previdian hanno registrato 20 tentativi da 13 indirizzi IP geolocalizzati in nove paesi, cifre che altri resoconti portano a 22 tentativi da 14 indirizzi.

L’elenco degli indirizzi sorgente che GreyNoise rende consultabile parte dal 5 novembre e dal 6 si riempie in larga parte di indirizzi di Amazon, con client dichiarato Paramiko, libreria SSH per Python. L’elenco li classifica come dannosi o sospetti, senza indicare quali eventi siano andati a buon fine.

Come funziona l’aggiramento dell’autenticazione

L’attacco colpisce gli account il cui campo password in /etc/shadow contiene un asterisco (*), la convenzione con cui si impedisce l’accesso tramite password, standard per certi tipi di account. Quando il server OpenSSH riceve per uno di questi account una password di oltre 256 caratteri, la funzione di hashing di musl va in errore e restituisce proprio *. OpenSSH scambia quel valore per una corrispondenza con quello memorizzato nell’account e concede l’accesso. Red Hat descrive la causa come un'”interpretazione errata del fatto che una stringa sia destinata a essere un hash di password”.

OpenSSH deve girare su musl e senza PAM, i moduli di autenticazione collegabili. La configurazione deve inoltre prevedere almeno un account raggiungibile con una password salvata come hash SHA256 o SHA512, oltre agli account senza password. Secondo Kultekin gli account con un hash valido non sono interessati, e l’accesso può arrivare a root quando l’account compromesso dispone di privilegi amministrativi senza password. Il bacino di macchine esposte resta comunque ampio, soprattutto tra i sistemi Alpine, e individuare i server vulnerabili sembra questione di secondi.

Che cosa fanno gli attaccanti dopo l’accesso

GreyNoise ha registrato 16 catene di sfruttamento riuscite contro reti che protegge, cifra che altri resoconti portano a 18, con sei indirizzi sorgente collegati ad attività successive alla compromissione. L’azienda precisa che questi attacchi non rappresentano l’attività più ampia legata a SSHole. Gli aggressori hanno condotto ricognizione sul sistema e sui container, interrogato i servizi di metadati dei provider cloud, tentato di leggere gli hash delle password e le chiavi SSH di root e di modificare il file authorized_keys per assicurarsi un accesso persistente. Sempre secondo GreyNoise, le scansioni sulla porta 22 ammontano a 27,5 milioni e i tentativi di sessione SSH a 20,1 milioni, numeri che non sono attacchi SSHole confermati.

In un caso l’attaccante ha ottenuto i privilegi di root e ha installato TAC Agent, un agente di comando e controllo (C2) scritto in Python. L’impianto non è riuscito a raggiungere il suo server all’indirizzo tac.vpnla[.]org e non ha mai ricevuto istruzioni. L’analisi del payload mostra che sa eseguire comandi di shell, condurre una ricognizione estesa del sistema, elencare directory, trasferire file in entrambe le direzioni e aggiornarsi da solo. Non ha meccanismi di persistenza propri, e per questo gli attaccanti tentano di configurare un servizio all’avvio. GreyNoise ha osservato anche l’installazione di Python3 sulle macchine che ne sono prive, perché l’agente ne ha bisogno per girare.

Gli honeypot che GreyNoise mantiene nel Sud-Est asiatico sono stati colpiti da un gruppo che l’azienda traccia come GT10, autore di “intrusioni mature”. GreyNoise ha poi ottenuto accesso a un server del gruppo, dove ha trovato altre potenziali vittime e parte degli strumenti della campagna. Commenti, log ed errori della backdoor sono in cinese, un elemento che insieme ad altri potrebbe servire a risalire all’origine degli attacchi, e il codice sembra generato con l’aiuto dell’intelligenza artificiale. Manca inoltre un controllo sulla presenza degli strumenti che restituisce un riscontro utile a un pianificatore automatico per correggere i comandi, e questo fa pensare a un’operazione almeno in parte automatizzata.

Gli amministratori dovrebbero aggiornare OpenSSH il prima possibile, oppure disattivare l’autenticazione SSH con password sui sistemi interessati; chi usa musl farebbe bene a verificare la propria esposizione. Vanno cercati gli accessi riusciti con password su account il cui campo in /etc/shadow è *, le chiavi SSH non autorizzate, i file di TAC Agent e i servizi di avvio creati per mantenerlo attivo.