In questo articolo Indice dei contenuti 2 sezioni
Una falla in OpenSSH battezzata SSHole viene già sfruttata attivamente dagli hacker per violare sistemi Linux, eseguire comandi, sottrarre credenziali e garantirsi un accesso persistente alle macchine colpite. Diverse aziende di sicurezza informatica hanno confermato gli attacchi e la cronologia è piuttosto eloquente. I primi tentativi sono partiti il 5 novembre, lo stesso giorno in cui è comparso online un exploit dimostrativo, e il primo sfruttamento andato a buon fine è stato registrato il giorno successivo.
La vulnerabilità è stata resa pubblica la settimana scorsa dal ricercatore Ozgun Kultekin. Permette di aggirare l’autenticazione di OpenSSH su alcuni sistemi Linux basati sulla libreria musl, tra cui la leggera distribuzione Alpine, molto diffusa negli ambienti cloud e virtuali. Il meccanismo è curioso. Gli account con l’hash della password impostato su un asterisco (), una scelta fatta proprio per impedire gli accessi tramite password, diventano invece accessibili. Basta una password di dimensioni eccessive perché la funzione di hashing di musl restituisca un errore, che OpenSSH interpreta per sbaglio come una corrispondenza con il valore memorizzato.
Kultekin ha precisato che lo sfruttamento richiede impostazioni di autenticazione specifiche e che gli account con hash validi non sono coinvolti. Il problema si fa serio quando l’account compromesso dispone di privilegi amministrativi senza password, perché in quel caso si arriva dritti all’accesso root. I manutentori hanno corretto il difetto con la versione 10.6p2 rilasciata il 5 novembre, ma il codice dell’exploit è circolato circa quattro ore dopo.
Cosa hanno osservato i ricercatori sul campo
La società finlandese Defused ha segnalato nel fine settimana di aver notato “un piccolo numero di attori” impegnati a sfruttare SSHole, pur parlando di un’attività non ancora diffusa. GreyNoise, specializzata in threat intelligence, ha invece registrato il primo attacco riuscito in circolazione il 7 novembre alle 00:46 UTC, circa 40 ore dopo la correzione. Sono state documentate 16 catene di sfruttamento andate a segno contro reti protette dall’azienda, partite da sei indirizzi IP collegati ad attività successive all’intrusione. Secondo la stessa GreyNoise questi episodi non rappresentano comunque il quadro più ampio legato alla vulnerabilità.
Negli attacchi analizzati gli autori hanno condotto ricognizioni sul sistema e sui container, interrogato i servizi di metadati cloud, provato a leggere gli hash delle password e le chiavi SSH di root e tentato di modificare i file authorized_keys per restare dentro a lungo. Un aggressore ha ottenuto i privilegi di amministratore e installato TAC Agent, un agente di comando e controllo scritto in Python. L’impianto però non è mai riuscito a contattare il proprio server all’indirizzo tac.vpnla[.]org e quindi non ha ricevuto alcun incarico.
Dall’analisi del payload emerge che TAC Agent può eseguire comandi shell, svolgere una ricognizione approfondita del sistema, caricare e scaricare file e aggiornarsi in autonomia. Non dispone però di meccanismi di persistenza integrati, così gli attaccanti cercano di renderlo stabile configurando un servizio di avvio. Commenti, log ed errori del software erano in cinese, un dettaglio che insieme ad altri elementi potrebbe aiutare a risalire all’origine dell’aggressore. C’è poi un indizio di possibile automazione. Un controllo mancante su uno strumento restituisce un riscontro che un sistema di pianificazione automatico potrebbe usare per correggere i comandi e far proseguire l’attacco.
I numeri dell’attività e le contromisure consigliate
Nel complesso GreyNoise ha contato 27,5 milioni di scansioni sulla porta 22 e 20,1 milioni di tentativi di sessione SSH, anche se non si tratta di attacchi SSHole confermati. I sensori di Previdian, azienda di sicurezza di rete, hanno a loro volta rilevato sfruttamenti riusciti, con 20 tentativi provenienti da 13 indirizzi IP distribuiti in nove paesi. La società di sicurezza offensiva watchTower ha riferito il 6 novembre di aver visto la falla impiegata in attacchi associati a botnet e attività di cryptomining.
Agli amministratori di sistema viene raccomandato di aggiornare OpenSSH il prima possibile oppure di disattivare l’autenticazione SSH tramite password sulle macchine esposte a SSHole. Conviene inoltre verificare eventuali accessi con password riusciti e inattesi su account il cui campo password in /etc/shadow è impostato su , la presenza di chiavi SSH non autorizzate e l’eventuale comparsa di file o servizi di avvio riconducibili a TAC Agent.
Fonte: TecnoAndroid