it-swarm.dev

Come divulgare una vulnerabilità della sicurezza in modo etico?

Come divulgare una vulnerabilità della sicurezza in modo etico? Ho sentito che ci sono varie scuole di pensiero su questo argomento. Mi piacerebbe conoscere i pro/contro di ciascuno.

75
Olivier Lalonde

Dovresti informare lo/gli sviluppatore/i in privato in modo che abbiano la possibilità di risolverlo. Dopodiché, se e quando si rende pubblica la vulnerabilità, è necessario concedere allo sviluppatore abbastanza tempo per risolvere il problema e chiunque sia esposto a esso abbastanza tempo per aggiornare i propri sistemi. Personalmente, consentirei allo sviluppatore di fare l'annuncio in un bollettino sulla sicurezza nella maggior parte dei casi piuttosto che annunciarlo da solo. Almeno, aspetterei la conferma che la vulnerabilità sia stata risolta. Se hai tempo e hai accesso al codice sorgente, potresti anche fornire una patch.

43
VirtuosiMedia

Personalmente penso Divulgazione responsabile sembra essere il modo migliore per andare da un punto di vista etico e ha funzionato bene per Dan Kaminsky rivelando i dettagli della vulnerabilità avvelenamento da cache DNS. Ma tutto dipende molto dalla compagnia o dal gruppo con cui hai a che fare e anche dalla base di utenti che interesserà.

27
Mark Davidson

@VirtuosiMedia fa un ottimo lavoro nel delineare "Responsible Disclosure".

Aggiungerei due punti:

  • Collabora con il fornitore (se puoi), per assicurarti che lo comprendano appieno e non emettano una patch semi-cotta.
  • Se il fornitore ti ignora o ti ignora, continua a provare. Tuttavia, se affermano che non è una vulnerabilità, vai avanti e pubblica. Il più forte possibile. Se hanno promesso di risolvere, ma non farlo, prova a ottenere una risposta da loro, insieme a una linea temporale definitiva a cui si impegnano. Ad un certo punto, se continuano a rimandare, alla fine potresti voler dire loro che pubblicherai comunque - e poi dare loro un po 'di tempo per risolverlo effettivamente (ma breve e limitato).
18
AviD

Questo è un diamine di un argomento complesso. Sono stato coinvolto nella divulgazione del bug di rinegoziazione TLS un paio di anni fa, e credetemi, abbiamo cercato molto duramente di essere "responsabili", ma alla fine siamo riusciti principalmente a far incazzare tutti quelli che ci circondavano e (forse) a ritardare la versione effettiva della correzione. Per non dire che la notifica del fornitore è necessariamente negativa, solo che è davvero facile essere frustati e finire causando più danni che buoni o peggiori.

Nel nostro caso, ci è voluta un'azione dell'IETF ( RFC 5746 ) per risolvere il problema, e anche se avevamo una bozza di Internet pronta il giorno in cui trapelava, l'effettivo lavoro di dibattito e decisione su la soluzione ha richiesto circa altri tre mesi e non è stata realmente avviata sul serio fino alla divulgazione.

Comunque, questa non è una risposta alla tua domanda, ma è una delle storie di divulgazione più interessanti di cui sono a conoscenza. Maggiori informazioni su quella storia nel keynote di ShmooCon 201 l'ho fatto con Marsh Ray, che ha scoperto il problema.

11
Steve Dispensa

In generale, dipende dalla risposta del fornitore. La buona pratica è quando il ricercatore di sicurezza informa il fornitore della vulnerabilità, quindi durante la conversazione si parla di termini di pubblicazione di poc/exploit di questa vulnerabilità. In realtà, il ricercatore sceglie cosa fare con questa vulnerabilità - pubblica più tardi o no. Quindi il fornitore rilascia patch o nuova versione del prodotto. Può essere. Ma come mostra l'esperienza - non tutti i venditori sono così carini. Alcuni risolvono i bug in modo silenzioso, senza informare gli utenti finali e i ricercatori, altri preferiscono ignorare i ricercatori. Altri addirittura provano a fare causa. Ecco perché a volte l'anonimato è un modo preferibile di comunicazione iniziale con un fornitore sconosciuto.

Vorrei anche ammettere che ci sono programmi di ricompensa di bug bounty - quelli offerti da Google, Mozilla. Inoltre, altri acquistano vulnerabilità - ZDI , iDefense , SNOsoft , in arrivo "exploit hub", e ecc. Quindi, ci sono almeno tre modi per informare il fornitore - direttamente, pubblicando informazioni sulla vulnerabilità in un elenco o tramite società di terze parti.

8
anonymous

Se hanno un localizzatore di problemi pubblici, vedi se riesci a presentare un bug con un'etichetta "privata" o "di sicurezza".

Indipendentemente dal fatto che abbiano un tracker dei problemi, invia un'email [email protected] nome azienda e informali.

Se non rispondono abbastanza prontamente (vedi "Finestra di divulgazione" nell'articolo di Schneier di seguito), devi pensare a divulgarlo più ampiamente. Cerca le mailing list su cui si nascondono accademici/professionisti della sicurezza e chiedi loro come segnalare problemi al fornitore in questione. Potrebbero essere in grado di fare presentazioni nel posto giusto all'interno dell'organizzazione.

Se tutto ciò non riesce, leggi la parte di Schneier e pensa se la completa divulgazione sarebbe parte del problema o parte della soluzione.

Bruce Schneier fornisce un argomento per divulgazione completa in determinate circostanze basato su uno standard "essere parte della soluzione, non parte del problema". Vale sicuramente la pena leggerlo.

Questo è il classico dibattito "segretezza dei bug contro divulgazione completa". Ne ho già scritto in precedenza in Crypto-Gram; anche altri ne hanno scritto. È un problema complicato con implicazioni impercettibili in tutta la sicurezza del computer, e vale la pena discuterne ancora.

...

Questo flusso gratuito di informazioni, sia di descrizione che di codice di prova, è anche vitale per la ricerca sulla sicurezza. La ricerca e lo sviluppo della sicurezza informatica sono sbocciati negli ultimi dieci anni e gran parte di ciò può essere attribuito al movimento di divulgazione integrale. La capacità di pubblicare risultati di ricerca, sia positivi che negativi, porta a una migliore sicurezza per tutti. Senza pubblicazione, la comunità della sicurezza non può imparare dagli errori reciproci. Tutti devono operare con i paraocchi, facendo gli stessi errori più e più volte. La piena divulgazione è essenziale se vogliamo continuare a migliorare la sicurezza dei nostri computer e reti.

...

In secondo luogo, credo nel dare preavviso al venditore. Il CERT ha portato questo estremo, a volte dando al venditore anni per risolvere il problema.

...

Mi piace la metrica "essere parte della soluzione, non parte del problema". La ricerca sulla sicurezza fa parte della soluzione. Convincere i fornitori a risolvere i problemi fa parte della soluzione. Seminare paura fa parte del problema. Consegnare strumenti di attacco a adolescenti senza conoscenza è parte del problema.

6
Mike Samuel