Divulgazione completa o responsabile: come vengono divulgate le vulnerabilità di sicurezza

Annuncio pubblicitario

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

Vengono scoperte vulnerabilità di sicurezza nei pacchetti software più diffusi tutto il tempoe OS X non fa eccezione. Il database delle vulnerabilità open source (OSVDB) mostra almeno 1100 vulnerabilità contrassegnate come "OS X". Ma cosa è interessante è il modo in cui è stata rivelata questa particolare vulnerabilità.

Invece di dire ad Apple e dare loro il tempo di porre rimedio al problema, il ricercatore ha deciso di pubblicare il suo exploit su Internet affinché tutti lo vedessero.

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

Potresti pensare che un particolare metodo di divulgazione sia irresponsabile. Potresti persino definirlo non etico o sconsiderato. Ma è più complicato di così. Benvenuti nel mondo strano e confuso della divulgazione di vulnerabilità.

Divulgazione completa vs responsabile

Esistono due modi popolari per rivelare le vulnerabilità ai fornitori di software.

Il primo si chiama divulgazione completa. Proprio come nell'esempio precedente, i ricercatori pubblicano immediatamente la loro vulnerabilità in natura, dando ai venditori assolutamente alcuna possibilità di rilasciare una correzione.

Il secondo si chiama divulgazione responsabileo divulgazione scaglionata. È qui che il ricercatore contatta il fornitore prima che la vulnerabilità venga rilasciata.

Entrambe le parti concordano quindi un lasso di tempo in cui il ricercatore promette di non pubblicare la vulnerabilità, al fine di offrire al venditore l'opportunità di creare 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à. Alcune falle di sicurezza non possono essere riparate facilmente e richiedono la ricostruzione da zero di interi sistemi software.

Una volta che entrambe le parti sono soddisfatte della correzione che è stata prodotta, la vulnerabilità viene quindi rivelata e data a Numero CVE. Questi identificano in modo univoco ogni vulnerabilità e la vulnerabilità viene archiviata online su OSVDB.

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

Nel campo della sicurezza, ci sono accesi dibattiti sul metodo di divulgazione migliore. Alcuni pensano che l'unico metodo etico e accurato sia la piena divulgazione. Alcuni pensano che sia meglio offrire ai fornitori l'opportunità di risolvere un problema prima di rilasciarlo in natura.

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

Gli argomenti a favore di una divulgazione responsabile

Vediamo un esempio di dove è meglio usare la divulgazione responsabile.

Quando parliamo di infrastrutture critiche nel contesto di Internet, è difficile evitare di parlarne il protocollo DNS Come modificare i server DNS e migliorare la sicurezza di InternetImmagina questo: ti svegli una bella mattina, ti versi una tazza di caffè e poi ti siedi al computer per iniziare il tuo lavoro per la giornata. Prima di ottenere effettivamente ... Leggi di più . Questo è ciò che ci consente di tradurre indirizzi Web leggibili dall'uomo (come makeuseof.com) in indirizzi IP.

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

Se qualcuno è stato in grado di interferire con, o compromettere una richiesta DNS, c'è un grande potenziale di danno. Ad esempio, potrebbero inviare le persone a pagine fraudolente di servizi bancari online, consentendo in tal modo di ottenere i propri dati bancari online. Potrebbero intercettare il loro traffico e-mail e online attraverso un attacco man-in-the-middle e leggere i contenuti. Potrebbero fondamentalmente minare la sicurezza di Internet nel suo insieme. Roba spaventosa.

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

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

Vi sono stati alcuni dei principali prodotti DNS interessati, inclusi quelli realizzati da Alcatel-Lucent, BlueCoat Technologies, Apple e Cisco. Il problema riguardava anche una serie di implementazioni DNS fornite con alcune popolari distribuzioni Linux / BSD, comprese quelle per Debian, Arch, Gentoo e FreeBSD.

Kaminsky ha dato loro 150 giorni per produrre una correzione e ha lavorato con loro in segreto per aiutarli a capire la vulnerabilità. Sapeva che questo problema era così grave e che i potenziali danni erano così grandi che lo sarebbero stati incredibilmente sconsiderato di rilasciarlo pubblicamente senza dare ai venditori l'opportunità di emettere un rattoppare.

Per inciso, la vulnerabilità era trapelato per caso dalla società di sicurezza Matsano in un post sul blog. L'articolo è stato rimosso, ma è stato rispecchiato e un giorno dopo la pubblicazione un exploit Ecco come ti attaccano: il mondo oscuro dei kit di exploitI truffatori possono utilizzare le 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ù era stato creato.

La vulnerabilità del DNS di Kaminsky alla fine riassume il nocciolo dell'argomento a favore di una divulgazione responsabile e scaglionata. Alcune vulnerabilità - come vulnerabilità zero day Che cos'è una vulnerabilità zero day? [MakeUseOf Explains] Leggi 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 della piena divulgazione

Rilasciando una vulnerabilità all'aperto, si sblocca una scatola di pandora in cui le persone 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 fornitori sono spesso abbastanza 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 non pubblicizzare Perché le aziende che mantengono segrete le violazioni potrebbero essere una buona cosaCon così tante informazioni online, siamo tutti preoccupati per potenziali violazioni della sicurezza. Ma queste violazioni potrebbero essere tenute segrete negli Stati Uniti per proteggerti. Sembra folle, quindi cosa sta succedendo? Leggi di più il fatto che stavano spedendo software vulnerabile. La piena divulgazione li costringe a essere onesti con i propri clienti.

Ma consente anche ai consumatori di fare una scelta informata se desiderano continuare a utilizzare un particolare software vulnerabile. Immagino che la maggioranza no.

Cosa vogliono i venditori?

I venditori non amano davvero la piena divulgazione.

Dopotutto, è un PR incredibilmente negativo per loro e mette a rischio i loro clienti. Hanno cercato di incentivare le persone a rivelare le vulnerabilità in modo responsabile attraverso i programmi di bug bounty. 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 vuole smettere di inviarli bug: ecco perché è pazzescoOracle è in acqua calda su un post errato del blog del capo della sicurezza, Mary Davidson. Questa dimostrazione di come la filosofia di sicurezza di Oracle si discosti dal mainstream non è stata accolta bene nella comunità della sicurezza ... Leggi di più - scoraggiare le persone dall'esecuzione di ricerche di sicurezza sul proprio software.

Ma ci saranno ancora persone che insistono sull'uso della piena divulgazione, sia per ragioni filosofiche, sia per il loro stesso divertimento. Nessun programma di bug bounty, per quanto generoso, può contrastarlo.