CVE-2022-3602 e CVE-2022-3786 – SpookySSL

Cosa c’è da sapere su queste vulnerabilità OpenSSL pubblicate con un livello di gravità inizialmente elevato?

Martedì 25 ottobre 2022, la mailing list di OpenSSL ha annunciato il rilascio di un nuovo aggiornamento di sicurezza per OpenSSL versione 3.0.7 che risolverebbe problemi critici di sicurezza delle versioni 3.0.x antecedenti. Questo aggiornamento è stato rilasciato poi il 1° novembre 2022.

OpenSSL  annuncio release
Annuncio nella mailing list ufficiale.

Martedì 1° novembre 2022, OpenSSL ha quindi pubblicato un avviso di sicurezza con 2 vulnerabilità nel database CVE: CVE-2022-3602 e CVE-2022-3786, che riguardano gli overflow del buffer.

Sebbene indicato come critico nel messaggio del 25 ottobre, il livello di CVE-2022-3602 è stato comunque rivisto al ribasso. Pertanto, CVE-2022-3602 e CVE-2022-3786 hanno solo una gravità elevata.

A questi CVE è stato assegnato il nome SpookySSL dal National Cyber ​​Security Centrum (NCSC-NL).

SpookySSL (CVE-2022-3602 e CVE-2022-3786) è difficile da sfruttare su un sistema moderno

Il livello di vulnerabilità di SpookySSL (CVE-2022-3602 e CVE-2022-3786) è stato rivisto al ribasso dal team di OpenSSL a seguito di discussioni con gli editori dei principali sistemi operativi presenti sul mercato.
In effetti, i moderni sistemi operativi implementano in modo nativo meccanismi di protezione contro gli overflow del buffer, il che riduce notevolmente il rischio di un attacco riuscito basato su queste CVE.
OpenSSL, a seguito di ciò, ha ridotto la gravità dell’avviso di sicurezza del 1 novembre 2022 da “critico” ad “alto”. Inoltre, OpenSSL 3 è utilizzato pochissimo: per la maggior parte delle aziende, queste vulnerabilità CVE-2022-3602 e CVE-2022-3786 riguarderanno solo pochissimi dispositivi. Queste vulnerabilità sono quindi rare e molto difficili da sfruttare in un moderno sistema informativo.

Cos’è OpenSSL?

OpenSSL è un software sviluppato dall’omonima comunità internazionale per fornire strumenti per la crittografia e la comunicazione sicura. OpenSSL è uno dei software più utilizzati al mondo: nel 2014 due terzi dei siti web accessibili utilizzavano questa tecnologia.

OpenSSL fornisce in particolare uno strumento da riga di comando chiamato openssl, utilizzato per generare chiavi private e pubbliche, certificati X.509 ed eseguire test sui protocolli SSL e TLS.

Essendo questa tecnologia molto diffusa e molto conosciuta, ogni vulnerabilità che la colpisce tende ad essere fortemente diffusa dalla stampa generale.

Come funzionano le CVE-2022-3602 e CVE-2022-3786 (SpookySSL) che influiscono su OpenSSL v3?

Che cos’è Punycode?

Le vulnerabilità CVE-2022-3602 e CVE-2022-3786 (SpookySSL) sono correlate alla compatibilità di OpenSSL con il cosiddetto Punycode o “codice spettrale”. Punycode è un meccanismo che consente di codificare determinati caratteri Unicode utilizzando caratteri ASCII. Punycode è particolarmente utilizzato per codificare nomi di dominio internazionalizzati. Ad esempio, le vulnerabilità diventano in Punycode vulnrabilits-eebh e il nome di dominio vulnerabilità.fr diventa allo stesso modo xn--vulnrabilits-eebh.fr.

SpookySSL (CVE-2022-3602 e CVE-2022-3786) è correlato a OpenSSL che interpreta Punycode durante la lettura di un certificato X.509

CVE-2022-3602 e CVE-2022-3786 sono correlati all’interpretazione di Punycode di OpenSSL. Infatti, poiché OpenSSL viene utilizzato in particolare per effettuare scambi con SSL e TLS, OpenSSL può essere utilizzato per effettuare controlli sui certificati X.509.

Ora, un certificato X.509 include campi chiamati “Subject Alternative Name” e “Issuer Alternative Name”, che consentono di associare questo certificato a e-mail con un nome di dominio internazionalizzato (RFC 8398).

L’interpretazione di queste e-mail internazionalizzate da parte di OpenSSL può, in determinate configurazioni, portare al danneggiamento della memoria e causare l’esecuzione di codice in modalità remota o la negazione del servizio.

Un utente malintenzionato potrà quindi creare un certificato X.509 con un’e-mail internazionalizzata creata appositamente per causare lo sfruttamento di queste vulnerabilità.

Lo sfruttamento di queste vulnerabilità CVE-2022-3602 e CVE-2022-3786 richiede la creazione di certificati il ​​cui Subject Alternative Name (campo subjectAltName) o il cui campo nameConstraint utilizzi un indirizzo email internazionalizzato con una sintassi specificatamente progettata per causare un buffer overflow su OpenSSL.

La società DataDog è riuscita a riprodurre questa situazione in un ambiente controllato ed è stata in grado di causare un arresto anomalo su Windows con OpenSSL 3.0.6.

Le CVE SpookySSL (CVE-2022-3602 e CVE-2022-3786) interessano sia i server che i client che utilizzano OpenSSL v3

Questa interpretazione di Punycode può avvenire sia su un server che su un client: infatti, in una comunicazione che utilizza un certificato X.509, questo certificato può essere presentato da un client ed essere verificato dal server, oppure presentato da un server ed essere verificato dal cliente.

Tuttavia, l’autenticazione di un client tramite certificato X.509 è utilizzata più raramente sul mercato e lo scenario più probabile qui riguarda quindi un server che presenta un certificato X.509 preparato da un utente malintenzionato ed esposto a client che incontreranno il buffer overflow quando si effettuano chiamate al server dannoso.

Queste CVE su OpenSSL v3 sono collegate al file crypto/punycode.c del progetto OpenSSL

Le patch rilasciate dalla comunità del progetto OpenSSL mostrano che è stato modificato solo un file: crypto/punycode.c.

 Vulnerabilità SpookySSL: patch per la CVE-2022-3786
Estratto della patch per la CVE-2022-3786 (commit 680e65b94c916af259bfdc2e25f1ab6e0c7a97d6)
Vulnerabilità SpookySSL: patch per la CVE-2022-3602
Estratto della patch per la CVE-2022-3602 (commit 3b421ebc64c7b52f1b9feb3812bdc7781c784332)

L’analisi di queste patch evidenzia anche la difficoltà di gestire in modo sicuro la memoria per progetti che si basano su codice di basso livello come C o C++, anche per progetti così grandi e conosciuti come OpenSSL.

Quali sistemi sono interessati da SpookySSL (CVE-2022-3602 e CVE-2022-3786)?

Le CVE OpenSSL 3 indicate come SpookySSL o CVE-2022-3602 e CVE-2022-3786 influiscono sulle versioni OpenSSL dalla v3.0.0 alla v3.0.6 inclusa.
Le versioni 1.1.1 e 1.0.2, che sono oggi le più utilizzate sul mercato, non sono interessate.

Esiste un elenco completo dei prodotti interessati da SpookySSL (CVE-2022-3602 e CVE-2022-3786)?

L’NCSC-NL mantiene un repository GitHub con l’elenco dei prodotti vulnerabili.
L’NCSC-NL fornisce anche script di ricerca per librerie OpenSSL potenzialmente vulnerabili.
Attenzione però ai falsi positivi con questo metodo: Ubuntu 22.04 ad esempio offre una micropatch 3.0.2-0ubuntu1.7 che è quindi in versione 3.0.2, ma che corregge SpookySSL (CVE-2022-3602 e CVE-2022-3786).

Cyberwatch consiglia quindi soprattutto di avvicinarsi alle opinioni di ciascun publisher per verificare se il prodotto studiato sia vulnerabile o meno, sapendo che molti prodotti utilizzano invece OpenSSL nel ramo 1.1.X o 1.0.X e quindi non sono interessati da SpookySSL.

Cyberwatch fornisce l’elenco delle varie opinioni delle principali distribuzioni sul mercato nella sua enciclopedia delle vulnerabilità (di seguito un estratto):

Inoltre, Cyberwatch Vulnerability Manager è in grado di rilevare queste vulnerabilità sui computer dalla data di pubblicazione dei vari avvisi di sicurezza, ovvero il 1 novembre 2022.
Non è richiesta alcuna azione da parte dei clienti.

SpookySSL: Cyberwatch rileva automaticamente la vulnerabilità
Individuazione automatica di SpookySSL da parte di Cyberwatch Vulnerability Manager

Come neutralizzare le CVE-2022-3602 e CVE-2022-3786?

Se si dispone di una versione interessata di OpenSSL, Cyberwatch consiglia di installare gli aggiornamenti di sicurezza già disponibili.
Cyberwatch Vulnerability Manager consente di distribuire le patch in modo nativo dalla sua interfaccia.

SpookySSL: distribuzione automatica patch di sicurezza
Distribuzione delle patch di sicurezza disponibili dall’interfaccia di Cyberwatch Vulnerability Manager

Articolo originale francese scritto da Maxime ALAY-EDDINE di Cyberwatch

Non esitate a chiederci una dimostrazione tramite la pagina dedicata selezionando nel campo Scegli la soluzione => Cyberwatch VM e CM.