Bug Bounty e Open Source

Forse non tutti conoscono i Bug Bounty Program. Un Bug Bounty è una specie di concorso a premi indetto da una azienda di software, aperto a tutti, consistente nel trovare bachi (bug) nei prodotti e nel comunicarli al produttore. Se la notifica viene valutata positivamente, ovvero, se viene verificato che effettivamente è stata trovata una vulnerabilità od un exploit, il cacciatore viene premiato in vari modi: denaro, gadget, sconti ed il suo nome viene aggiunto alla “All of Fame”pubblicata nel sito dell’azienda in questione.
Quasi tutte le aziende di software sfruttano questo metodo per avere, praticamente a costo zero, un gran numero di analisti e specialisti di sicurezza a spulciare programmi e cercare falle nei propri prodotti.

Insomma, si potrebbe dire che le aziende produttrici di software proprietario si sono accorte che tanti occhi vedono meglio di pochi.
Aspetta un momento, ho già sentito questa frase…
Ma certo! É una delle frasi famose relative all’open source software! In realtà la citazione originale sarebbe “Dato un numero sufficiente di occhi, tutti i bug vengono a galla” ed è contenuta nel testo “la cattedrale ed il bazaar” di Eric Raymond, nel quale si può anche leggere “Con molti occhi puntati addosso, ogni bug diventa una bazzecola”.

Si può quindi individuare un parallelo fra la teoria del bazar e i programmi di ricerca di falle nei programmi basati sulla attività non ufficiale della gran  massa di esperti, ricercatori, appassionati che gratuitamente, giornalmente, analizzano programmi ed applicazioni.

Certo, non esistono solo i bravi ragazzi che una volta trovata una vulnerabilità si precipitano ad avvisare il produttore, anzi. Il mercato degli 0-Day è vivo e vegeto e si alimenta giornalmente con nuove offerte.
Una volta individuata e verificata in laboratorio una falla, coloro che seguono il lato oscuro della forza, possono scegliere di vendere la vulnerabilità, creare uno 0-Day od effettuare una “full disclosure”.
Se si sceglie di effettuare una “full disclosure”, tutte le informazioni relative alla vulnerabilità individuata vengono rese di pubblico dominio, in genere attraverso servizi o mailing list specializzate e spesso anonime.
Chi si occupa di sicurezza dal lato buono della forza segue quella che è definita “responsible disclosure”.
La “responsible disclosure” prevede che venga contattata l’azienda produttrice che potrà o meno rispondere (eh già, potrebbe anche non rispondere) e confermare al cacciatore la vulnerabilità,   premiandolo in qualche modo. Il ricercatore/cacciatore accetta di non divulgare alcuna informazione fino a quando l’azienda non abbia realizzato una patch o comunque analizzato e chiuso il problema.
Una volta giunti a questo punto,  le informazioni possono essere liberamente pubblicate ed il ricercatore/cacciatore ha il suo momento di gloria. Se invece, a giudizio del ricercatore, trascorre un lasso di tempo troppo lungo senza risposta o se la risposta dell’azienda è negativa, spesso si sceglie di rilasciare le informazioni in full-disclosure.
La scelta di pubblicare comunque le informazioni sulla vulnerabilità sono dettate dalla coscienza personale ma in genere i motivi addotti sono due: dimostrare all’azienda il suo “errore” nel non considerare importante la sicurezza dei propri prodotti e rendere consapevoli gli utilizzatori del problema sapendo bene che esiste la possibilità che esista già un exploit o 0-day che sfrutta quella specifica falla.
E’ ovvio che si tratta di una scelta che comporta la possibilità che qualcuno sfrutti le informazioni pubblicate per crearsi il proprio exploit, è un rischio.

Un vantaggio nello sfruttare il supporto delle comunità e della filosofia propria del movimento Free Software / Open Source esiste, se è vero come è vero che diversi bug sono stati scoperti e risolti  in Magento  anche grazie alla Security Challenge indetta dall’azienda ed il cui vincitore sarà proclamato il prossimo 30 novembre.

Ecco un paio di esempi relativi a  Magento. La persistent filename vulnerability individuata verso metà agosto e fixata ai primi di settembre od ancora più recentemente la Multiple CSRF Web Vulnerabilities, scoperta a fine settembre, fixata e rilasciata al pubblico dominio pochi giorni fa.

Come potete vedere, c’è un preciso percorso che viene seguito dal momento della scoperta della vulnerabilità a quello della pubblicazione ufficiale ed a volte passa molto tempo prima della disclosure ufficiale per la necessità di verificare il problema e trovare la soluzione.

Sia come sia, alla fine il problema rimane sempre lo stesso. Non esiste un software sicuro al 100% ed è obbligatorio che le patch e gli aggiornamenti rilasciate via via dai produttori siano applicate tempestivamente.

Ricordate però che è buona norma testare in un ambiente sicuro, appositamente predisposto, tutte le modifiche prima di applicarle al sistema in produzione.
Dimenticare o semplicemente non adottare questa precauzione per pigrizia o per risparmiare potrebbe portare a gravi conseguenze come alcune recenti esperienze hanno dimostrato.