Hacker sfruttano la falla SSHole di OpenSSH per entrare nei server Alpine Linux

Gli attaccanti stanno già sfruttando SSHole (CVE-2026-123158, gravità 8,1 su 10), una falla di OpenSSH che permette di entrare in alcuni server Linux con qualsiasi password più lunga di 256 caratteri. Colpisce i sistemi basati sulla libreria C musl, Alpine Linux in testa. La società di threat intelligence GreyNoise ha registrato la prima intrusione riuscita il 7 novembre alle 00:46 UTC, circa 40 ore dopo l'uscita della correzione. Una volta dentro, gli intrusi hanno cercato password e chiavi, aggiunto le proprie chiavi SSH e in un caso installato un agente di controllo remoto, riferisce BleepingComputer.

Come funziona l'aggiramento

Su Linux, un * nel campo password di /etc/shadow significa che su quell'account non si può proprio entrare con una password. Alpine lo usa per root e per gli utenti che accedono solo con chiave. Il ricercatore Özgün Kültekin di Wakefield, che ha segnalato il bug, ne ha trovato l'origine in una modifica di musl del 2012: quando la sua funzione di hash delle password fallisce, restituisce * invece di un errore. E fallisce con qualsiasi password oltre i 256 byte. Una password lunghissima diventa quindi *, coincide con l'account bloccato e sshd fa entrare l'attaccante. Con PAM attivo sshd non confronta gli hash in questo modo, quindi quei sistemi sono al sicuro.

L'attacco richiede quattro condizioni insieme: sshd compilato con musl, PAM disattivato, accesso con password consentito e almeno un account con * nel campo password. Su Alpine le prime tre sono le impostazioni predefinite del pacchetto openssh-server, e root ha * dalla versione 3.16. Le immagini ufficiali di Alpine per AWS e Azure hanno inoltre un utente alpine che può eseguire comandi come root senza password, quindi entrare con quell'utente dà il controllo completo.

Cosa hanno fatto gli attaccanti

OpenSSH ha rilasciato la versione 10.6p2 con la correzione il 5 novembre. L'analisi del ricercatore è uscita lo stesso giorno e meno di un'ora dopo il codice dell'exploit era su GitHub. GreyNoise ha visto 16 catene di attacco riuscite da sei indirizzi IP sui sistemi che monitora e sottolinea che è solo una parte dell'attività. Gli intrusi hanno controllato se si trovavano in un container, interrogato i servizi di metadati del cloud, tentato di leggere le chiavi SSH di root e /etc/shadow e inserito le proprie chiavi in authorized_keys per root e per l'utente alpine, così da mantenere l'accesso.

Un gruppo ha ottenuto i permessi di root, cambiato le impostazioni DNS, avviato un secondo server SSH nascosto e installato TAC Agent, un programma Python con commenti e messaggi in cinese che può eseguire comandi e trasferire file. Non è mai riuscito a registrarsi presso il suo server di controllo, tac.vpnla[.]org, e non ha ricevuto incarichi. Anche le società di sicurezza Previdian e Defused hanno registrato tentativi, e watchTowr ha collegato la falla a botnet e mining di criptovalute.

Come controllare il proprio server

• Verificate il sistema: cat /etc/os-release. Se è Alpine o un altro sistema con musl, proseguite. I server con Ubuntu e Debian non sono esposti a questo bug.
• Aggiornate: apk upgrade openssh su Alpine. Ci sono pacchetti corretti per i rami dal 3.19 al 3.24 ed edge, secondo il tracker di sicurezza di Alpine.
• Se usate le chiavi, disattivate l'accesso con password: PasswordAuthentication no nella configurazione di sshd, poi riavviate sshd. Così la falla è chiusa anche prima dell'aggiornamento.
• Cercate tracce: accessi con password riusciti (grep "Accepted password" /var/log/messages) su account con * in /etc/shadow, chiavi sconosciute in authorized_keys, i file /opt/py3/tac_agent.py e /etc/init.d/tac-agent, modifiche a /etc/hosts e /etc/resolv.conf e un server SSH in più su una porta insolita (ss -tlnp elenca le porte aperte).
• Se trovate qualcosa, considerate il server compromesso: reinstallatelo e cambiate tutte le password e le chiavi che conteneva.

La questione riguarda chiunque gestisca una propria VPN su un VPS economico: le immagini leggere di Alpine sono molto usate a questo scopo. La maggior parte dei router domestici con OpenWrt usa Dropbear per SSH e non è colpita, a meno che il proprietario non l'abbia sostituito con OpenSSH. La nostra guida per mettere in sicurezza un VPS consiglia già l'accesso SSH solo con chiave, e questa impostazione blocca l'attacco.