CVE-2022-3602 e CVE-2022-3768
Il 1° novembre 2022, dopo aver anticipato lo spettacolo principale la settimana precedente, OpenSSL ha pubblicato il proprio avviso che descrive due rischi per OpenSSL 3.0.0 - 3.0.6. Inizialmente era stato previsto un allarme di livello Critico, che sarebbe stato il primo Critico dal 2015, ma è stato declassato ad Alto a causa di quelli che OpenSSL descrive come "fattori attenuanti".
Le due vulnerabilità si basano su buffer overflow nel campo dell'indirizzo e-mail in un certificato X509. Creando l'indirizzo e-mail in modo specifico, un utente malintenzionato potrebbe andare in overflow e controllare 4 byte sullo stack del sistema di destinazione CVE-2022-3602, oppure riempiendo l'indirizzo e-mail con un carattere specifico l'utente malintenzionato potrebbe andare in overflow sul buffer e bloccare il sistema CVE-2022-3768. Queste due vulnerabilità potrebbero, da sole, sembrare in grado di rompere tutto dappertutto e in una volta sola, tuttavia questi fattori di mitigazione sono piuttosto importanti.
Il primo fattore di attenuazione è che queste due vulnerabilità richiedono un livello di interazione da parte del client o del server preso di mira. In entrambe le vulnerabilità, un client che utilizza OpenSSL3.0 dovrebbe visitare un server dannoso che ospita un certificato x509 dannoso. Sebbene ciò non sia al di fuori della realtà delle operazioni quotidiane, è necessario che un utente faccia clic su un link o apra un documento per essere compromesso. Sebbene ciò sia abbastanza comune, esistono modi più semplici che utilizzare una vulnerabilità OpenSSL per eseguire un'esecuzione di codice remoto.
Dal lato del server, il server preso di mira dovrebbe richiedere un certificato di autenticazione client a un client malintenzionato. Questa non è una configurazione normale per i server rivolti a Internet ed è più probabile che venga utilizzata nei dispositivi on premise. A questo punto è necessario che una terza parte malintenzionata sia abbastanza vicina da colpire una rete.
Un altro importante fattore di mitigazione per queste vulnerabilità è che i certificati utilizzati devono essere firmati da un'autorità di certificazione (CA) affidabile, oppure l'applicazione deve continuare a non essere in grado di stabilire un percorso verso una CA affidabile per innescare questi overflow. Si tratta di un compito non banale per la maggior parte degli aggressori, anche se potrebbero esserci modi per utilizzare autorità di firma più aperte, ma è molto probabile che questi fornitori stiano controllando le richieste di firma dei certificati per trovare questi campi di indirizzi e-mail che potrebbero essere dannosi.
Inoltre, non c'è un gran numero di sistemi che eseguono OpenSSL3.0. Il numero non è certo pari a zero, ma per metterlo in prospettiva, due dei principali sistemi operativi per server non Windows, RHEL e Ubuntu, hanno incorporato OpenSSL3.0 nelle loro piattaforme solo quest'anno. RHEL 9 è stato rilasciato a maggio 2022, mentre Ubuntu 22.04 è stato rilasciato ad agosto 2022. Ciò significa che molti amministratori di sistema potrebbero non aver avuto la possibilità di aggiornare a questi rami e che queste sono solo le versioni LTS più recenti, quindi potrebbe non essere necessario aggiornare. Tuttavia, va notato che queste versioni possono essere utilizzate per costruire container Docker e altre applicazioni containerizzate.
Infine, OpenSSL non ha rilevato lo sfruttamento di queste vulnerabilità in natura, quindi non si tratta di una patch fuori banda in cui è in corso una campagna di attacco. Ciononostante, si consiglia di applicare una patch ai sistemi che utilizzano OpenSSL3.0.0-3.0.6 fino alla versione 3.0.7.
Vectra non dispone di un rilevamento specifico o di una ricerca salvata per trovare potenziali utilizzi di queste vulnerabilità specifiche, tuttavia, come per tutte le vulnerabilità che colpiscono infrastrutture o client, la vulnerabilità è solo il primo vettore di infezione in una compromissione in corso. Se un client o un server venisse compromesso utilizzando le tecniche sopra descritte, è probabile che venga distribuito un impianto o un trojan. In questi casi, i clienti potrebbero aspettarsi di vedere i seguenti rilevamenti:
- Tunnel DNS nascosto
- Tunnel HTTP nascosto
- Tunnel HTTPS nascosto
- Accesso remoto esterno
- Vectra Threat Intelligence Match
- Tunnel frontale multi-casa
Questi coprirebbero gli strumenti dannosi e gli impianti di comportamento C2, indipendentemente dalla vulnerabilità utilizzata per distribuirli.
Poiché si tratta di una campagna in corso, si prevede che si verifichino anche movimenti laterali, nel qual caso Vectra fornisce una copertura per le seguenti tecniche:
- Esecuzione remota sospetta
- Anomalia dei privilegi: servizio insolito
- Anomalia dei privilegi: account insolito sull'host
- Desktop remoto sospetto
- Anomalia dei privilegi: servizio insolito - Insider
- Anomalia dei privilegi: trio insolito, Anomalia dei privilegi: ospite insolito
- Anomalia dei privilegi: servizio insolito da parte dell'host
- Amministratore sospetto
Indipendentemente dallo strumento utilizzato, questi rilevamenti sono progettati per fornire copertura ai comportamenti che gli aggressori utilizzano dopo la violazione per raggiungere i loro obiettivi finali all'interno dell'ambiente.