OpenSSH: attenzione alla vulnerabilità critica che espone i dati di 14 milioni di server

I ricercatori di Qualys hanno comunicato pubblicamente la scoperta di una grave vulnerabilità di sicurezza che ad oggi interessa qualcosa come 14 milioni di server esposti sulla rete Internet. Un numero del genere non può non essere motivo di preoccupazione.

OpenSSH, acronimo di Open Secure Shell, è uno strumento ampiamente utilizzato per la gestione remota dei server. È la “porta di accesso” a un numero incalcolabile di sistemi connessi e consente di interfacciarsi a distanza con ogni aspetto della macchina. A meno che i sistemi non siano protetti tramite VPN o il collegamento sia autorizzato solo per specifici indirizzi IP, la porta utilizzata da SSH è di solito pubblicamente esposta. Una scansione di blocchi di indirizzi IP con nmap o con altri tool similari, oppure una ricerca con Shodan mettono immediatamente in evidenza quanti sistemi hanno porte SSH aperte e visibili.

regreSSHion: attenzione alla vulnerabilità in OpenSSH. C’è il rischio di esecuzione di codice dannoso

Gli esperti di Qualys spiegano che la falla CVE-2024-6387 scoperta all’interno di OpenSSH, rappresenta un rischio significativo per la sicurezza dei sistemi. Soprattutto considerando che sono oltre 14 milioni i server OpenSSH potenzialmente vulnerabili all’attacco battezzato con il nome di regreSSHion (il dato arriva dal già citato motore di ricerca Shodan e da Censys).

Lo sfruttamento della lacuna di sicurezza in questione portare a una compromissione completa del sistema, consentendo a un attaccante di eseguire codice arbitrario con i massimi privilegi. Le conseguenze includono l’installazione di malware, la manipolazione dei dati e la creazione di backdoor per un accesso persistente. Inoltre, l’attacco potrebbe facilitare i movimenti laterali consentendo agli attaccanti di bersagliare altri sistemi connessi in rete locale.

Perché l’attacco regreSSHion si chiama così

Da Qualys si spiega che la vulnerabilità non è propriamente una novità. In OpenSSH si è verificata una “regressione” (da qui il nome dell’attacco). Nell’ambito dello sviluppo software, una regressione si verifica quando un difetto, una volta risolto, riappare in un rilascio successivo a causa di modifiche o aggiornamenti che reintroducono involontariamente il problema.

Nel caso di OpenSSH nel 2006 fu segnalata e corretta una vulnerabilità significativa: CVE-2006-5051. Con la pubblicazione di OpenSSH 8.5p1 di ottobre 2020, il problema di sicurezza è tornato nel codice dell’applicazione.

Tutte le versioni di OpenSSH dalla 8.51p compresa fino alla 9.8p1 (esclusa) soffrono della grave vulnerabilità descritta da Qualys. Nello specifico, una race condition nel daemon sshd permette l’esecuzione di codice da remoto in modalità root sui sistemi basati su glibc.

La race condition è un difetto del sistema in cui il comportamento del software dipende dalla sequenza o dalla tempistica delle operazioni eseguite da più thread o processi. Quando due o più operazioni competono per risorse condivise, il risultato finale può variare a seconda dell’ordine con cui le operazioni sono eseguite. La libreria glibc, o GNU C Library, è la libreria standard del linguaggio C per i sistemi operativi GNU/Linux. Fornisce le funzioni di base necessarie per eseguire operazioni di basso livello, come gestione della memoria, input/output e gestione delle stringhe.

La specifica regressione della quale parliamo, è stata introdotta nell’ottobre 2020 con OpenSSH 8.5p1. L’incidente sottolinea l’importanza dei test di regressione per prevenire la reintroduzione di vulnerabilità note.

Quali sistemi sono vulnerabili

In parte l’abbiamo già detto, ma è importante sottolinearlo: affetti dalla vulnerabilità individuata da Qualys sono tutte le macchine che utilizzano versioni specifiche di OpenSSH su sistemi basati su glibc (la maggior parte delle distribuzioni Linux moderne).

• Versioni vulnerabili: OpenSSH 8.5p1 – 9.8p1 (non inclusa)
• Versioni non vulnerabili: OpenSSH 4.4p1 – 8.5p1 (non incluso)
• Versioni Precedenti a OpenSSH 4.4p1: sono vulnerabili solo in assenza delle patch per CVE-2006-5051 e CVE-2008-4109.

La vulnerabilità in questione è presente nelle configurazioni di default del server OpenSSH: ciò sottolinea la pressante esigenza di attivarsi prima possibile, proprio perché molte installazioni standard siano potenzialmente a rischio.

Mentre, tra le altre, distro come Debian, Ubuntu, Red Hat Enterprise Linux (RHEL), CentOS, Fedora, Arch Linux, SUSE Linux Enterprise, openSUSE sono interessate dalla problematica, OpenBSD non è interessato poiché dal 2001 utilizza un meccanismo che previene questo tipo di vulnerabilità.

Come risolvere il problema

Il primo passo consiste ovviamente nel verificare la versione di OpenSSH in uso sul sistema. È possibile digitare quanto segue in una finestra del terminale:

sudo sshd -V

A questo punto, nel caso in cui si usasse una versione vulnerabile del modulo server, è necessario installare la patch correttiva. Per mettersi al riparo da qualunque rischio, il modo migliore è certamente aggiornare OpenSSH alla versione 9.8p1 del 1° luglio 2024 (o successive). Inoltre, si può valutare di astenersi dall’esporre la porta di SSH sull’indirizzo IP pubblico.

Anzi, quest’ultimo suggerimento dovrebbe essere sempre applicato: perché offrire la possibilità, a chiunque, di stabilire una connessione SSH con i propri server? Come in questo caso, infatti, eventuali problemi di sicurezza potrebbero essere sfruttati da parte di aggressori remoti.

Anche la segmentazione della rete e l’utilizzo di efficaci soluzioni di intrusion detection sono accortezze che aiutano a rilevare e bloccare eventuali tentativi di accesso non autorizzato.

Credit immagine in apertura: Qualys.