In questo articolo Indice dei contenuti 2 sezioni
sshole è una vulnerabilità vecchia di circa un decennio che, in alcune configurazioni, permette a un attaccante di accedere via SSH a dispositivi Linux senza conoscere alcuna password. I casi più chiari riguardano sistemi basati su Alpine Linux, ma il perimetro potrebbe allargarsi anche ad altre distribuzioni se adottano la stessa combinazione di componenti e impostazioni.
Il problema nasce dall’interazione tra OpenSSH, la libreria che gestisce le connessioni SSH, e musl, alternativa leggera a libc usata da Alpine in modo distintivo rispetto a molte altre distribuzioni. C’è però un dettaglio che fa da spartiacque, OpenSSH deve essere usato insieme a musl senza PAM, cioè senza il framework che gestisce l’autenticazione e i controlli di accesso agli account. Alpine, intanto, resta una distribuzione leggera e molto diffusa, e proprio questa diffusione fa alzare le antenne anche se le condizioni per lo sfruttamento non sono universali.
sshole: quando funziona l’accesso senza password e perché basta un solo tentativo
Per arrivare allo scenario peggiore servono altre condizioni piuttosto precise. La prima è che sul sistema esista almeno un account accessibile con password il cui hash sia basato su SHA256 o SHA512. La seconda è che l’account preso di mira sia configurato come “senza password”, attraverso la presenza di una stringa vuota nel campo password di /etc/shadow, il file Linux che conserva gli hash delle password. Gli account senza password non sono un’idea strana o rara, spesso vengono usati quando l’accesso avviene con certificati, e questa impostazione risulta comune per alcune tipologie di utenze.
Se tutto combacia, l’impatto diventa serio. I manutentori di Alpine Linux hanno spiegato che un attaccante capace di raggiungere la porta SSH può entrare senza sapere alcuna password. E il punto che preoccupa di più è la semplicità pratica, basta una sola connessione, funziona ogni volta, non richiede una sequenza di tentativi.
La dinamica, per come è stata descritta, è legata agli accessi su account senza password. In quel caso, l’attaccante può ottenere l’ingresso inserendo più di 256 caratteri nel campo password. Secondo i ricercatori di Checkpoint conta anche la presenza di SHA256 o SHA512 perché sshd finirebbe per riutilizzare il salt di quell’account, e senza quel salt l’attacco non andrebbe a buon fine. Sempre nei test riportati, l’account non dovrebbe essere solo “presente” nei dati, ma attivo, non un semplice contenitore di un hash.
Sul fronte privilegi, viene indicato che gli account root risultano protetti con l’impostazione predefinita PermitRootLogin prohibit password. Questo però non chiude la partita, perché account raggiungibili con permessi doas o sudo possono comunque arrivare a diventare root.
Dove sta davvero il difetto, quanti sistemi possono essere esposti e quali patch ci sono
Anche con prerequisiti così specifici, sshole viene visto come un rischio potenzialmente ampio. Il motivo è legato alla diffusione di Alpine in ambienti reali e spesso difficili da aggiornare. L’immagine base Alpine su Docker Hub supera 1 miliardo di download, e Alpine è da tempo presente in router, smart TV, controller industriali e altri dispositivi embedded, spesso poco aggiornabili o addirittura bloccati su versioni datate. Negli ultimi tempi, inoltre, Alpine è stata adottata anche su desktop e server, e compare in molte immagini container.
Secondo Detectify, Shodan elenca circa 22 milioni di sistemi con SSH aperto sulla porta 22. Solo una frazione, va detto, rispetterebbe tutte le condizioni necessarie per lo sfruttamento, ma la verifica è rapida e la ricerca di dispositivi vulnerabili non richiederebbe troppo sforzo né troppo tempo.
Resta un’area grigia importante, non è del tutto chiaro dove “abiti” la vulnerabilità. OpenSSH, che ha rilasciato un aggiornamento, sostiene che la causa principale sia fuori da sshd, pur ammettendo che via sshd sia sfruttabile e che lì possa essere evitata. Dall’altra parte, lo sviluppatore di musl Rich Felker dice che non si tratterebbe di un bug in musl, ma di un uso errato da parte del chiamante. Felker aggiunge che gli sviluppatori musl volevano modificare quel meccanismo da tempo e hanno intenzione di farlo in una prossima release. Anche Alpine Linux ha rilasciato un aggiornamento.
Non è ancora definito quali altri pacchetti possano essere vulnerabili. Chi ha scoperto sshole indica che OpenWRT è colpito, ma per impostazione predefinita quel sistema usa Dropbear e non OpenSSH per le connessioni SSH, anche se esistono istruzioni per installare OpenSSH. Vengono citati anche buildroot e yocto, ma senza una conferma definitiva.
Nel frattempo, chi utilizza un sistema Linux che combina musl e OpenSSH è invitato a verificare immediatamente se rientra nello scenario vulnerabile e a installare le patch disponibili, sia lato Alpine sia lato OpenSSH, dato che non risulta un identificativo CVE associato alla vulnerabilità.
Fonte: TecnoAndroid