Il Bug Bounty nasce dalla necessità delle aziende di testare la sicurezza della loro infrastruttura. Prima, infatti, questo compito era esclusivamente assegnato al settore IT interno dell'azienda e, come spesso accade, non tutte le problematiche venivano subito alla luce, facendogli rischiare faccia e denaro.
L'idea di aprirsi ad un pubblico più vasto, deriva dal semplice concetto che dice: "Ci sarà sempre qualcuno che ne sa più di te". E quale miglior modo di aprirsi, se non quello di invitare 7 miliardi di persone a parteciparvi? I vantaggi principali per l'azienda che apre un Bug Bounty Program sono:
- Avvalersi della "folla" partecipante per trovare e fixare i bug in tempi decisamente più brevi rispetto a quelli che potrebbe avere il settore IT interno;
- Per quanto riguarda il lato economico, invece, è molto più vantaggioso pagare solo i bug validi piuttosto che mettere a lavorare dei dipendenti e doverli pagare ad ore (e magari trovare solo la metà dei bug - 100 occhi sono meglio di 2);
- Contatto diretto con i ricercatori - Capita che i bug segnalati siano delle vere e proprie metodologie d'attacco sconosciute fino a quel momento. Il contatto con il ricercatore permette di trovare insieme e velocemente una soluzione al problema;
- E come ultimo punto, ma non meno importante, è che il Bug Bounty è un ottimo strumento per contrastare il black market. Esistono infatti dei "luoghi" (principalmente forum sotto la rete The Onion Router - TOR) dov'è possibile comprare e vendere ogni sorta di bug, exploit, carta di credito, login istituzionali e chi più ne ha più ne metta. È lì che il cyber-criminale andrebbe a vendere un bug per Facebook qualora non ci fossero i Bug Bounty. I tipici compratori di un black market sono quei cyber-criminali già "avviati" che investono una parte dei soldi provenienti dal phishing e dallo spam per nuove tipologie di bug;
Gli svantaggi che potrebbero presentarsi nell'avviare un programma di Bug Bounty potrebbero derivare dalla scarsa qualità dell'infrastruttura, rischiando quindi un collasso delle macchine di produzione.
Nasce così una sorta di "febbre del bug" fra gli ethical hackers e security researchers di tutto il mondo, pronti a scovare le falle nelle più remote zone del sistema sotto analisi. Ma attenzione: come ogni "gioco" che si rispetti, ci sono delle regole da non violare per nessun motivo...
Come vedrete infatti sulla stragrande maggioranza dei Bug Bounty, i contest hanno delle limitazioni esplicite ed implicite. Fra le più comuni troviamo:
- DDoS - Non è possibile effettuare tentativi di Denial Of Service per evitare che l'infrastruttura risulti irraggiungibile anche ai normali utilizzatori, ma anche perché il DDoS non è considerato un bug;
- Brute Force - Viene visto un po' come il Denial of Service, perché trovare una password tramite l'utilizzo di forza bruta non è considerato un bug;
- Social Engineering - Le tecniche di ingegneria sociale non sono permesse per evitare che si generi del caos all'interno dell'azienda. Ve la immaginate la segretaria rispondere al telefono a domande di cui non conosce la risposta, oppure finti operai che si presentano alla porta della società per effettuare "manutenzione"?
Per quanto riguarda i compensi offerti dai bug bounty c'è da dire che la maggior parte utilizza solo la "Hall of Fame", una pagina dedicata in cui si racchiudono i nomi e cognomi dei ricercatori che hanno segnalato il bug, per l'appunto: "Stanza delle fama".
Foto di copertina tratta da Shutterstock
Esistono diverse categorie di società che hanno fatto del Bug Bounty un business:
Aperte |
Centralizzate |
Competizioni |
On Demand |
Netscape |
iDefense |
Pwn2Own |
HatForce |
Mozilla Firefox |
ZDI |
Deutsche Post |
BugWolf |
Google Chromium |
CrowdSec |
||
Google Web |
CrowdSecurify |
||
Mozilla Web |
BugCrowd |
||
Barracuda |
|||
Hex Ray |
|||
Etsy |
|||
Nokia |
Aperte: Si intendono tutti quei Bug Bounty aperti a tutti gli appassionati del settore, senza nessun tipo di restrizione geografica né temporale. Il programma con le limitazioni e i domini/IP sotto analisi sono pubblicamente consultabili.
Centralizzate: Qui sono racchiuse tutte le società (private) che pagano gli hacker per "rifornirli" di bug (0day) in modo da poterli usare per scopi personali. Spesso i bug vengono comunque resi pubblici dopo un certo periodo di tempo. Non esistono programmi o regole ben precise. Ci si registra, si propone un bug e loro decidono se accettarlo ed eventualmente quanto pagarlo.
Competizioni: Si racchiudono qui tutti quegli eventi che hanno un inizio ed una fine ben precisa nel tempo; spesso è richiesta la presenza fisica sul luogo dell'evento. Generalmente si lavora in team. La più famosa competizione è sicuramente il Pwn2Own (gergo informatico che starebbe per " hackerare per umiliare") che si tiene ogni anno in Canada durante il CanSecWest. Si mettono sul "banco di prova" tutte quelle tecnologie che il produttore vanta essere prive di bug. Chiunque riuscisse ad eseguire exploit sfruttando un bug non noto, avrà in premio il dispositivo ed una ricompensa in denaro (nel 2012 Google mise in palio ben 1.000.000$ a chiunque fosse riuscito a trovare falle di sicurezza su Chrome, il suo famoso browser).
On Demand: Sono tutte le società che si occupano di effettuare dei Penetration Test su richiesta. Il team interno è generalmente dislocato su tutto il territorio mondiale. Il meccanismo è semplice; esistono principalmente 3 figure in questo campo: Il cliente, gli intermediari, il team tecnico.
- Il cliente richiede agli intermediari un test della sua infrastruttura;
- Gli intermediari danno al team tecnico tutte le informazioni utili per avviare la ricerca dei bug e delle regole da rispettare per quel determinato sistema bersaglio;
- Il team viene pagato dagli intermediari per ogni bug valido trovato;
- Gli intermediari vengono pagati (di più?) dal cliente per ogni bug valido riportato;
Per questa ultima categoria risulta chiaro che gli intermediari non potrebbero essere del tutto trasparenti con il team tecnico. Inoltre c'è da mettere in dubbio la questione della riservatezza dei dati: il team tecnico (che è composto da dozzine di security specialists) potrebbe rivendere a terzi i dati che riesce a tirar fuori dalla società bersaglio. E se così fosse, è possibile arrivare al colpevole?
I numeri del Bug Bounty di Mozilla
È arrivato il momento di dare uno sguardo alle statistiche di un Bug Bounty. I dati sotto riportati sono stati presi dalla presentazione di Michael Coates, durante la conferenza AppSecUSA del 2011. Riportano le statistiche del bug bounty avviato da Mozilla fra Novembre 2010 e Settembre 2011:
Come si può vedere dall'immagine, il picco più alto è stato raggiunto non appena la competizione è stata aperta al pubblico (Dicembre 2010). Questo potrebbe indicare che c'erano molte persone che avevano trovato dei bug ed erano in attesa di poterli vendere a terzi (oppure li usavano per scopi personali). Passato questo "punto critico" la segnalazione dei bug si stabilizza fino a Settembre 2011 sulla media di 10-12 Bug al mese.
In questo grafico a torta è possibile avere una statistica di quante volte siano state ricevute segnalazioni per lo stesso bug. I duplicati, infatti, non vengono mai pagati. Solo il primo segnalatore riceverà la sua meritata ricompensa.
È impressionante vedere come la maggior parte dei bug segnalati (il 60%) siano Cross Site Scripting (XSS). Sono sicuramente i meno pagati, ma una decina di questi potrebbero valere quanto una SQL Injection. Di minore popolarità invece problematiche di autenticazione ("auth" sul grafico).
Numero di bug riportati |
Percentuale a persona |
1 Bug |
47 % |
2-5 Bugs |
33 % |
6+ Bugs |
20% |
La tabella riporta la percentuale con cui un solo ricercatore ha segnalato i bug. Ben il 20% delle persone partecipanti al Bug Bounty ha segnalato piu di 6 Bugs riconosciuti come validi.
Passando al lato economico, possiamo riassumere che Mozilla ha pagato 104.000,00$ (da Dicembre 2010 a Settembre 2011) per un totale di 64 bug riconosciuti come validi a 24 ricercatori diversi. Le uscite nel dettaglio sono le seguenti: