Passi da seguire per una corretta e responsabile Vulnerability Disclosure
Tempo di lettura: 10 minutiData pubblicazione: February 7, 2018
Ieri diverse testate hanno fatto sapere che Evariste Gal0is è formalmente indagato con l’accusa di accesso abusivo a sistema informatico, a causa della disclosure fatta ai danni del M5S l’estate scorsa. In quel periodo Evariste, dopo aver trovato delle vulnerabilità nel sito del partito, avvisò via mail i gestori dei problemi trovati rendendo successivamente pubblica la notizia. L’aver scoperto (e reso pubblica) una vulnerabilità di un partito politico (il movimento della rete!1!) ha creato un caos mediatico infinito, tra chi lo sosteneva e chi lo attaccava, fino ad arrivare alla brutta notizia della denuncia e conseguente indagine, che, spero per lui, avrà un lieto fine.
Questo significa che chiunque trovi una vulnerabilità in un sito deve aver paura di segnalarla o pubblicarla? No, no e di nuovo no. Ma andiamo con ordine.
Gli obiettivi di una divulgazione di vulnerabilità, secondo la documentazione ISO/IEC 29147:2014, includono:
- Permettere ad esterni l’invio di informazioni su possibili vulnerabilità identificate.
- Assicurarsi che le stesse siano risolte in tempi brevi.
- Minimizzare il rischio di essere sfruttate da terze parti.
- Evitare di conseguenza il rilascio di informazioni sensibili.
Dal punto di vista di un azienda informata di una possibile vulnerabilità, i passi da seguire sono quindi molto semplici e riportati nella documentazione sopra citata
Dal punto di vista dell’utente, il discorso si fa un pelo più complicato.
Identificazione di una falla
Identificare una falla in un sito, specialmente per chi lavora nel campo della sicurezza informatica, può essere questione di attimi. Durante la navigazione sul mio sito preferito inserisco un apice nella ricerca, un punto e virgola nel campo password, un qualsiasi carattere che potrebbe mandare in crisi l’applicazione web, la quale ritorna un bel messaggio d’errore, stuzzicando di conseguenza la mia curiosità. Essa mi porta poi a testare attacchi base, come SQL Injection o vettori XSS, che non interrompono il servizio offerto dal sito internet, di fatto non hanno reali intenzioni maligne, ma servono solo a verificare se il sito ha problemi di sicurezza.
Ma anche senza nessuna interazione, tramite semplici ricerche su Google si possono trovare centinaia di siti vulnerabili, file di configurazione, di backup, database interi!
L’accesso a queste informazioni non è reato, non abbiamo aggirato protezioni, non abbiamo passato centinaia di ore ad individuare una falla per sottrarre i dati degli utenti, e, di fatto, non c’è nessun accesso abusivo. Ora sappiamo che l’applicazione è potenzialmente vulnerabile, abbiamo anche trovato diversi dati sensibili appartenenti agli iscritti. La strade che si possono percorrere sono diverse, vediamone un paio.
Non disclosure
La comunità black hat utilizza solitamente questa modalità, ossia la non divulgazione della vulnerabilità. Questa modalità ha diversi svantaggi e ben pochi vantaggi:
- Se chiudiamo il sito senza segnalare la falla ai diretti interessati, stiamo lasciando che chiunque, in possesso delle stesse nostre capacità, avrà la possibilità di accedere al sistema, rubando i dati degli utenti;
- Nel caso sfruttassimo la falla e utilizzassimo i dati trovati a fini economici, inutile dirlo, ci porta dritti dritti all’effettivo accesso abusivo e violazione di sistema informatico, andando a ricadere nell'articolo 615-ter.
Da notare anche che, in assenza di misure di sicurezza, l´introduzione in sistemi informatici non costituisce reato!
Responsable Disclosure
Bene, abbiamo deciso di segnalare la falla ai diretti interessati, ma come facciamo? Chiamiamo l’assistenza clienti dicendogli che con una SQL Injection possiamo dumpare il database e potenzialmente creare migliaia di euro di danni all’azienda? Il pattern da seguire è e dovrebbe essere uno, ma si sa, nulla è mai semplice come sembra.
Trovare informazioni e contattare il produttore
Che sia un sito o un software, il primo passo da seguire è l’identificazione di chi possiede il prodotto vulnerabile e la conseguente collezione di indirizzi mail o contatti da poter utilizzare per la segnalazione. Alcune fonti possono essere:
- Sezione contatti del sito produttore.
- Indirizzi mail, come info@, assistenza@, etc.
- File security.txt.
- Whois della pagina internet o delle pagine ad essa collegata.
- Canali social, come Facebook, Twitter o Linkedin.
Prima di qualsiasi segnalazione, verificate se l’azienda/sito in oggetto abbia o meno una policy sulla disclosure di vulnerabilità; solitamente si può trovare con una semplice ricerca nel sito o cercando su un motore di ricerca query del tipo ‘vulnerability disclosure inurl:sitovulnerabile’. Nel caso sia presente, i dettagli e le informazioni dettagliate saranno presenti in quella pagina
L’obiettivo del cercare più contatti possibili è l’avere maggiori probabilità di ricevere una risposta. Una volta contattati, è solo questione di tempo e di attesa. Esso dipende da molti fattori (ad esempio la gravità della vulnerabilità) ed è principalmente soggettivo (Luigi Auriemma impone il limite a una/due settimane di attesa). Scaduto il tempo si hanno due possibilità:
- Il produttore o chi per lui, ha preso in carico la segnalazione e risolve la vulnerabilità in breve tempo. Benissimo, il lavoro è già finito! Se d’accordo, sarà il produttore stesso a dare la possibilità di pubblicare le informazioni trovate (un ottimo esempio è Luca milano e 18 app).
- Il produttore non risponde. Inventiamoci altre idee per contattarli, ad esempio provando a contattarli pubblicamente sui social. Ancora nulla? Passiamo al prossimo step.
Silenzio del produttore
Nel caso in cui nessuno si faccia sentire dopo il tempo limite, un’altra possibilità è contattare il CERT Italiano, il quale prenderà in gestione la vulnerabilità e si occuperà di segnalare nuovamente all’azienda il problema. Mi è capitato diverse volte di doverli contattare e sono stato piacevolmente colpito, mentre le mie mail erano perennemente senza risposta, loro son sempre stati in grado di raggiungere l’azienda. Oltre al CERT Nazionale, segnalo anche la presenza di:
- CERT-PA: da poter contattare nel caso di vulnerabilità e/o segnalazioni in merito a domini della Pubblica Amministrazione;
- PI-CERT: come sopra, ma per Poste Italiane.
Se neanche i magici contatti del CERT funzionano e passato altro tempo il problema è ancora li, l’ultima spiaggia etica è una segnalazione al garante della privacy, il quale, una volta verificata che c’è un effettiva violazione della privacy degli utenti da parte dell’azienda, prenderà, si spera in tempi brevi, provvedimenti contro la stessa.
Pubblicazione della vulnerabilità
Questo è l’ultimo passaggio, ed è solitamente il più rischioso.Non c’è stata risposta dall’azienda, il CERT non è riuscito a contattarla e i dati degli utenti sono ancora lì, disponibili a chiunque sia intenzionato a prenderli. Pubblicare un articolo su ciò che si è trovato è effettivamente una buona idea, da risalto alla notizia e l’azienda è costretta a correre ai ripari, pena la gogna mediatica e la possibilità concreta che un black hat sfrutti davvero i problemi con intenzioni non troppo buone.
Questo però ci porta ad un potenziale rischio di denuncia (come nel caso di Evariste), in quanto il produttore potrebbe erroneamente pensare che abbiamo avuto accesso ai dati, li abbiamo scaricati e visionati, magari anche condivisi.
Conclusioni
Questi passi non vogliono essere una regola da seguire, ma solo consigli da chi è passato più volte su questa strada. Le regole che mi sento di dare son molto semplici:
- Da parte nostra ci deve essere sempre piena trasparenza, apertura e disponibilità.
- Testare un sito può essere un bene, ma entro certi limiti. Nel caso questi si tenda a superarli, utilizzare servizi di anonimizzazione non fa mai male.
- La pubblicazione di un articolo, senza che il produttore ne sia a conoscenza, come detto è rischioso. Se non si vogliono avere beghe, c’è sempre la possibilità di pubblicarlo senza nominativo e in maniera anonima.
- Se si vogliono testare le proprie capacità, ci sono piattaforme come Hackerone e Bugcrowd che danno la possibilità di testare la sicurezza di applicazioni web.
Se avete altre idee, son più che disponibile a modificare l’articolo, inserendo quelle più utili (aggiunto policy di vulnerability e CERT-PA, grazie alla segnalazione di glamismac)