Pazzia della patch: gli avvisi sui bug dei fornitori sono rotti, così rotti

BLACK HAT USA – Las Vegas – Tenere il passo con le patch di vulnerabilità della sicurezza è nella migliore delle ipotesi una sfida, ma dare la priorità a quali bug concentrarsi è diventato più difficile che mai, grazie a punteggi CVSS privi di contesto, avvisi confusi dei fornitori e correzioni incomplete che lasciare agli amministratori un falso senso di sicurezza.

Questo è l'argomento che Brian Gorenc e Dustin Childs, entrambi con Zero Day Initiative (ZDI) di Trend Micro, hanno fatto dal palco di Black Hat USA durante la loro sessione, "Calcolo del rischio nell'era dell'oscurità: lettura tra le linee di avvisi di sicurezza. "

ZDI ha rivelato più di 10,000 vulnerabilità ai fornitori di tutto il settore dal 2005. Nel corso di questo periodo, Childs, responsabile delle comunicazioni di ZDI, ha affermato di aver notato una tendenza inquietante, ovvero una diminuzione della qualità delle patch e una riduzione delle comunicazioni relative agli aggiornamenti di sicurezza.

"Il vero problema sorge quando i fornitori rilasciano patch difettose o informazioni imprecise e incomplete su tali patch che possono indurre le aziende a calcolare erroneamente il rischio", ha osservato. "Le patch difettose possono anche essere un vantaggio per sfruttare gli scrittori, poiché gli 'n-day' sono molto più facili da usare rispetto agli zero-day".

Il problema con i punteggi CVSS e la priorità di patch

La maggior parte dei team di sicurezza informatica sono a corto di personale e sotto pressione, e il mantra "mantieni sempre aggiornate tutte le versioni del software" non ha sempre senso per i dipartimenti che semplicemente non hanno le risorse per coprire il litorale. Ecco perché l'assegnazione di priorità alle patch da applicare in base al livello di gravità nella Common Vulnerability Severity Scale (CVSS) è diventato un fallback per molti amministratori.

Childs ha notato, tuttavia, che questo approccio è profondamente imperfetto e può portare a spendere risorse per bug che è improbabile che vengano mai sfruttati. Questo perché c'è una serie di informazioni critiche che il punteggio CVSS non fornisce.

"Troppo spesso, le aziende non guardano oltre il core di base CVSS per determinare la priorità di patch", ha affermato. “Ma il CVSS non considera realmente lo sfruttamento o se è probabile che una vulnerabilità venga utilizzata in natura. Il CVSS non ti dice se il bug esiste in 15 sistemi o in 15 milioni di sistemi. E non dice se si trova o meno in server accessibili pubblicamente".

Ha aggiunto: "E, soprattutto, non dice se il bug è presente o meno in un sistema critico per la tua azienda specifica".

Pertanto, anche se un bug potrebbe avere una valutazione critica di 10 su 10 sulla scala CVSS, il suo vero impatto potrebbe essere molto meno preoccupante di quanto indicherebbe quell'etichetta critica.

"Un bug di esecuzione di codice remoto (RCE) non autenticato in un server di posta elettronica come Microsoft Exchange susciterà molto interesse da parte degli autori di exploit", ha affermato. "Un bug RCE non autenticato in un server di posta elettronica come Squirrel Mail probabilmente non genererà tanta attenzione."

Per colmare le lacune contestuali, i team di sicurezza si rivolgono spesso agli avvisi dei fornitori, che, ha osservato Childs, hanno il loro problema evidente: spesso praticano la sicurezza attraverso l'oscurità.

Gli avvisi di Microsoft Patch Tuesday mancano di dettagli

Nel 2021, Microsoft ha preso la decisione rimuovere i riepiloghi esecutivi
dalle guide di aggiornamento della sicurezza, informando invece gli utenti che i punteggi CVSS sarebbero stati sufficienti per la definizione delle priorità, un cambiamento che Childs ha fatto saltare in aria.

"Il cambiamento rimuove il contesto necessario per determinare il rischio", ha affermato. "Ad esempio, un bug di divulgazione di informazioni scarica la memoria casuale o le PII? O per un bypass di funzionalità di sicurezza, cosa viene bypassato? Le informazioni in questi articoli sono incoerenti e di qualità variabile, nonostante le critiche quasi universali al cambiamento".

Oltre a "rimuovere o oscurare le informazioni negli aggiornamenti da parte di Microsoft che prima fornivano indicazioni chiare", ora è anche più difficile determinare le informazioni di base del Patch Tuesday, ad esempio quanti bug vengono corretti ogni mese.

"Ora devi contare te stesso, ed è in realtà una delle cose più difficili che faccio", ha osservato Childs.

Inoltre, le informazioni su quante vulnerabilità sono sotto attacco attivo o pubblicamente note sono ancora disponibili, ma ora sono sepolte nei bollettini.

“Ad esempio, con 121 CVE in corso di patch questo mese, è un po' difficile scavare tra tutti loro per cercare quali sono sotto attacco attivo”, ha detto Childs. "Invece, le persone ora fanno affidamento su altre fonti di informazioni come blog e articoli di stampa, piuttosto che su quelle che dovrebbero essere informazioni autorevoli dal fornitore per aiutare a determinare il rischio".

Va notato che Microsoft ha raddoppiato il cambio. In una conversazione con Dark Reading presso Black Hat USA, il vicepresidente aziendale del Security Response Center di Microsoft, Aanchal Gupta, ha affermato che l'azienda ha deciso consapevolmente di limitare le informazioni che fornisce inizialmente con i suoi CVE per proteggere gli utenti. Sebbene i CVE di Microsoft forniscano informazioni sulla gravità del bug e sulla probabilità che venga sfruttato (e se venga sfruttato attivamente), l'azienda sarà giudiziosa su come rilasciare informazioni sull'exploit di vulnerabilità, ha affermato.

L'obiettivo è dare alle amministrazioni della sicurezza abbastanza tempo per applicare la patch senza metterle a repentaglio, ha affermato Gupta. "Se, nel nostro CVE, avessimo fornito tutti i dettagli su come sfruttare le vulnerabilità, i nostri clienti sarebbero zero-day", ha affermato.

Altri fornitori praticano l'oscurità

Microsoft non è certo l'unico a fornire scarsi dettagli nelle rivelazioni di bug. Childs ha affermato che molti fornitori non forniscono affatto CVE quando rilasciano un aggiornamento.

"Dicono solo che l'aggiornamento risolve diversi problemi di sicurezza", ha spiegato. "Quanti? Qual è la gravità? Qual è la sfruttabilità? Di recente anche un fornitore ci ha detto in modo specifico che non pubblichiamo avvisi pubblici su problemi di sicurezza. È una mossa audace".

Inoltre, alcuni fornitori mettono avvisi dietro paywall o contratti di supporto, oscurando ulteriormente il rischio. Oppure combinano più segnalazioni di bug in un unico CVE, nonostante la percezione comune che un CVE rappresenti un'unica vulnerabilità unica.

"Questo porta a distorcere il calcolo del rischio", ha detto. "Ad esempio, se guardi all'acquisto di un prodotto e vedi 10 CVE che sono stati corretti in un certo lasso di tempo, potresti trarre una conclusione sul rischio di questo nuovo prodotto. Tuttavia, se sapessi che quei 10 CVE sono basati su oltre 100 segnalazioni di bug, potresti giungere a una conclusione diversa".

Placebo Patches Prioritizzazione della Peste

Oltre al problema della divulgazione, i team di sicurezza devono anche affrontare problemi con le patch stesse. Secondo Childs, le "patch Placebo", che sono "correzioni" che in realtà non apportano modifiche al codice efficaci, non sono rare.

"Quindi quel bug è ancora lì e sfruttabile per gli attori delle minacce, tranne che ora ne sono stati informati", ha detto. “Ci sono molte ragioni per cui questo potrebbe accadere, ma succede – bug così belli che li correggiamo due volte.

Spesso ci sono anche patch che sono incomplete; infatti, nel programma ZDI, dal 10% al 20% dei bug analizzati dai ricercatori sono il risultato diretto di una patch difettosa o incompleta.

Childs ha utilizzato l'esempio di un problema di overflow di numeri interi in Adobe Reader che porta a un'allocazione dell'heap sottodimensionata, che si traduce in un overflow del buffer quando vengono scritti troppi dati.

"Ci aspettavamo che Adobe risolvesse impostando qualsiasi valore oltre un certo punto come negativo", ha affermato Childs. “Ma non è quello che abbiamo visto, ed entro 60 minuti dal lancio, si è verificato un bypass delle patch e hanno dovuto eseguire nuovamente le patch. Le repliche non sono solo per i programmi TV".

Come combattere i problemi di prioritizzazione delle patch

In definitiva, quando si tratta di prioritizzazione delle patch, una gestione efficace delle patch e un calcolo del rischio si riducono all'identificazione di obiettivi software di alto valore all'interno dell'organizzazione e all'utilizzo di fonti di terze parti per restringere il campo delle patch più importanti per un determinato ambiente, il hanno notato i ricercatori.

Tuttavia, la questione dell'agilità post-divulgazione è un'altra area chiave su cui le organizzazioni devono concentrarsi.

Secondo Gorenc, direttore senior di ZDI, i criminali informatici non perdono tempo a integrare vuln con ampie superfici di attacco nei loro set di strumenti ransomware o nei loro kit di exploit, cercando di armare i difetti appena scoperti prima che le aziende abbiano il tempo di correggere. Questi cosiddetti bug di n-day sono catnip per gli aggressori, che in media possono decodificare un bug in appena 48 ore.

"Per la maggior parte, la comunità offensiva utilizza vulnerabilità di n-day che hanno patch pubbliche disponibili", ha affermato Gorenc. "È importante per noi capire al momento della divulgazione se un bug verrà effettivamente utilizzato come arma, ma la maggior parte dei fornitori non fornisce informazioni sullo sfruttamento".

Pertanto, le valutazioni del rischio aziendale devono essere sufficientemente dinamiche per modificare la post-divulgazione e i team di sicurezza dovrebbero monitorare le fonti di intelligence sulle minacce per capire quando un bug è integrato in un kit di exploit o in un ransomware o quando un exploit viene rilasciato online.

In aggiunta a ciò, una tempistica importante da considerare per le aziende è quanto tempo ci vuole per implementare effettivamente una patch in tutta l'organizzazione e se ci sono risorse di emergenza che possono essere utilizzate se necessario.

"Quando si verificano cambiamenti nel panorama delle minacce (revisioni delle patch, proof-of-concept pubblici e rilasci di exploit), le aziende dovrebbero spostare le proprie risorse per soddisfare le esigenze e combattere i rischi più recenti", ha spiegato Gorenc. “Non solo l'ultima vulnerabilità pubblicizzata e denominata. Osserva cosa sta succedendo nel panorama delle minacce, orienta le tue risorse e decidi quando agire".