Indicazioni su regreSSHion, una vulnerabilità critica di OpenSSH
Analisi riassuntiva
La CVE-2024-6387 è una vulnerabilità critica legata all'esecuzione di codice remoto (RCE) in OpenSSH, che deriva dalla regressione di una CVE del 2006.
Lo sfruttamento richiede il raggiungimento di una race condition, la cui riuscita può richiedere ore o persino settimane.
Si consiglia di applicare una patch ad una versione non interessata del server OpenSSH sui sistemi Linux basati su glibc. Nei casi in cui non è possibile eseguire questa operazione, abbiamo incluso altre opzioni di mitigazione che consentono di ridurre il suo potenziale impatto.
Forniamo anche una osquery per rilevare le versioni vulnerabili di OpenSSH.
Analisi tecnica e background della vulnerabilità di OpenSSH
Una nuova vulnerabilità critica (CVE-2024-6387) in OpenSSH è stata recentemente scoperta dal team Qualys Threat Research Unit , che potrebbe condurre ad una RCE non autenticata. Il 1° luglio 2024, il team ha pubblicato i risultati della sua ricerca sulla regressione della vulnerabilità CVE-2006-5051, che è stata corretta nel 2006 ed è riapparsa nel 2021.
La causa principale della CVE è una race condition determinata da un utilizzo non sicuro di segnali una volta scaduta l'autenticazione degli utenti. Al momento del timeout, viene generato un segnale SIGALRM, che causa un'interruzione in un thread che esegue una routine di gestione dell'heap. Se il gestore del segnale richiama la routine di gestione dell'heap, può causare un comportamento non previsto e, in tal caso, l'esecuzione di codice arbitrario.
Attualmente, una PoC (Proof-of-Concept) pubblica sfrutta questa vulnerabilità, rendendola nota (questa PoC è offerta da una terza parte non affiliata con Akamai, pertanto prestare la dovuta attenzione prima di tentare qualsiasi interazione con il codice). Nonostante la sua gravità, questa PoC evidenzia alcuni aspetti che limitano uno sfruttamento riuscito della vulnerabilità. Una delle principali limitazioni è il tempo richiesto per sfruttarla: su alcuni sistemi, alcune ore, su altri anche una settimana. Altre limitazioni includono la dipendenza dalla distribuzione del sistema operativo e dalla versione/configurazione del server OpenSSH.
Cosa è vulnerabile?
La vulnerabilità riguarda molte versioni di OpenSSH, inclusa la maggior parte delle distribuzioni Linux che vengono fornite di default con OpenSSH.
Poiché la causa principale della vulnerabilità è una regressione nel codice di OpenSSH, le versioni meno recenti del server OpenSSH sono interessate dalla CVE originale, che non riguarda, invece, le nuove versioni (pubblicate prima della regressione).
Alla data della pubblicazione di questo articolo, le versioni note di OpenSSH interessate da questa vulnerabilità sono riportate di seguito:
La vecchia versione della vulnerabilità (CVE-2006-5051) interessa le versioni di OpenSSH precedenti alla OpenSSH 4.4/4.4p1 (2006-09-27) [a meno che non siano state corrette dalle patch per le vulnerabilità CVE-2006-5051 e CVE-2008-4109]
La regressione della vulnerabilità è stata introdotta nella versione OpenSSH 8.5/8.5p1 (2021-03-03)
Gli addetti alla manutenzione di OpenSSH hanno corretto la vulnerabilità nella versione OpenSSH 9.8/9.8p1 (2024-07-01)
Un modo per cercare quali server sono interessati consiste nell'utilizzare la seguente query di Insight:
SELECT
name AS vulnerable_item,
'DEB' AS type,
version,
CAST(SUBSTR(version, 3, 3) AS REAL) AS version_to_compare,
source,
arch,
revision,
maintainer AS vendor
FROM deb_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
UNION
SELECT
name AS vulnerable_item,
'RPM' AS type,
version,
CAST(SUBSTR(version, 1, 3) AS REAL) AS version_to_compare,
source,
arch,
release AS revision,
vendor
FROM rpm_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
Dalle nostre osservazioni, risulta che il 75% delle reti presenta computer con una versione vulnerabile di OpenSSH e, in media, circa il 35% dei computer presenti in una determinata rete sono vulnerabili. Guardando al lato positivo, nei nostri ambienti monitorati, dobbiamo ancora osservare un computer con una porta SSH aperta arbitrariamente su Internet. Da una rapida ricerca condotta su Shodan , è emerso come più di 6 milioni di computer accessibili presentino una versione vulnerabile (Figura).
Rapporto di Shodan del 2 luglio 2024 per computer vulnerabili su Internet
Il potenziale impatto
Poiché la vulnerabilità interessa OpenSSH di default, il potenziale impatto è enorme in quanto interessa la maggior parte delle distribuzioni Linux, specialmente a causa della regressione sulle nuove versioni.
Ecco, tuttavia, tre precisazioni per ridurre il panico totale:
L'attuale PoC riguarda solo i computer x86 in quanto lo sfruttamento sui computer amd64 (che oggi sono standard) è molto più complesso a causa della presenza di migliori sistemi di protezione della memoria.
Attualmente, si ritiene che lo sfruttamento richieda più tempo e connessioni per una buona riuscita, pertanto, dovrebbe attivare la maggior parte dei sistemi di gestione degli attacchi di forza bruta.
A seguito delle due precisazioni qui sopra, questo attacco sembra essere più adatto come vettore di accesso iniziale da Internet. È possibile mitigare parte dell'impatto con una segmentazione appropriata delle connessioni SSH a Internet e del traffico proveniente dai computer che devono disporre di interfacce SSH connesse a Internet (come i jumpbox).
Mitigazione
Applicazione di patch
Il consiglio più ovvio è applicare una patch per correggere la vulnerabilità di OpenSSH alla versione aggiornata, non a quella vulnerabile. Tuttavia, poiché OpenSSH, di solito, viene fornito insieme alle distribuzioni Linux, l'applicazione delle patch dipende dalla versione del vendor di una patch, che può richiedere altro tempo e l'esecuzione di ulteriori test.
Gli amministratori di rete possono utilizzare la osquery fornita in questo blog per rilevare le loro risorse vulnerabili e tenerne traccia nel corso del tempo. I clienti di Akamai Guardicore Segmentation possono anche utilizzare query programmate per tale scopo ed etichettare le loro risorse in base ai risultati delle query.
Segmentazione
Come abbiamo notato sopra, lo sfruttamento di questa CVE è probabilmente più adatto per eseguire un'iniziale violazione delle reti poiché uno sfruttamento può richiedere ore, se non giorni, per garantire una buona riuscita dell'operazione. Pertanto, è cruciale mappare tutte le istanze delle interfacce OpenSSH connesse a Internet, quindi chiuderne o restringerne l'accesso.
Se è richiesto un accesso SSH arbitrario da Internet, si consiglia di applicare la segmentazione di rete ai computer per restringere l'accesso alla rete interna e limitare il raggio d'azione in caso di esito positivo delle operazioni di sfruttamento e violazione.
Sensibilità degli avvisi di minaccia
Poiché le patch non sono necessariamente ancora disponibili, potrebbe essere prudente aumentare la sensibilità degli avvisi sui carichi di lavoro che potrebbero essere potenzialmente vulnerabili e senza patch. In questo modo, anche se la vulnerabilità viene sfruttata in modo nascosto, potreste comunque notarne le conseguenze. In particolare, si consiglia di aumentare la sensibilità in caso di tentativi di attacchi di forza bruta, che è il modo con cui potrebbe più probabilmente avvenire lo sfruttamento della vulnerabilità.
Tuttavia, l'incremento della sensibilità può aumentare eccessivamente il numero di avvisi. Di conseguenza, consigliamo anche di regolare la sensibilità degli avvisi in base all’importanza del carico di lavoro interessato per la rete o al suo impatto.
Riepilogo
In questo blog, abbiamo esaminato le informazioni disponibili sulla vulnerabilità critica regreSSHion in OpenSSH, che è stata recentemente corretta e divulgata.
Per gli addetti alla sicurezza, è fondamentale determinare la vulnerabilità dei carichi di lavoro nella propria rete. Abbiamo tentato di offrire assistenza fornendo una osquery in grado di rilevare le versioni vulnerabili di OpenSSH. Abbiamo anche discusso cosa fare per mitigare parte del rischio (ad esempio, regolare la sensibilità degli avvisi di minaccia) quando le patch non sono disponibili.
Questo post del blog intende fornire una panoramica delle nostre conoscenze attuali e offrire suggerimenti sulla base delle informazioni disponibili. La nostra revisione è continua e tutte le informazioni contenute in questa analisi sono soggette a modifiche. Potete anche visitare il nostro account X per aggiornamenti in tempo reale.