La falla *sshole sfrutta il modo in cui musl gestisce gli hash non validi: su Alpine, con PAM spento, si entra in account bloccati. Chi rischia e cosa fare.
Una password sbagliata che apre la porta
Come si fa a entrare in un account che una password non ce l'ha? Sembra un controsenso, eppure è proprio quello che permette una falla di OpenSSH scoperta dal ricercatore Ozgun Kultekin e battezzata "*sshole". Colpisce i server SSH che girano su Linux basati su musl, la libreria C leggera usata da Alpine e da gran parte del mondo dei container e dell'embedded.
Come funziona
Il meccanismo è sottile. Per non far capire a un attaccante quali username esistono, OpenSSH calcola comunque un hash della password anche quando l'account non ne ha una valida. Gli account bloccati hanno un asterisco (*) al posto dell'hash in /etc/shadow. Il problema è che la funzione crypt() di musl restituisce anch'essa un asterisco quando l'hashing fallisce, per esempio se la password supera i 256 byte. Risultato: l'attaccante manda una password enorme, musl risponde con un "*", OpenSSH lo confronta con il "*" salvato per quell'account bloccato, i due coincidono e il login passa. Chi ha un hash valido resta al sicuro: il trucco funziona solo contro gli account disabilitati.
Chi è davvero esposto
Non basta usare Alpine per essere in pericolo. Servono diverse condizioni insieme: un sistema basato su musl, l'autenticazione PAM disattivata (che però è il default del pacchetto openssh-server di Alpine), l'autenticazione a password abilitata, almeno un account bloccato con "*" e almeno un altro account con password valida. I sistemi su glibc come Debian, Ubuntu e Fedora, e chiunque usi PAM, non sono toccati. Il caso più delicato riguarda le immagini cloud ufficiali di Alpine su AWS e Azure, che hanno un account 'alpine' con privilegi doas senza password: lì un accesso riuscito può trasformarsi in una scorciatoia verso root.
Cosa fare
La correzione c'è ed è nella OpenSSH 10.6p2: su Alpine si aggiorna con apk upgrade openssh. Se non puoi aggiornare subito, la via rapida è disattivare l'autenticazione a password (PasswordAuthentication no nella configurazione del server, poi riavvio di SSH) e affidarti alle chiavi. Per capire se qualcuno ha già provato, vale la pena controllare i log: su Alpine grep "Accepted password" /var/log/messages mostra i login a password andati a buon fine, e un accesso riuscito su un account che in /etc/shadow ha ancora "*" è un segnale che merita un'occhiata seria.
Fonte: BleepingComputer
La tua azienda è pronta ad affrontare una minaccia come questa?
Richiedi una valutazione gratuita →
Il dettaglio che mi ha fatto alzare un sopracciglio non è il bug in sé, ma dove vive: i container Alpine. Stanno ovunque, sono le immagini base di mezzo mondo DevOps perché pesano pochi megabyte e si avviano in un lampo. Solo che "leggero" vuol dire spesso anche "con meno pezzi di serie", e qui il pezzo che manca è PAM, spento di default nel pacchetto openssh di Alpine. Una scelta che nessuno nota finché non diventa esattamente la condizione che apre la falla.
Poi c'è la storia delle immagini cloud su AWS e Azure, con quell'account 'alpine' e i privilegi doas senza password: se l'attacco va a segno lì, non parliamo di un accesso qualunque ma di una porta verso root. Detto questo, secondo me non è il momento di farsi prendere dal panico. Le condizioni perché funzioni sono precise, e parecchie aziende sono già fuori dal tiro perché usano solo chiavi SSH, magari senza nemmeno saperlo. Il punto vero è proprio questo: quasi nessuno lo sa con certezza, e "credo di essere a posto" non è una risposta che mi tranquillizza.
Se gestite container Alpine o apparati embedded e non avete sottomano l'elenco di cosa accetta ancora il login a password, posso darvi una mano a fare questa verifica e a chiudere la porta anche prima dell'aggiornamento: scrivetemi e la guardiamo insieme sul vostro parco macchine.