Vulnerabilità delle applicazioni: Metrica Ambiente

Environmental Metrics

Queste metriche dello standard CVSS consentono all’analista di personalizzare il punteggio CVSS a seconda, per l’organizzazione, dell’importanza della risorsa IT interessata alla vulnerabilità, misurato in termini di controlli di sicurezza complementari, riservatezza, integrità e disponibilità.

Security Requirements (CR, IR, AR)

L’effetto del punteggio ambientale è costituito da dei modificatori che vengono valutati con le corrispondenti metriche Base. Cioè, questi parametri modificano il punteggio già assegnato sulle caratteristiche di riservatezza, integrità e disponibilità.
Ad esempio, il modificatore impatto sulla riservatezza (MC) è aumentato di peso se il requisito di riservatezza (CR) è alto. Allo stesso modo, il peso della metrica impatto riservatezza è diminuito se il requisito riservatezza è basso. Questo stesso processo viene applicato ai requisiti integrità e disponibilità.

Modified Basic Metric

Queste metriche consentono all’analista di rideterminare i parametri in base alle modifiche che sono state fatte all’interno dell’ambiente. Cioè, se un ambiente ha apportato modifiche generali per il software interessato che si differenzia in modo che possa modificare, per un attacco, la sfruttabilità, l’ambito, o l’impatto, è possibile far riflettere questo tramite un appropriato punteggio ambientale.
Il pieno effetto sul punteggio ambientale è determinato dai parametri di base corrispondenti.
Ad esempio, la configurazione di default per un componente vulnerabile può essere quello di eseguire un servizio di ascolto con i privilegi di amministratore, e potrebbe concedere la possibiltà di effettuare un attacco che comprometta riservatezza, integrità e disponibilità del servizio.
Nell’ambiente dell’analista, quel servizio è in esecuzione con privilegi ridotti; in tal caso, i modificatori possono essere impostato su Basso ed abbassare il punteggio della vulnerabilità.

Vulnerabilità delle applicazioni: metrica Temporale

Le metriche temporali, definite dallo standard CVSS, misurano la possibilità in questo momento di sfruttare l’attacco, l’esistenza di eventuali patch o soluzioni alternative, o la fiducia che si ha nella descrizione di una vulnerabilità.

Exploit Code Maturity (E)

Questa metrica misura la probabilità che la vulnerabilità venga sfruttata, e si basa sullo stato attuale delle tecniche utilizzabili, la disponibilità del codice, o la disponibilità di semplici script capaci di sfruttarla aumenta il numero di potenziali aggressori includendo quelli che sono non veri professionisti, aumentando la gravità della vulnerabilità. Inizialmente, lo sfruttamento del mondo reale può essere solo teorica.
In seguito avviene la pubblicazione di codice proof-of-concept, codice exploit funzionante, o dettagli tecnici sufficienti necessarie per sfruttare la vulnerabilità. Nei casi più gravi, può essere utilizzato come payload di un altri strumenti di attacco automatizzati: worm o virus.

Remediation Level (RL)

Il livello di rimedio RL di una vulnerabilità è un fattore importante per definire la priorità di risoluzione. La vulnerabilità tipicamente appena viene pubblicata è senza patch. Soluzioni alternative o correzioni possono offrire delle soluzioni provvisorie fino a quando una patch ufficiale o l’aggiornamento viene rilasciato. Ognuno di questi rispettivi stadi definisce questo punteggio temporale, che riflette la pericolosità diminuendo fino a quando la soluzione diventa definitiva.

Report Confidence (RC)

Questa metrica misura il grado di fiducia nell’esistenza della vulnerabilità e la credibilità dei dettagli tecnici noti. A volte è nota solo l’esistenza della vulnerabilità, ma non sono pubblicati dettagli specifici. La pericolosità e di conseguenza l’urgenza di porre rimedio ad una vulnerabilità è maggiore quando è nota l’esistenza con certezza. Questa metrica suggerisce anche il livello di conoscenze tecniche a disposizione degli aspiranti aggressori.

Vulnerabilità delle applicazioni: Impatto

Metriche Impatto

Le metriche di impatto si riferiscono alle caratteristiche del componente impatto. Se una vulnerabilità sfruttata con successo interessa uno o più componenti, le metriche di impatto si riferiscono alla componente che subisce il peggior risultato che descrive meglio le probabilità che un attacco abbia successo.

Se non si è verificato un cambiamento di Ambito, le metriche di impatto devono descrivere l’impatto su: riservatezza, integrità e disponibilità (CIA) per la componente vulnerabile.
Tuttavia, se si è verificato un cambiamento di ambito, le metriche di impatto devono riflettere l’impatto della CIA sulla componente interessata dalla vulnerabilità, o sul componente su cui si acquisiscono le autorizzazioni, a seconda di quale subisce l’impatto maggiore.

Riservatezza (C)

Questa metrica misura l’impatto sulla riservatezza delle risorse informative gestite da un componente software a causa di una vulnerabilità sfruttata con successo. Riservatezza si riferisce a limitare l’accesso alle informazioni solo gli utenti autorizzati.

Integrità (I)

Questa metrica misura l’impatto sull’integrità dei dati dopo che una vulnerabilità è sfruttata con successo. L’integrità si riferisce alla attendibilità e la veridicità delle informazioni.

Disponibilità (A)

Questa metrica misura l’impatto alla disponibilità della componente dopo che una vulnerabilità è stata sfruttata con successo. Mentre le metriche confidenzialità e integrità metriche riguardano la perdita di riservatezza o l’integrità dei dati (ad esempio, informazioni, file) utilizzati dal componente vulnerabile, questa metrica si riferisce alla perdita di disponibilità del componente stesso, come un servizio di rete (ad esempio, webserver, database, e-mail). Dal momento che la disponibilità si riferisce alla accessibilità delle risorse informative, attacchi DoS che consumano la banda, processore, o spazio su disco impattano sulla disponibilità del componente.

Vulnerabilità DROWN

Una nuova vulnerabilità nota con il nome di DROWN è stata scoperta CVE-2016-0703 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0703

Secondo la classificazione CVSS questa vulnerabilità ha un livello di pericolosità MEDIA

Questa vulnerabilità interessa l’implementazione di OpenSSL:

OpenSSL 0.9 fino alla versione 0.9.8zf
OpenSSL 1.0.0, fino alla versione 1.0.0r
OpenSSL 1.0.1 fino alla versione 1.0.1m
OpenSSL 1.0.2 fino alla versione 1.0.2a

poiché accettano valori di CLIENT-MASTER-KEY CLEAR-KEY-LENGTH arbitrari, che rende fattibile un attacco man-in-the-middle, che permette all’attaccante di scoprire il valore della MASTER-KEY e di decrittare i dati crittografati con TLS.

DROWN consente agli aggressori di rompere la cifratura e leggere o rubare le comunicazioni, tra cui informazioni sensibili come password, numeri di carte di credito, segreti commerciali o dati finanziari.Un server è vulnerabile a DROWN se :

Permette connessioni SSL v.2 Questo è sorprendentemente comune, a causa di errori di configurazione e le impostazioni predefinite inappropriate . Si stima che il 17% dei server HTTPS ancora consentire le connessioni SSL v.2.
La sua chiave privata viene utilizzata su qualsiasi altro server che permette connessioni SSLv2, anche per un altro protocollo, ad esempio SMTPS.
Molte aziende scelgono di riutilizzare lo stesso certificato e la chiave sui propri server web ed e-mail. In questo caso , se il server e-mail supporta SSL v.2 e il server web non lo fa, un utente malintenzionato può sfruttare il server di posta elettronica per intercettare le connessioni TLS al server web.

La particolare gravità di questa minaccia è determinata da due fattori:

Diffusione: Si stima che il 30% di tutti i server HTTPS sono vulnerabili all’attacco.
Costo: Si stima che per determinare la MASTER-KEY sia sufficiente poche ore, ed un attacco possa costare circa 440$

Come proteggo il mio server ?

Per la proteggersi dalla vulnerabilità Drown, è importante essere certi che le chiavi private non vengono utilizzati in un server che consente le connessioni SSL v.2.
Questa raccomandazione include i server web, server SMTP , server IMAP e POP, e qualsiasi altro software che supporta SSL / TLS .

Ulteriori dettagli sull’attacco sono riportati nel paper: https://drownattack.com/drown-attack-paper.pdf

Vulnerabilità delle applicazioni: Ambito

Metrica Ambito

Una proprietà importante descritta da CVSS v3.0 è la possibilità per una vulnerabilità in un componente software di riuscire ad utilizzare le risorse privilegi superiori. Questo viene rappresentato dalla metrica Scope (Ambito).

Formalmente, Scope si riferisce all’insieme di privilegi definiti da un’autorità (ad esempio un’applicazione, un sistema operativo, o un ambiente sandbox) nel concedere l’accesso alle risorse di calcolo (ad esempio file, CPU, memoria, ecc). Questi privilegi vengono assegnati sulla base di un sistema di identificazione ed autorizzazione. In alcuni casi, l’autorizzazione può essere semplice od effettuata genericamente sulla base di regole o standard predefiniti. Ad esempio, nel caso di traffico Ethernet inviato ad uno switch, l’apparato accetta traffico che arriva sulle porte ed è un’autorità che controlla il flusso del traffico indirizzandolo verso altre porte.

Quando la vulnerabilità di un componente software che governa le autorizzazioni è in grado di influenzare le risorse governate cambiando i permessi di autorizzazione, si verifica un cambiamento ambito (Scope).

Il punteggio è maggiore quando si può verificare un cambiamento di ambito. I valori possibili per la metrica sono:

Invariato (U) la vulnerabilità può interessare solo le risorse gestite dalla stessa autorità. In questo caso il componente vulnerabile ed il componente impattato sono uguali.
Modificato (C) la vulnerabilità sfruttata può influenzare risorse oltre i privilegi di autorizzazione previsti dalla componente vulnerabile. In questo caso il componente vulnerabile e il componente impatto sono differenti.