Una vulnerabilità critica denominata *sshole è già sfruttata in attacchi contro sistemi Linux: può consentire l’accesso non autenticato ad account con privilegi elevati quando ricorrono specifiche condizioni legate a OpenSSH e alla libreria musl.
Secondo quanto riferito da Ars Technica, i ricercatori di Greynoise hanno rilevato intrusioni nei propri honeypot nel Sud-est asiatico. OpenSSH ha già pubblicato una correzione che impedisce il funzionamento dell’attacco.
Da dove nasce la vulnerabilità
*sshole non viene descritta come un difetto isolato di un singolo pacchetto. Il problema nasce dall’interazione tra OpenSSH e musl, una libreria usata da alcune distribuzioni Linux. I sistemi che impiegano entrambi i componenti e soddisfano ulteriori requisiti possono essere compromessi in pochi secondi, ottenendo accesso senza autenticazione a profili con privilegi elevati.
Questo dettaglio delimita il perimetro del rischio: non ogni macchina Linux è automaticamente vulnerabile. Tuttavia, la possibilità di arrivare a un account privilegiato senza credenziali rende il difetto particolarmente serio per i sistemi esposti e configurati nelle condizioni interessate.
La falla è diventata pubblica giovedì scorso e, a pochi giorni di distanza, sono emersi segnali di sfruttamento reale. Il passaggio dalla divulgazione tecnica agli attacchi osservati riduce il tempo disponibile per intervenire sulle installazioni coinvolte.
Le intrusioni osservate da Greynoise
Greynoise ha segnalato attacchi contro gli honeypot che gestisce nel Sud-est asiatico e attribuisce la campagna a un gruppo monitorato con il nome GT10. L’azienda parla di “intrusioni mature”, cioè di attività che non si limiterebbero a tentativi automatici di accesso.
La società afferma inoltre di aver ottenuto accesso a un server usato dal gruppo. Da quel sistema sarebbero emersi potenziali altri bersagli e alcuni degli strumenti impiegati nella campagna. Sono informazioni di attribuzione e osservazione raccolte dai ricercatori, non una conferma dell’identità degli attaccanti.
Il ruolo della backdoor TAC Agent
Una volta ottenuto l’accesso, GT10 starebbe installando Python3 sulle macchine che ne sono sprovviste. Il pacchetto è necessario per eseguire la backdoor individuata come TAC Agent.
Secondo Greynoise, TAC Agent può eseguire comandi della shell, raccogliere informazioni sul sistema e mantenere la persistenza. In pratica, l’accesso iniziale fornito dalla vulnerabilità può diventare la base per proseguire l’attività sul dispositivo compromesso.
La backdoor conterrebbe commenti in lingua cinese e sembrerebbe generata con l’aiuto dell’intelligenza artificiale. Si tratta di indizi tecnici riportati dai ricercatori: da soli non dimostrano la provenienza geografica o l’identità degli operatori della campagna.
La correzione è già disponibile
OpenSSH ha rilasciato una correzione che blocca l’efficacia dell’attacco. La fonte non indica quali versioni siano interessate né elenca le distribuzioni Linux coinvolte, quindi non è possibile ricavare da questo resoconto un elenco completo dei sistemi da aggiornare.
Il punto rilevante è che la mitigazione esiste già, mentre lo sfruttamento è stato osservato sul campo. Per chi gestisce sistemi Linux, la priorità concreta è verificare se l’ambiente usa insieme OpenSSH e musl nelle configurazioni interessate e applicare la correzione resa disponibile.
FAQ
*sshole colpisce tutti i sistemi Linux?
No. La vulnerabilità riguarda sistemi che usano OpenSSH e musl e che rispettano anche altri requisiti non specificati dalla fonte.
Che cosa possono fare gli aggressori dopo l’accesso?
La campagna osservata usa TAC Agent, una backdoor che supporta comandi shell, ricognizione del sistema e persistenza.
Esiste già una soluzione?
Sì. OpenSSH ha pubblicato una correzione che impedisce all’attacco di funzionare, secondo quanto riportato dalla fonte.
Considerazioni finali
Il dato più preoccupante non è soltanto la gravità teorica di *sshole, ma la rapidità con cui è passata dalla divulgazione allo sfruttamento osservato. Una vulnerabilità che apre la strada ad account privilegiati senza autenticazione merita attenzione immediata proprio perché non lascia spazio a una sottovalutazione basata sull’assenza di incidenti visibili.
È positivo che la correzione di OpenSSH sia già disponibile, ma questo non ridimensiona il problema: la protezione dipende dall’applicazione effettiva dell’aggiornamento nelle configurazioni che combinano OpenSSH e musl. È questa la conseguenza concreta che pesa di più mentre gli attacchi sono già in corso.