Full-disclosure delle vulnerabilità. L’arma definitiva, trasparente, a prova di “zona grigia”.

Massimiliano Brolli : 19 Novembre 2021 21:42

Autore: Brolli Massimiliano
Data Pubblicazione: 19/11/2021

Su Red Hot Cyber abbiamo spesso parlato della divulgazione coordinata delle vulnerabilità, con dei video sul nostro canale youtube e con molti articoli sul tema dicendo che la forza della trasparenza e della community, partendo dai ricercatori di sicurezza fino ad arrivare agli utilizzatori dei software e agli amministratori dei sistemi, permette di renderci più sicuri.

Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765 

Supporta RHC attraverso:

• L'acquisto del fumetto sul Cybersecurity Awareness
• Seguendo RHC su WhatsApp
• Seguendo RHC su Telegram
• Scarica gratuitamente "Dark Mirror", il report sul ransomware di Dark Lab

Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo

Molti potrebbero pensare, che non divulgando gli exploit dei bug di sicurezza, si possa in qualche modo preservare i sistemi da attacchi informatici da parti di attori malevoli, ma questo è appunto una vista superficiale al problema. Oggi vorrei parlare proprio di questo, spiegare il perché bisogna sempre premiare la trasparenza ed incentivare la “full disclosure”, a valle della conclusione della divulgazione responsabile delle vulnerabilità (CVD).

Le tipologie di disclosure

Esistono 5 diversi modelli di divulgazione delle vulnerabilità che possiamo sintetizzare di seguito:

1. No Disclosure: Il ricercatore dei bug non divulga le vulnerabilità rilevate pertanto la vulnerabilità da lui scoperta, rimane sconosciuta alla community di sicurezza informatica se non fino a quando tale vulnerabilità non viene riscoperta da un altro ricercatore di bug che la divulga pubblicamente. Delle ricerche hanno dimostrato che la probabilità di riscoprire uno stesso 0-day entro un anno è compresa tra il 15 e il 20% con importanti variazioni a seconda del set di dati. (Herr, Schneier e Morris, 2017)
2. Full disclosure: Il ricercatore rende le informazioni relative alla vulnerabilità di pubblico dominio, pertanto il venditore dovrà produrre immediatamente la patch in modo da proteggere i suoi sistemi. Questa modalità permette anche ai criminali informatici di scrivere exploit o PoC e quindi attaccare i sistemi che ancora non hanno applicato la fix di sicurezza;
3. Disclosure to a third party: Il ricercatore comunica la vulnerabilità ad un’altra entità diversa dal fornitore. Riferito al mercato nero, questo modello può essere rappresentato da un broker zeroday, che acquisisce gli exploit e li rivende ai suoi clienti, alimentando, il mercato degli exploit 0-day, degli spyware e dei sistemi di intelligence prodotti dagli PSOA (Private Sector Offensive Actor). Ma può anche essere vista in “zona bianca”, attraverso programmi centralizzati bug bounty;
4. Reporting to the vendor: si tratta di un processo di divulgazione limitato al solo vendor del prodotto da parte del ricercatore dei bug, per ridurre al minimo il rischio legato alla divulgazione di informazioni sulle vulnerabilità e sugli exploit ad esso collegati.
5. Coordinated Vulnerability Disclosure: il ricercatore di bug informa il vendor del prodotto, il quale produce una patch di sicurezza per la risoluzione la vulnerabilità segnalata. Solo dopo la produzione della patch, il ricercatore dei bug o il vendor, qualora sia una CNA (CVE Numbering Authority), procede alla divulgazione della vulnerabilità verso la community di sicurezza informatica.

Il modello che premia

Ad oggi, il modello che sta prendendo piede nel “mercato bianco”, è la Coordinated Vulnerability Disclosure (o abbreviato come CVD), dove la vulnerabilità viene resa pubblica solo dopo la produzione della patch da parte del vendor.

Sia nei programmi di bug-bounty (ad es. HackerOne o BugCrowd), oppure nella normale gestione dei programmi di Responsible Disclosure delle aziende, si tende sempre a far produrre la fix dal vendor prima di divulgare informazioni sulla vulnerabilità rilevata.

Questo ovviamente consente ai clienti dei prodotti software di avere a disposizione la patch prima della divulgazione delle informazioni di sfruttamento, come una normale PoC che segue la “full disclosure” (anche se in questo caso dopo la patch).

Questo è di fondamentale importanza in quanto una volta pubblicata una PoC di sfruttamento di una vulnerabilità di rilievo (ad esempio una Remote Code Execution da 9,8), miriadi di black hacker iniziano a scansionare internet alla ricerca delle infrastrutture vulnerabili, per trarne un profitto.

Avere a disposizione la patch già prodotta, ovviamente da un vantaggio enorme a tutta la community in quanto c’è una soluzione per la risoluzione della vulnerabilità, cosa che nella “full disclosure”, non avrebbe consentito al vendor di agire.

Ma anche dopo aver prodotto la patch di sicurezza, quindi completata la CVD, c’è una diatriba tra vendor e ricercatori di bug.

Quale modello, alla fine della divulgazione responsabile delle vulnerabilità adottare?

Pubblicare tutte le informazioni, compresi i “payload” per sfruttare il bug, oppure limitarci solo a dire quale CWE è stata rilevata?

I vantaggi della full disclosure dopo la CVD

Si potrebbe quindi pensare che un criminale informatico, avendo a disposizione tutti i dettagli di sfruttamento di una vulnerabilità, possa in qualche modo fare prima “dell’amministratore di sistema distratto”, e quindi violare il sistema prima che questo installi la patch.

Ma esistono diversi vantaggi nella “full disclosure” che devono essere compresi che a prima vista non si riescono ad intravedere e possiamo sintetizzare in:

• Gli amministratori dei sistemi, una volta che i dettagli completi della vulnerabilità sono resi pubblici, si affretteranno ad applicare le patch;
• I fornitori di vulnerability assessment, avranno a disposizione i dettagli per poter implementare il software capace di rilevare la vulnerabilità e mettere in condizione l’azienda di risolvere la falla;
• I fornitori di protezioni perimetrali IPS/NGF/WAF, potranno implementare le policy di rilevamento che permetteranno il blocco del “payload” dannoso in transito verso l’infrastruttura attaccata;
• Qualora gli exploit di sfruttamento siano già conosciuti nelle undeground (ad esempio nel caso di un exploit utilizzato in uno strumento di spyware prodotto da uno PSOA, come il famigerato Pegasus), rendendo pubbliche le vulnerabilità consentirà l’uguaglianza tra chi attacca e chi protegge i sistemi;

• Permettere la conoscenza degli “exploit” solo a poche persone, chi li ha scoperti (i ricercatori) e chi li ha risolti (il vendor), e non la community, renderebbe entrambi deboli a livello di trasparenza, dopo lo sfruttamento di tale exploit in un attacco informatico;
• I vendor di prodotto potranno migliorare la propria “cyber posture” andando ad evitare che tali falle si possano ripetere su apparati analoghi;
• Se i dettagli della vulnerabilità vengono pubblicati, tutti gli sviluppatori del mondo possono imparare e cercare di non ripetere gli stessi errori effettuati dal vendor;
• Un aggressore di solito ha molto tempo libero per scoprire i dettagli di una nuova vulnerabilità, un amministratore oberato di lavoro no. La full disclosure in questo caso è più vantaggiosa per l’amministratore (i clienti) piuttosto che per gli attaccanti;
• Gli analisti di sicurezza, prendendo spunto dalle vulnerabilità pubbliche per rilevare vulnerabilità simili su altri sistemi, rendendoli di fatto più sicuri;

Inoltre possiamo concludere dicendo che la trasparenza ha sempre premiato piuttosto che una condotta di “no disclosure”. Infatti, tale modello è adottato ad oggi da tutti i BIG dell’IT come Microsoft, Google, Apple, Amazon, Facebook e chi più ne ha più ne metta.

Il risvolto della medaglia nella logica a “modello chiuso”

Molte aziende, anche di prestigio, oggi hanno paura delle pubblicazione delle proprie CVE.

Ma questa è una tipica “vista miope” in quanto le aziende che non hanno cultura nella cyber security sono solite “chiudersi a riccio”. Questo perché si pensa che avere una CVE pubblicata sul National Vulnerability Database (NVD) degli Stati Uniti D’America è un danno per la propria brand e web reputation.

Successivamente però queste aziende iniziano ad ampliare la proprie conoscenze e avviano un programma di Responsible Disclosure ben fatto e iniziano a comprendere che con la collaborazione, in questo caso della community hacker, e la divulgazione delle proprie vulnerabilità verso la community, riescono a mettersi più al sicuro che “chiudendosi a riccio”.

Lo capiscono talmente tanto bene che quell’azienda dopo diventa una CNA (CVE Numbering Authorities, ovvero si mette in condizioni di aprire lei stessa le CVE per i suoi prodotti) e crea una pagina di “hall of fame” per “celebrare i suoi ricercatori” che le hanno fornito informazioni sui bug di sicurezza dei loro prodotti e alla fine attiva un programma di bug bounty per poter “pagare” chi trova le falle sui suoi prodotti.

Apple, ultimamente sta avendo problemi con i suoi software e soprattutto con la community hacker in quanto si sta allontanando dai suoi prodotti, per problematiche di patch lente e mancati riconoscimenti, oltra alla politica notoriamente a software chiuso. Non avere gli hacker etici dalla propria parte, quando sei una azienda come Apple, o sei una azienda che produce apparati network che stanno varcando la soglia dell’IT attraverso la NFV (Network functions virtualization), oggi non è assolutamente una scelta saggia.

Nella storia, ed in particolare nella storia dell’informatica, la collaborazione e la condivisione sono sempre più premiate che il “Modello chiuso”. Qualche motivo ci sarà no?

Massimiliano Brolli
Responsabile del RED Team e della Cyber Threat Intelligence di una grande azienda di Telecomunicazioni e dei laboratori di sicurezza informatica in ambito 4G/5G. Ha rivestito incarichi manageriali che vanno dal ICT Risk Management all’ingegneria del software alla docenza in master universitari.
Visita il sito web dell'autore