Divulgazione completa o responsabile del modo in cui vengono rivelate le vulnerabilità di sicurezza

Tre settimane fa è stato scoperto un serio problema di sicurezza in OS X 10.10.4. Questo, di per sé, non è particolarmente interessante.

Vengono scoperte vulnerabilità di sicurezza in pacchetti software popolari tutto il tempo, e OS X non fa eccezione. Il database di vulnerabilità open source (OSVDB) mostra almeno 1100 vulnerabilità contrassegnate come “OS X”. Ma cosa è interessante è il modo in cui è stata divulgata questa particolare vulnerabilità.

Piuttosto che dire a Apple e dare loro il tempo di rimediare al problema, il ricercatore ha deciso di pubblicare il suo exploit su Internet affinché tutti potessero vederlo.

Il risultato finale fu una corsa agli armamenti tra Apple e hacker black-hat. Apple ha dovuto rilasciare una patch prima che la vulnerabilità venisse armata e gli hacker dovevano creare un exploit prima che i sistemi a rischio venissero rattoppati.

Potresti pensare che un particolare metodo di divulgazione sia irresponsabile. Potresti anche definirlo immorale, o spericolato. Ma è più complicato di così. Benvenuti nel mondo strano, confusionario della divulgazione delle vulnerabilità.

Divulgazione completa vs responsabile

Esistono due modi diffusi per divulgare le vulnerabilità ai fornitori di software.

Il primo è chiamato piena divulgazione. Proprio come nell'esempio precedente, i ricercatori pubblicano immediatamente la loro vulnerabilità in natura, dando ai venditori assolutamente alcuna opportunità di rilasciare una correzione.

Il secondo è chiamato divulgazione responsabile, o divulgazione scaglionata. È qui che il ricercatore contatta il venditore prima che venga rilasciata la vulnerabilità.

Entrambe le parti concordano quindi un lasso di tempo in cui il ricercatore promette di non pubblicare la vulnerabilità, al fine di dare al venditore l'opportunità di costruire e rilasciare una correzione. Questo periodo di tempo può variare da 30 giorni a un anno, a seconda della gravità e della complessità della vulnerabilità. Alcuni problemi di sicurezza non possono essere risolti facilmente e richiedono la ricostruzione di interi sistemi software da zero.

Quando entrambe le parti sono soddisfatte della correzione che è stata prodotta, la vulnerabilità viene quindi divulgata e viene fornito un numero CVE. Identificano in modo univoco ciascuna vulnerabilità e la vulnerabilità è archiviata online su OSVDB.

Ma cosa succede se scade il tempo di attesa? Bene, una delle due cose. Il venditore negozierà quindi un'estensione con il ricercatore. Ma se il ricercatore non è soddisfatto di come il venditore ha reagito o si è comportato, o ritiene che la richiesta di un'estensione sia irragionevole, potrebbe semplicemente pubblicarla online senza alcuna correzione.

Nel campo della sicurezza, ci sono accesi dibattiti su quale metodo di divulgazione sia il migliore. Alcuni pensano che l'unico metodo etico e accurato sia la completa divulgazione. Alcuni pensano che sia meglio dare ai venditori l'opportunità di risolvere un problema prima di rilasciarlo in the wild.

A quanto pare, ci sono alcuni argomenti convincenti per entrambe le parti.

Gli argomenti a favore della divulgazione responsabile

Diamo un'occhiata a un esempio di dove è meglio utilizzare la divulgazione responsabile.

Quando parliamo di infrastrutture critiche nel contesto di Internet, è difficile evitare di parlare del protocollo DNS Come cambiare i server DNS e migliorare la sicurezza di Internet Come cambiare i server DNS e migliorare la sicurezza Internet Immagina questo: ti svegli una bellissima mattina, versati una tazza di caffè e poi siediti al tuo computer per iniziare il tuo lavoro per la giornata. Prima che tu abbia effettivamente ... Leggi altro. Questo è ciò che ci consente di tradurre indirizzi IP leggibili da umani (come makeuseof.com) in indirizzi IP.

Il sistema DNS è incredibilmente complicato, e non solo a livello tecnico. C'è molta fiducia in questo sistema. Siamo fiduciosi che quando scriviamo un indirizzo web, siamo inviati nel posto giusto. C'è semplicemente molto sull'integrità di questo sistema.

Se qualcuno è in grado di interferire o di compromettere una richiesta DNS, c'è molto potenziale rischio di danni. Ad esempio, potrebbero inviare persone a pagine di banking online fraudolente, consentendo loro di ottenere i loro dati bancari online. Potevano intercettare le loro e-mail e il traffico online attraverso un attacco man-in-the-middle e leggere il contenuto. Potrebbero fondamentalmente minare la sicurezza di Internet nel suo complesso. Roba spaventosa.

Dan Kaminsky è un ricercatore di sicurezza di tutto rispetto, con un lungo curriculum di individuazione di vulnerabilità in software ben noti. Ma è più noto per la scoperta del 2008 forse della più grave vulnerabilità nel sistema DNS mai trovato. Ciò avrebbe permesso a qualcuno di eseguire facilmente un attacco di avvelenamento della cache (o di spoofing del DNS) su un server dei nomi DNS. I dettagli più tecnici di questa vulnerabilità sono stati spiegati alla conferenza Def Con del 2008.

Kaminsky, acutamente consapevole delle conseguenze del rilascio di un difetto così grave, ha deciso di rivelarlo ai fornitori del software DNS interessati da questo bug.

Ci sono stati alcuni dei principali prodotti DNS interessati, inclusi quelli costruiti da Alcatel-Lucent, BlueCoat Technologies, Apple e Cisco. Il problema ha interessato anche una serie di implementazioni DNS fornite con alcune diffuse distribuzioni Linux / BSD, incluse quelle per Debian, Arch, Gentoo e FreeBSD.

Kaminsky diede loro 150 giorni per produrre una correzione, e lavorò con loro in segreto per aiutarli a capire la vulnerabilità. Sapeva che questo problema era così grave ei danni potenziali così grandi che sarebbe stato incredibilmente sconsiderato pubblicarlo senza dare ai venditori l'opportunità di rilasciare una patch.

Per inciso, la vulnerabilità è stata trapelata per caso dalla ditta di sicurezza Matsano in un post sul blog. L'articolo è stato rimosso, ma è stato replicato, e un giorno dopo la pubblicazione di un exploit This Is How Hack You: Il mondo oscuro dei kit di exploit Ecco come ti prendono in giro: il mondo oscuro dei kit di exploit Gli scammer possono utilizzare suite di software per sfruttare le vulnerabilità e creare malware. Ma quali sono questi kit di exploit? Da dove vengono? E come possono essere fermati? Leggi di più è stato creato.

La vulnerabilità DNS di Kaminsky riassume alla fine il nocciolo dell'argomento a favore di una divulgazione responsabile e scaglionata. Alcune vulnerabilità, come le vulnerabilità zero day Cos'è una vulnerabilità Zero Day? [MakeUseOf Explains] Che cos'è una vulnerabilità Zero Day? [MakeUseOf Explains] Per saperne di più - sono così significativi, che rilasciarli pubblicamente provocherebbe danni significativi.

Ma c'è anche un argomento convincente a favore del non dare un preavviso.

Il caso per la divulgazione completa

Rilasciando una vulnerabilità allo scoperto, si sblocca la scatola di un pandora in cui individui sgradevoli sono in grado di produrre rapidamente e facilmente exploit e compromettere i sistemi vulnerabili. Quindi, perché qualcuno dovrebbe scegliere di farlo?

Ci sono un paio di ragioni. In primo luogo, i venditori sono spesso piuttosto lenti a rispondere alle notifiche di sicurezza. Forzando efficacemente la propria mano rilasciando una vulnerabilità in natura, sono più motivati ​​a rispondere rapidamente. Ancora peggio, alcuni sono inclini a non pubblicizzare Perché le aziende che tengono il segreto sulle violazioni potrebbe essere una buona cosa Perché le aziende che tengono il segreto sulle violazioni potrebbe essere una buona cosa Con così tante informazioni online, tutti noi ci preoccupiamo di potenziali violazioni della sicurezza. Ma queste violazioni potrebbero essere tenute segrete negli Stati Uniti per proteggerti. Sembra pazzesco, quindi cosa sta succedendo? Leggi di più sul fatto che stavano spedendo software vulnerabile. La completa divulgazione li costringe ad essere onesti con i loro clienti.

A quanto pare @PepsiCo non si cura di un vuln nel loro sito, non accetta l'aiuto non richiesto. Ha già una squadra di sec. Farò piena divulgazione

- White Packet (@WhitePacket) 4 settembre 2015

Ma consente anche ai consumatori di fare una scelta informata su se vogliono continuare a utilizzare un particolare software vulnerabile. Immagino che la maggioranza non lo farebbe.

Cosa vogliono i venditori??

I venditori non amano davvero la divulgazione completa.

Dopotutto, è un PR incredibilmente cattivo e mette a rischio i loro clienti. Hanno cercato di incentivare le persone a rivelare le vulnerabilità in modo responsabile attraverso programmi di bug bug. Questi hanno avuto un notevole successo, con Google che ha pagato $ 1,3 milioni di dollari solo nel 2014.

Anche se vale la pena sottolineare che alcune aziende, come Oracle Oracle, vogliono smetterla di inviarle - Ecco perché l'oracolo pazzo ti fa smettere di inviarle - Ecco perché è pazzo Oracle è in acqua calda su un post sul blog sbagliato dal capo della sicurezza , Mary Davidson. Questa dimostrazione di come la filosofia della sicurezza di Oracle si allontani dal mainstream non è stata accolta bene nella comunità della sicurezza ... Read More - scoraggiare le persone dall'eseguire ricerche di sicurezza sul proprio software.

Ma ci saranno ancora persone che insistono nell'utilizzare la piena divulgazione, sia per ragioni filosofiche, sia per il loro stesso divertimento. Nessun programma di bug bug, non importa quanto generoso, può contrastarlo.

Scopri di più su: Computer Security, Hacking.