"Ho trovato una vulnerabilità! E ora?"
"Posso richiedere una CVE? Come si fa? A chi devo richiederla?"
"Devo avvertire prima il vendor o posso richiederla subito?"
Queste sono solo alcune delle domande che ci vengono fatte quando qualcuno trova una vulnerabilità e decide di voler richiedere una CVE. Con questo articolo abbiamo deciso di rispondere a tutte le domande più frequenti fornendo delle linee guida su tutti i passi da seguire.
Senza perderci in chiacchiere, cominciamo.
Lo scopo per il quale è nato il CVE (Common Vulnerabilities Enumeration) è chiaro: identificare, definire e catalogare le vulnerabilità di sicurezza del software divulgate pubblicamente. Già da qui è evidente che non tutte le vulnerabilità hanno la relativa CVE, perché non tutte le vulnerabilità vengono divulgate, ma il motivo non è solamente questo; non per tutte le vulnerabilità è possibile richiedere una CVE.
Stando al glossario presente sul sito ufficiale del CVE Program una vulnerabilità è:
Un'istanza di una o più debolezze in un prodotto che può essere sfruttata, causando un impatto negativo sulla riservatezza, l'integrità o la disponibilità; un insieme di condizioni o comportamenti che consente la violazione di una politica di sicurezza esplicita o implicita.
Quindi, requisito fondamentale è che la vulnerabilità sia su un prodotto. Per semplificare possiamo dire che possiamo richiedere una CVE su un qualsiasi software o hardware di cui siamo in grado di specificare il nome, il vendor e il numero di versione. Per questo motivo, se ad esempio trovassimo una SQL injection sul sito del meccanico di quartiere non potremmo richiedere una CVE perché un sito web non ha un versioning pubblico e perché una volta che la vulnerabilità viene risolta, questa semplicemente smette di esistere per chiunque, senza possibilità di tornare indietro, quindi non avrebbe senso tenerne traccia su un sistema pubblico.
Discorso diverso se invece trovassimo una vulnerabilità su un sito web che è un'istanza di una versione specifica di un software open source. In quel caso, anche se il vendor risolvesse la vulnerabilità, ci sarebbe comunque la possibilità che qualche utente continua ad utilizzare una versione non aggiornata, quindi ancora vulnerabile.
Chi può richiedere una CVE?
"C'è bisogno di essere un'azienda o un professionista riconosciuto per richiedre una CVE?"
No, chiunque può richiedere una CVE, ad esempio:
- Penetration Tester che incappano in una vulnerabilità durante un ingaggio;
- Ricercatori di sicurezza che cercano attivamente vulnerabilità nel software;
- Sviluppatori che trovano vulnerabilità nel codice che hanno scritto loro stessi (si, questa cosa andrebbe regolamentata…);
- Navigatori occasionali di forum russi sulla sicurezza informatica che scovano dettagli di una vulnerabilità ormai pubblica per cui non è stata ancora chiesta una CVE;
- …
A chi si deve richiedere una CVE?
Questa è facile: la lista delle CVE è manutenuta dal MITRE, quindi va fatta richiesta solo al MITRE. Giusto? Sbagliato.
Considerando l'andamento nel tempo del numero di CVE richieste si è reso necessario realizzare un sistema più scalabile.
A grandi linee, possiamo pensare alla gerarchia su cui si basa il CVE Program in questo modo: il CVE Program al vertice designa delle organizzazioni come responsabili per uno specifico ambito di competenza; queste sono le cosìdette Root CNA. A loro volta le Root CNA reclutano, formano e gestiscono altre Root CNA, oppure delle CNA o CNA-LR. Le CNA (CVE Numbering Authority) sono entità autorizzate all'assegnazione e alla pubblicazione di CVE all'interno del loro specifico ambito di competenza. Le CNA-LR (CVE Numbering Authority of Last Resort), come dice il nome stesso, sono l'ultima spiaggia a cui rivolgersi. Si tratta di CNA autorizzate da una Root CNA all'assegnazione e alla pubblicazione di CVE all'interno di quella parte dello scope della Root CNA stessa, ma che non è già coperto da un'altra CNA.
Quindi, per sapere a chi richiedere la nostra CVE dovremmo cercare la CNA più specifica possibile per il prodotto su cui abbiamo trovato la vulnerabilità. Se non c'è una CNA specifica, allora dobbiamo rivolgerci alla CNA-LR più specifica possibile. Se non ci sono CNA o CNA-LR specifiche, allora possiamo richiedere la CVE alla CNA-LR figlia della Root CNA radice di tutta la gerarchia: il MITRE.
Detta così sembra un processo molto lungo e macchinoso, ma nella pratica è piuttosto semplice e si può riassumere così:
- Si apre il sito ufficiale del CVE Program alla pagina relativa alla lista dei partner;
- Si inserisce nella barra di ricerca il nome del vendor relativo al prodotto su cui si è trovata una vulnerabilità;
- Se otteniamo un risultato abbiamo trovato la CNA a cui richiedere la CVE;
- Se non otteniamo nessun risultato (il 99% delle volte) facciamo richiesta alla CNA-LR "MITRE Corporation".
Come si richiede una CVE a una CNA?
Cliccando sulla CNA di interesse dalla lista dei partner ci vengono forniti i dettagli della CNA, tra cui lo scope, la Root CNA di riferimento, ecc. Tra questi dettagli siamo interessati ai link nella sezione "Steps to Report a Vulnerability or Request a CVE ID":
Ogni CNA ha la sua disclosure policy e la sua modalità per la richiesta di una CVE. Alcune presentano un form online, altre richiedono l'invio di una mail, alcune richiedono un singolo passaggio, altre un intricato groviglio di pagine web degno di una challenge OSINT.
Come si richiede una CVE alla CNA-LR "MITRE Corporation"?
Nel caso in cui la CNA di riferimento sia "MITRE Corporation", la strada è semplice. Cliccando sul link nella lista dei partner e poi al link nella scheda di dettaglio veniamo portati sul CVE Form. Basta scegliere "Report Vulnerability/Request CVE ID" nella prima voce di menù e comprarirà a seguire il form completo di tutti i campi da compilare, ma non prima di alcuni avvertimenti:
- il primo ci dice come evitare che la loro risposta finisca in spam;
- l'ultimo ci chiede di confermare che abbiamo verificato che non c'è una CNA più idonea a cui inviare la richiesta e che alla vulnerabilità che stiamo segnalando non sia stata già assegnata una CVE;
- il secondo e più importante avvertimento ci dice che una volta che ci dovesse essere assegnata una CVE, questa comparirà nella lista pubblica delle CVE con la dicitura "RESERVED" e senza alcun dettaglio. Per fare in modo che la CVE venga resa pubblica sarà necessario fornire almeno un link a una pagina su cui sono riportati i dettagli della vulnerabilità (la pagina "Advisory" del produttore, un articolo di un blog o una issue su Github sono sufficienti).
Quali informazioni sono richieste nel CVE Form?
Il CVE Form enumera e spiega ogni campo dettagliatamente, ma vediamoli velocemente insieme per fare qualche considerazione in più.
Campi obbligatori
- Tipo di vulnerabilità, questo campo poteva essere lasciato libero per permettere agli utenti di scrivere la CWE che meglio descrive la vulnerabilità, ma per qualche motivo la MITRE Corporation ha deciso di renderlo un menù a tendina che riduce le 938 CWE esistenti a una lista di sole 10 CWE più il campo bonus "Altro". Tra queste dieci troviamo Buffer Overflow (CWE-119), Cross Site Scripting (CWE-79), SQL Injection (CWE-89), Directory Traversal (CWE-22), XXE (CWE-611), Insecure Permissions (CWE-276), Incorrect Access Control (CWE-284), Integer Overflow (CWE-190), CSRF (CWE-352) e Missing SSL certification verification (CWE-599).
- Nome del vendor
- Nome e versione del prodotto vulnerabile
Tutto qui? Si. Potenzialmente una richiesta valida per una CVE può essere una cosa del tipo "C'è un buffer overflow su Mozilla Firefox v123.0.1". Ovviamente una richiesta del genere sarebbe troppo generica per essere accettata; inoltre le CNA devono sottostare a delle regole specifiche (CNA Rules) in cui è specificato che una CVE per essere valida deve contenere:
- Tipo di vulnerabilità
- Nome del vendor
- Nome e versione del prodotto vulnerabile
- Descrizione della vulnerabilità
Già… non ho sbagliato a scrivere, è proprio così… la descrizione è un campo opzionale, ma senza di quello la segnalazione DEVE essere rifiutata. Come è possibile questo? Perché, come vedremo, la descrizione che forniamo è solamente un suggerimento e sarà poi chi riceverà la segnalazione a scriverne una appropriata. Ovviamente con così poche informazioni è impossibile scrivere una descrizione che rispetti le regole, quindi l'unica strada sarebbe rifiutare la segnalazione.
Campi opzionali
- Il fornitore ha confermato o riconosciuto la vulnerabilità? se abbiamo contattato il vendor per metterlo al corrente della vulnerabilità e questa è stata confermata, rispondendo "sì" il processo di assegnazione della CVE sarà più rapido perché secondo le CNA Rules "se un product owner considera una problematica segnalata su un suo prodotto una vulnerabilità, allora quella segnalazione DEVE essere considerata dalla CNA come vulnerabilità". In caso contrario sarà necessario da parte della CNA fare delle valutazioni interne che richiederanno tempo e potrebbero farvi rifiutare la richiesta di CVE;
- Tipo di attacco, questo campo permette la scelta tra "remoto", "locale", "fisico", "dipendente dal contesto" oppure l'immancabile "altro". Maggiore sarà la distanza da cui è possibile sfruttare la vulnerabilità, maggiore sarà lo score CVSS che verrà assegnato alla vulnerabilità;
- Impatto, cosa otteniamo se sfruttiamo la vulnerabilità? Possiamo scegliere tra "Code Execution", "Denial of Service", "Escalation of Privileges", "Information Disclosure" e ancora una volta "Altro";
- Componenti vulnerabili, qui possiamo specificare ad esempio il nome del file o della funzione che contengono il codice vulnerabile. Come vedremo è un'informazione che va inserita nella descrizione, ma allora perché ce la stanno chiedendo di nuovo? perché ricordate che la descrizione che forniamo è solo un suggerimento e questa informazione è utile per costruire una descrizione adeguata alle CNA Rules;
- Vettore d'attacco, qui dobbiamo specificare in che modo avviene lo sfruttamento della vulnerabilità. Nel caso di una SQLi, ad esempio, il vettore potrebbe essere "per sfruttare la vulnerabilità l'attaccante deve inviare una richiesta HTTP opportunamente realizzata", oppure nel caso di una XSS Stored potrebbe essere "per sfruttare la vulnerabilità l'utente vittima deve aprire la pagina X contenente il payload malevolo inserito dall'attaccante", ecc. Non è richiesto un grande livello di dettaglio e in generale potremmo generalizzare dicendo che si può scrivere una frase del genere: "to exploit the vulnerability an [actor] must [action] [conditions]";
- Suggerimento di descrizione della vulnerabilità da utilizzare per la CVE, cliccando sull'icona delle informazioni di questo campo ci viene fornito un link al PDF "Key Details Phrasing" che contiene tutte le specifiche che la descrizione dovrà avere per essere pubblicata. Quindi, se seguiamo le specifiche la CVE molto probabilmente sarà pubblicata con la nostra descrizione, altrimenti ne verrà scritta una da chi valuterà la nostra segnalazione, sulla base delle informazioni inserite negli altri campi.
Nel documento vengono proposti due template generici molto simili che sono:- "[VULNTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] allows [ATTACKER] to [IMPACT] via [VECTOR]."
- "[COMPONENT] in [VENDOR] [PRODUCT] [VERSION] [ROOT CAUSE], which allows [ATTACKER] to [IMPACT] via [VECTOR]."
- Crediti, il nome della persona o dell'azienda che ha trovato la vulnerabilità. Nell'ipotesi che stiate richiedendo una CVE per una vulnerabilità trovata da qualcun altro, qui va inserito il nome dell'altro, non il vostro. Ricordate comunque che questa informazione è visibile soltanto nel formato CVE JSON 5.0, ma solitamente non viene inserita nei siti web come CVEdetails.com;
- Riferimenti, qui potremo specificare i link a pagine utile, come la pagina del vendor o del prodotto, gli advisory o anche articoli di blog, ecc. Se tra questi link saranno presenti anche link a dettagli pubblici della vulnerabilità, la CVE, se accettata, verrà subito pubblicata, altrimenti rimarrà nello stato "RESERVED" finché non aggiorneremo la CNA della pubblicazione dei dettagli;
- Informazioni aggiuntive, questo è un campo libero; qualsiasi informazione aggiuntiva che volessimo dare alla CNA può essere scritta qui.
Ho richiesto la CVE, e ora?
Arrivati a questo punto non ci resta che attendere. La richiesta entrerà nella coda delle richieste da gestire, una coda molto lunga se ci rivolgiamo alla CNA-LR MITRE Corporation. Una volta che la nostra richiesta verrà presa in carico ci verrà riservato un CVE ID, che è lo stato iniziale per ottenere una CVE. Lo stato di riservato significa che alla nostra vulnerabilità viene assegnato un ID nel formato CVE-YYYY-NNNN (con YYYY l'anno corrente e NNNN una sequenza di almeno 4 numeri) che verrà utilizzato internamente dalla CNA per le comunicazioni e il coordinamento delle attività di verifica e gestione. Lo stato riservato non è tuttavia definitivo e la nostra segnalazione potrà ancora subire molte modifiche.
Se non avremo fornito tutti i dettagli necessari, potremo farlo anche successivamente con degli aggiornamenti della richiesta tramite il CVE Form, selezionando la voce di menù "Request an update to an existing CVE Entry").
Quando tutti i dettagli verranno forniti e la CNA avrà fatto le dovute verifiche rispetto alla conformità della richiesta, allora la CVE potrà essere pubblicata nella CVE List.
Tutte le comunicazioni in queste fasi avverranno tramite mail all'indirizzo che vi viene chiesto quando iniziate la compilazione del CVE Form.