Discussione Come classificare la gravità di una vulnerabilità informatica

0xbro

Moderatore
24 Febbraio 2017
3,478
2,603
959
In questo articolo studieremo quali sono in linea generale le regole da seguire per clasificare correttamente una vulnerabilità informatica secondo lo standard CVSS Version 3​
bL0HACh.png


Come si classifica la gravità di una vulnerabilità?​

Tempo di lettura stimato: ~5 min​


Partiamo da un presupposto: non esiste una reale classificazione oggettivita di una vulnerabilità. Ogni falla va sempre valutata e "pesata" nel contesto in cui essa viene trovata.

Lo standard CVSS​

Fatta questa piccola precisazione, iniziamo ad analizzare lo standard utilizzato a livello globale. Il suo nome è CVSS (Common Vulnerability Scoring System), oggi alla versione 3.1, ed è il metro di valutazione che permette di racchiudere le caratteristiche principali di una vulnerabilità fornendo un punteggio numerico (da 0.0 a 10.0) che ne riflette la gravità oggettiva.

Il punteggio numerico può poi essere tradotto in una rappresentazione qualitativa della vulnerabilità (info, low, medium, high e critical) per aiutare le organizzazioni a valutare correttamente e dare priorità ai loro processi di gestione delle vulnerabilità.

La scala qualitativa​

La scala qualitativa delle vulnerabilità è suddivisa nei seguenti range:
Severity
Base Score Range
None / Informational
0.0​
Low
0.1 - 3.9​
Medium
4.0 - 6.9​
High
7.0 - 8.9​
Critical
9.0 - 10.0​

Il calcolo della severity​

Per facilitare il calcolo delle severity delle vulnerabilità sono nati diversi tools (tutti molto simili tra loro) che permettono di ottenerne velocemente il valore. Tra i più famosi e utilizzati ci sono il CVSS calculator del NIST (link al tool) e quello del FIRST (link al tool). Esistono comunque anche altri programmi da riga di comando o plugin di terze parti che svolgono lo stesso identico compito di valutazione.

Analizziamo come funziona il CVSS calculator del NIST (immagine sotto):

LfsGlD9.png


Il sito fornisce diversi campi obbligatori da compilare da cui calcolerà il grado di severity della vulnerabilità. I campi nel dettaglio sono divisi in due macro-gruppi. I parametri relativi al livello di exploitabilità della vulnerabilità:​
  • Attack Vector (AV): Indica se la vulnerabilità può essere exploitata a livello di rete remota - e quindi attraverso internet - (Network AV:N), solo da rete interna o "dispositivi vicini" - come tramite protocollo bluetooth - (Adjacent Network AV:A), solo con un accesso locale alla macchina - per esempio gli exploit di privilege escalation - (Local AV:L) o solo tramite accesso fisico al dispositivo (Physical AV: P).​
  • Attack Complexity (AC): Indica se la vulnerabilità è facilmente exploitabile tramite PoC pubblici o facili condizioni di exploitation (Low AC:L) o se la vulnerabilità necessità di condizioni estreme o concatenazioni di altre vulnerabilità (High AC:H)​
  • Privileges Required (PR): Indica se per sfruttare la vulnerabilità è necessario aver ottenuto prima un accesso con bassi privilegi (Low PR:L), accesso con privilegi elevati (High PR:H) o se non è necessario alcun tipo di autenticazione (None PR:N)​
  • User Interaction (UI): Indica se per sfruttare la vulnerabilità è necessario che un utente interagisca attivamente - per esempio cliccando su un link o un bottone - (Required UI:R) oppure se non serva alcuna interazione con l'utente (None UI:N)​
  • Scope (S): Indica se il componente impattato dalla vulnerabilità è lo stesso di quello vulnerabile (Unchanged S:U) oppure se il componente impattato dalla vulnerabile è diverso dal componente vulnerabile - per esempio le vulnerabilità Reflected XSS - (Changed S:C)​
e i parametri relativi alla metrica dell'impatto della vulnerabilità:​
  • Confidentiality Impact (C): Indica se la vulnerabilità permetta di violare la confidenzialità dei dati in maniera lieve - per esempio dati non personali e non sensibili, dati non completamente controllati dall'attaccante, ecc. - (Low C:L), in maniera grave - per esempio permettendo di leggere dati personali, sensibili, credenziali, ecc. - (High C:H) oppure non comporti una violazione di confidenzialità dei dati (None C:N)​
  • Integrity Impact (I): Indica se la vulnerabilità permetta di violare l'integrità dei dati in maniera lieve - per esempio senza avere il pieno controllo delle modifiche o modificando dati non critici - (Low I:L), in maniera grave - per esempio modificando dati sensibili, inserendo codice malevolo o avendo il pieno controllo delle modifiche - (High I:H) oppure non comporti una violazione di integrità dei dati (None I:N)​
  • Availability Impact (A): Indica se la vulnerabilità permetta di impattare la disponibilità del servizio in maniera leggera - rallentami di caricamento, leggera latenza - (Low A:L), in maniera grave - causando un completo Denial of Service - (High A:H) oppure non comporti una violazione di disponibilità del servizio (None I:N)​

Dopo aver compilato tutti i campi di base si otterrà lo score finale della vulnerabilità e il corrispettivo vector (la stringa contenente le caratteristiche della vulnerabilità):

MBDO1jW.png


Come si può notare il vector può essere facilmente scomposto nei campi sopra elencati, permettendo una rapida lettura della vulnerabilità:

AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N

AV:N = Attack Vector Network
AC:L = Attack Complexity Low
PR:L = Privilege Required Low
UI:R = User Interaction Required
S:C = Scope Changed
C:L = Confidentiality Impact Low
I:N = Integrity Impact None
A:N = Availability Impact None

Temporal ed Environmental Score Metrics​

Una volta ottenuto il base-score di una vulnerabilità esistono altre due metriche che ne permettono di regolare la severity: il Temporal Score Metrics, cioè dei parametri che indicano in un determinato momento storico il livello di maturità e completezza di eventuali PoC e relative tecniche di remediation, e l'Environmental Score Metrics, cioè una serie di parametri che permettono di regolare il livello di severity in base all'environment aziendale o non in cui si è trovata la vulnerabilità.

bvnAKUU.png


Entrambe le matrici servono a dare una sfumatura contestualizzata della vulnerabilità, ma a differenza del Base Score Metrics non sempre vengono utilizzate (esistono modi alternativi per contestualizzare una vulnerabilità) e perciò non sono quasi mai richieste.​

Esempi pratici​

Per vedere degli esempi pratici di categorizzazione delle vulnerabilità consiglio di dare un'occhiata ai link qua sotto, sia per degli esempi generali, sia prendendo spunto dalle classificazioni originali delle vulnerabilità note:

Compiti per casa :)

Esercizio #1​

Provare a scrivere il CVSS v3 score e relativo vector per la vulnerabilità LFI trovata durante la seguente CTF:

Esercizio #2​

Provare a scrivere il CVSS v3 score e relativo vector per la vulnerabilità trovata su GitLab al seguente link:


Made with ❤ for Inforge