Grave vulnerabilità su Adobe Flash Player

Una nuova grave vulnerabilità è stata scoperta su Adobe Flash Player e pubblicata sul bollettino di sicurezza di Adobe Security Advisory https://helpx.adobe.com/security/products/flash-player/apsa16-03.html il 14 giugno 2016.

La vulnerabilità è presente nella versione 21.0.0.242 e nelle precedenti nei software installati su sistemi operativi Windows, Linux, Mac, e ChromeOS.

Il punteggio CVSS assegnato a questa vulnerabilità è elevatissimo 9,8

cvss

Sfrutta come vettore d’accesso la rete (una applicazione flash aperta tramite browser) genera il crash dell’applicazione e permette all’attacante di prendere il controllo del sistema attaccato.

La complessità di questo attacco è veramente bassa e non richiede privilegi particolari dell’utente, è sufficiente avere a disposizione l’input che genera il crash per poterlo utilizzare e compromettere la confidenzialità, l’integrità e la disponibilità dei dati e dei servizi presenti nella macchina vittima dell’attacco.

La vulnerabilità è stata scoperta da Anton Ivanov e Costin Raiu di Kaspersky Lab.kaspersky

La scoperta è avvenuta in modo accidentale durante l’analisi di un caso di attacco APT. kaspersky
I ricercatori Kaspersky sono all’avanguardia nell’individuazione degli attacchi, delle tecniche utilizzate dagli hacker per colpire le loro vittime e nel fronteggiare gli attacchi.

Le conoscenze acquisite dai ricercatori Kaspersky sugli attacchi zero-day permettono di avere nei loro prodotti tecniche di riconoscimento avanzate degli attacchi zero-day, tuttavia quando l’attacco è già noto, bisogna procedere il più rapidamente possibile nell’installazione delle patch applicative.

Kaspersky Security Center offre al reparto IT la possibilità di gestire il ciclo di individuazione, prioritizzazione, testing della patch e distribuzione delle patch per la maggior parte delle applicazioni commerciali e non solo per le patch del sistema operativo.

argonavislab

Argonavis è a vostra disposizione per fornirvi ulteriori informazioni su aspetti tecnici e commerciali, ed illustrarvi la convenienza nel proteggere i vostri sistemi con la tecnologia Kaspersky.

Richiedi Informazioni

21 Giugno 2016

Vulnerabilità delle applicazioni

Ridurre al minimo i privilegi concessi ad applicazioni ed utenti è una pratica necessaria se non indispensabile per ridurre i rischi di attacco informatico.

Tuttavia a dispetto di quanto si possa pensare questa best practice non è sufficiente da sola. Esistono delle vulnerabilità che permetto all’attaccante di eseguire un payload utilizzando un livello maggiore di privilegi rispetto a quelli che aveva l’applicazione vulnerabile.

E’ essenziale quindi monitorare costantemente le applicazioni vulnerabili ed in base alla gravità occorre procedere con la loro correzione nel più breve tempo possibile.

Prendiamo per esempio la vulnerabilità CVE-2016-0003 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0003 che riguarda Microsoft Edge, il nuovo browser che sostituisce Microsoft Internet Explorer.

Impact
CVSS Severity (version 3.0):
CVSS v3 Base Score: 9.6 Critical
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Impact Score: 6.0
Exploitability Score: 2.8

CVSS Version 3 Metrics:
Attack Vector (AV): Network
Attack Complexity (AC): Low
Privileges Required (PR): None
User Interaction (UI): Required
Scope (S): Changed
Confidentiality (C): High
Integrity (I): High
Availability (A): High

Questa vulnerabilità, dovuta ad un buffer overflow permette all’attaccante di eseguire del codice arbitrario (payload).

Ma la cosa più temibile è che il codice avrà permessi superiori rispetto alla applicazione vulnerabile (metrica CVSS Scope: Changed).

Il suggerimento è quello di effettuare opportune configurazioni per ridurre al minimo i privilegi delle applicazioni e degli utenti, per diminuire i rischi, ma anche di adottare delle politiche per monitorare e correggere in maniera automatica le vulnerabilità delle applicazioni

21 Marzo 2016

Vulnerabilità delle applicazioni: Metrica Ambiente

Environmental Metrics

Queste metriche dello standard CVSS consentono all’analista di personalizzare il punteggio CVSS cvssa 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à.

14 Marzo 2016

Vulnerabilità delle applicazioni: metrica Temporale

Le metriche temporali, definite dallo standard CVSS, misurano la possibilità in questo momento cvssdi 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 specificiLa 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.

 

11 Marzo 2016

Vulnerabilità delle applicazioni: Impatto

Metriche Impatto

cvssLe 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.

10 Marzo 2016