Cos'è una vulnerabilità? Debolezza, minaccia, rischio ed exploit

Gran parte della confusione in sicurezza nasce da quattro parole che si usano come se volessero dire la stessa cosa: vulnerabilità, minaccia, rischio ed exploit. Una notizia dice "è stata sfruttata una vulnerabilità critica" e chi legge ci vede un solo fatto. In pratica sono quattro cose diverse. Tenerle separate ti dice cosa correggere per primo, cosa tenere d'occhio e cosa può aspettare.

Questo articolo ti dà definizioni operative, mostra come le quattro si collegano in un'unica catena e poi spiega due sistemi di denominazione che incontrerai ovunque. CWE dà un nome ai tipi di debolezza. CVE dà un nome a falle specifiche in prodotti specifici. Le ultime sezioni trattano due affermazioni che sorprendono chi inizia: una vulnerabilità senza un percorso per raggiungerla di solito ha un rischio basso, e un'impostazione sbagliata conta come vulnerabilità anche se nessuno ha scritto un bug.

Per questo articolo non ti serve un lab. La parte pratica è un esercizio su carta. Se leggi prima l'articolo sulla triade CIA, il passaggio sull'impatto ti sembrerà familiare.

#Quattro parole, quattro compiti

Parti dalla definizione ufficiale. Il glossario del NIST Computer Security Resource Center definisce una vulnerabilità come una debolezza in un sistema informativo, nelle sue procedure di sicurezza, nei suoi controlli interni o nella sua implementazione, che potrebbe essere sfruttata o attivata da una fonte di minaccia. La parola che conta è "weakness", debolezza. Una vulnerabilità è una proprietà di un sistema. Esiste che qualcuno la stia cercando o no.

#Vulnerabilità

Una vulnerabilità è una debolezza che potrebbe essere usata per causare danni. Alcuni esempi:

• Un modulo web che incolla l'input dell'utente direttamente in una query al database. Il tipo di debolezza è noto e CWE ha una voce apposita (più avanti ne parliamo).
• Un file server che accetta ancora un vecchio protocollo di cifratura debole.
• Un bucket di storage che permette a chiunque di elencarne il contenuto.
• Una versione di una libreria software con un bug di corruzione della memoria documentato pubblicamente.

Una vulnerabilità non ha bisogno di un attaccante per esistere. Deve esistere nel sistema, ed è la prima cosa da controllare quando valuti qualcosa.

#Minaccia

Una minaccia è una circostanza, un attore o un evento che potrebbe approfittare di una debolezza e causare danni. Il NIST usa il termine "threat source" per il soggetto o l'evento: un gruppo criminale, un insider malintenzionato, un'alluvione o un amministratore che sbaglia un file di configurazione.

La differenza rispetto a una vulnerabilità è la direzione. Una vulnerabilità descrive ciò su cui si può agire. Una minaccia descrive ciò che può agire. Una minaccia è potenziale. Per contare non serve che sia attiva contro di te in questo momento.

#Rischio

Il rischio combina quanto è probabile un evento dannoso con quanto sarebbe grave. NIST SP 800-30 Revision 1, la guida alla valutazione del rischio, tratta il rischio come funzione di probabilità e impatto. In parole semplici, il rischio è quanto è probabile che qualcosa accada, rapportato al danno che causerebbe. È un giudizio, non un calcolo preciso.

Molti team disegnano una matrice con la probabilità su un asse e l'impatto sull'altro. La matrice aiuta a ragionare. Non è una misura. Due finding con lo stesso punteggio di gravità possono avere un rischio molto diverso, perché il punteggio descrive la falla e il rischio descrive il tuo ambiente.

#Exploit

Un exploit è un metodo, un pezzo di codice o una sequenza di passi che usa una vulnerabilità per produrre un risultato non previsto da chi ha progettato il sistema. La parola può indicare la tecnica stessa o lo strumento che la esegue.

Due relazioni vanno ricordate. Primo, un exploit ha bisogno di una vulnerabilità contro cui funzionare. Secondo, una vulnerabilità non ha bisogno di un exploit pubblico per esistere. Molte vulnerabilità sono note e non hanno mai un exploit pubblico. Altre si attivano con un semplice input che chiunque può provare.

#Come si collegano le quattro

Queste quattro parole descrivono una sola catena. Eccola in ordine, con un generico modulo di login come esempio:

1. Debolezza. Il modulo di login accetta tentativi illimitati di password. Non c'è né blocco dell'account né limite di richieste. Questa è la vulnerabilità.
2. Fonte di minaccia. Qualcuno possiede un elenco di password da una vecchia violazione di dati e le riusa su molti account. Questa è la minaccia.
3. Exploit. Un breve script invia migliaia di tentativi di login e registra quelli riusciti. Quello script è l'exploit.
4. Impatto. Un account corrispondente viene compromesso. L'attaccante legge i dati di quell'utente, una perdita di riservatezza, e può cambiare le impostazioni, una perdita di integrità.
5. Rischio. Quanto conta dipende da due cose: quanto sono probabili i passi 2 e 3 nel tuo contesto, e quanto sarebbe grave il passo 4 per gli account coinvolti. Il modulo è raggiungibile da internet? Gli account usano l'autenticazione a più fattori? Cosa può raggiungere ogni account?

Puoi spezzare la catena in più punti. Un limite di richieste toglie la debolezza. L'autenticazione a più fattori rende molto meno utile un tentativo riuscito. Limitare il modulo a una rete privata riduce la portata della minaccia. Ogni controllo spezza un anello diverso, quindi devi sapere su quale anello stai lavorando.

#Come CWE e CVE danno un nome alle falle

Vedrai di continuo due identificatori nelle notizie di sicurezza, nei bollettini e nei report degli scanner. Rispondono a domande diverse, e confonderli è uno degli errori più comuni di chi inizia.

#CWE: il tipo di debolezza

Il sito CWE descrive CWE come un elenco, sviluppato dalla comunità, di debolezze comuni del software e dell'hardware. Definisce una debolezza come una condizione in un componente software, firmware, hardware o di servizio che, in certe condizioni, potrebbe contribuire all'introduzione di vulnerabilità. CWE risponde alla domanda: che tipo di errore è questo?

Ogni voce CWE ha un numero. La voce per la SQL injection è CWE-89, che riguarda la neutralizzazione impropria di elementi speciali in un comando SQL. La voce per il cross-site scripting è CWE-79. Queste voci non nominano alcun prodotto. Descrivono uno schema che compare in molti prodotti e aiutano chi sviluppa a riconoscerlo prima del rilascio.

#CVE: la falla specifica

CVE è un elenco di vulnerabilità di sicurezza informatica rese pubbliche. Ogni record descrive una falla in un prodotto, di solito con le versioni interessate e i link ai bollettini di sicurezza. L'identificatore ha questa forma:

CVE-YEAR-NUMBER

Un esempio reale è CVE-2021-44228, la falla in Apache Log4j 2 nota come Log4Shell. L'ID ti dice di quale falla si tratta. Il record ti dice quali prodotti e versioni sono interessati e dove trovare la correzione del produttore.

CVE risponde a un'altra domanda: quale falla specifica, in quale prodotto, è questa? Un singolo tipo CWE può avere molti record CVE in prodotti diversi, perché lo stesso tipo di errore viene commesso più e più volte.

#Leggere i due insieme

Quando leggi un record CVE, cerca il tipo di debolezza a cui è associato. Un record associato a CWE-89 ti dice che la falla è una SQL injection, anche se il prodotto non ti è familiare. Così puoi applicare a un caso nuovo quello che sai della categoria. Vale anche il contrario: se un prodotto ha precedenti con un certo tipo di debolezza, sai cosa controllare per primo.

#Perché una vulnerabilità senza percorso raggiungibile di solito ha un rischio basso

Immagina un servizio con una falla nota, in ascolto solo sull'indirizzo di loopback del tuo portatile. Nessun'altra macchina può connettersi. È una vulnerabilità? Sì. Il rischio è alto? Di solito no, perché la probabilità è molto bassa. Nessuno fuori dal tuo portatile può raggiungere la falla, quindi nessuna fonte di minaccia può usarla attraverso la rete.

Qui si vede all'opera l'idea di rischio. Una probabilità più bassa dà un rischio più basso, anche quando l'impatto sarebbe grave. La gravità da sola non decide cosa correggere per primo.

Attenzione, però. "Nessun percorso raggiungibile oggi" è un'affermazione su un singolo momento. Alcune cose cambiano il quadro:

• Una modifica di rete, come un nuovo port forward, una regola di un security group cloud o una rotta VPN, può rendere raggiungibile un servizio.
• Una macchina compromessa sulla stessa rete può raggiungere servizi invisibili dall'esterno.
• Un dipendente ingannato da un messaggio di phishing può diventare una strada verso un sistema interno.
• L'applicazione stessa può esporre il servizio attraverso un'altra via, come un proxy o un redirect.

Quindi rischio basso non significa rischio zero, e non significa ignorare la falla. Di solito la correzione può venire dopo i finding con percorsi raggiungibili, e dovresti ricontrollare la raggiungibilità ogni volta che la rete cambia.

#Perché una configurazione sbagliata conta come vulnerabilità

Molti principianti danno per scontato che una vulnerabilità debba essere un bug nel codice. È una visione troppo stretta. La definizione del glossario NIST include la "implementation" e gli "internal controls" del sistema, e CWE copre anche le debolezze di configurazione. Un'impostazione che espone dati o accessi è una debolezza, anche se nessuna riga di codice è sbagliata.

Un esempio semplice. Questo blocco nginx attiva il directory listing per un percorso:

location /backup/ {
    autoindex on;
}

Nessun codice è rotto. Nginx fa esattamente quello che dice questa riga. Ma chiunque possa raggiungere il percorso vede un elenco dei file in quella cartella, e alcuni potrebbero essere backup mai destinati al pubblico. La debolezza sta nella configurazione, e qualcuno può usarla per sapere cose che non dovrebbe sapere.

Altre configurazioni sbagliate comuni seguono la stessa logica:

• Un bucket di storage cloud impostato su lettura pubblica quando dovrebbe essere privato.
• Una password di amministratore predefinita mai cambiata.
• La modalità debug lasciata attiva in un'applicazione di produzione, che può mostrare stack trace ai visitatori.
• Un'interfaccia di amministrazione esposta su internet invece che su una rete privata.

Controlla i tuoi sistemi in questo modo. Per ogni impostazione che regola chi può vedere o cambiare qualcosa, chiediti se uno sconosciuto potrebbe usarla. Se sì, hai una vulnerabilità, che l'abbia scritta uno sviluppatore o l'abbia scelta un amministratore.

#Prova pratica: classifica cinque finding su carta

Non serve un lab. Prendi un foglio o un file di testo e lavora su cinque casi. Per ciascuno scrivi quattro risposte brevi: la debolezza, la probabile fonte di minaccia, se serve un exploit per usarla e se è raggiungibile da internet o solo dall'interno di una rete.

1. Un'applicazione web usa una versione di libreria con una falla documentata pubblicamente. L'applicazione è raggiungibile da internet.
2. Il directory listing è attivo su un percorso di backup. Il server è raggiungibile solo dalla rete dell'ufficio.
3. Un servizio con una falla nota ascolta solo sull'indirizzo di loopback di un portatile.
4. Un modulo di login non ha limite di richieste, ma ogni account richiede un secondo fattore.
5. Un bucket di storage cloud è impostato su lettura pubblica ed è attualmente vuoto.

Per ogni caso, scrivi una frase che inizia con "Il rischio è" e ne dà il motivo. Confronta le risposte con il ragionamento sopra. I casi 1 e 4 hanno le frasi sul rischio più utili, perché raggiungibilità e secondo fattore cambiano la probabilità del danno. Il caso 5 è una configurazione sbagliata che resta una vulnerabilità, anche se oggi nel bucket non c'è niente, perché i dati possono arrivare domani.

Conserva le risposte. Quando più avanti leggerai un vero bollettino di sicurezza, potrai applicare le stesse quattro domande.

#Errori comuni

• Usare vulnerabilità ed exploit come sinonimi. La vulnerabilità è la debolezza. L'exploit è il metodo che la usa.
• Scambiare il punteggio di gravità di uno scanner per il tuo rischio. Il punteggio descrive la falla in generale. Il tuo rischio dipende da raggiungibilità, dati e controlli.
• Ignorare le configurazioni sbagliate perché non c'è un bug nel codice. Anche le impostazioni possono essere vulnerabilità.
• Pensare che "nessun exploit noto" voglia dire sicuro. Significa che oggi non si conosce un exploit pubblico. Non dice nulla sull'esistenza di uno privato.
• Pensare che irraggiungibile voglia dire irraggiungibile per sempre. Modifiche di rete e macchine compromesse possono cambiare il percorso.
• Confondere un ID CVE con un tipo di debolezza. CVE indica una falla in un prodotto. CWE indica la categoria di errore.

#Per andare oltre

Leggi la voce del glossario NIST sulla vulnerabilità e le sezioni sulla valutazione del rischio di NIST SP 800-30 Revision 1. Poi apri un record CVE che ti interessa e trova tre cose: il prodotto e le versioni interessati, la descrizione della falla e l'associazione CWE, se presente. Questa abitudine trasforma un elenco di identificatori in un quadro chiaro, ed è la competenza di base per leggere i bollettini di sicurezza.

Quando le quattro parole ti sono chiare, la domanda successiva è come una debolezza possa essere raggiunta di proposito. L'articolo sul threat modeling con STRIDE mostra un modo strutturato per elencare le minacce contro un sistema prima che qualcuno lo attacchi. Usa lo stesso vocabolario che hai appena imparato, quindi lì le distinzioni viste sopra conteranno.

Leggendo con regolarità i record CVE noterai che la descrizione spesso indica la condizione necessaria per attivare la falla. Quella condizione è il tuo primo controllo sulla raggiungibilità. Scrivila accanto alla versione interessata e alla tua esposizione.

#Fonti

• NIST CSRC glossary: vulnerability
• CWE: About CWE
• CVE: Overview
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments