OpenSSH SSHole: CISA impone patch entro 12 novembre, sfruttata in attacchi reali

OpenSSH SSHole. Il difetto aggira l’autenticazione su sistemi Linux con musl, come Alpine, quando PAM non è in uso. GreyNoise ha registrato 16 catene di sfruttamento riuscite e l’installazione dell’agente TAC Agent, un agente di comando e controllo scritto in Python.

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.

OpenSSH SSHole: perché è importante

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, una 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 UTC, circa 40 ore dopo il rilascio della patch. Defused, una società di sicurezza finlandese, ha osservato un piccolo numero di attori che provano a sfruttare SSHole, precisando 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, dati confermati anche da altri resoconti che parlano di 22 tentativi da 14 indirizzi.

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

L’attacco colpisce gli account il cui campo password in /etc/shadow contiene un asterisco (*), la convenzione che 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.

GreyNoise ha registrato 16 catene di sfruttamento riuscite contro le reti che protegge, una cifra confermata anche da altri resoconti 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.

Cosa cambia e quali sono gli effetti

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, 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.

Fonte e approfondimento su OpenSSH SSHole: articolo originale.

* Contenuto realizzato con l'ausilio di sistemi di intelligenza artificiale.