Leggo ancora su Heise del sito per la messa all’asta di vulnerabilità. Ho già scritto quanto sono contrario a questa iniziativa, ma credo che valga la pena di ripeterlo, alla luce di quanto riportato da Heise. Anzi, partiamo da un’altro articolo, quello che riporta di vulnerabilità in un prodotto Checkpoint valutato EAL 4+. L’articolo dice che “The investigators informed Checkpoint of these holes some months ago, but have not been contacted by the vendor to engage in an exchange of information”. Ora, supponiamo che questi “investigators” (bug hunter?), visti gli scarsi risultati, la prossima volta che trovano una vulnerabilità in quel prodotto decidano di agire diversamente. Finora le opzioni erano: rendere pubblica la vulnerabilità, cosa che non avrebbe fornito loro alcun guadagno, o vendere la vulnerabilità “sul mercato nero”, guadagnandoci ma sapendo di averla probabilmente consegnata a qualche delinquente. A seconda della loro etica, la seconda strada non era percorribile. Ora hanno una terza possibilità: metterla all’asta, in un contesto che non sembra creare gli stessi problemi etici del mercato nero. Infatti, dice, Roberto Preatoni, “the organisations accessing the WSLabi website most frequently are Cisco, Microsoft, IBM, Veritas, Symantec, F-Secure, the U.S. army, Oracle, VeriSign and SAP”.
Allora, la domanda è: chi può essere interessato ad accedere ad una vulnerabilità, se non chi la deve correggere nei propri prodotti? Le risposte sono sostanzialmente tre: primo, chi vuole usarla per proteggere i propri sistemi che usano quel prodotto (creando delle patch in proprio, o esercitando pressioni sul produttore); secondo, aziende di sicurezza che pensano di utilizzarla nei propri servizi e prodotti (e in questo caso, è probabile che comunque prima o poi la vulnerabilità finisca “in the wild”); terzo, entità che pensano di utilizzarla contro sistemi altrui. Ma ecco, per evitare il problema che i delinquenti usino anche questo canale, Preatoni dice che “To prevent criminals from obtaining information via WSLabi, purchasers are subjected to a number of checks by WSLabi staff, including comparing ID card details with bank account details”.
Bene, quindi i frequentatori non sono criminali… ma potrebbero comunque usare la vulnerabilità nei confronti dei sistemi di terzi? Prendiamo l’US Army: potrebbe ritenere opportuno utilizzare una tale vulnerabilità sui sistemi di paesi terzi, o passarla ad altre agenzie con questo interesse? Forse potrebbe, certamente non lo farà e comunque loro sono i buoni e quindi non contano 😉 Supponiamo che l’esercito russo decida di frequentare il sito; potrebbe? Quello israeliano? Quello cinese? Quello somalo? Un’agenzia di security privata? L’azienda di qualche noto ma incensurato spammer americano? Quella che fa da copertura a un’organizzazione criminale? Dov’è che il fatto di verificare “comparing ID card details with bank account details” finisce di separare i buoni dai cattivi? O forse vale solo per alcuni grossi nomi? E supponiamo che il sistema prenda piede, ma che WabiSabiLabi non accetti uno dei soggetti appena citati, non sarebbe ormai leggittimata a quel punto la nascita di un altro sito con criteri di ammissibilità appena un po’ più laschi, e quindi certamente con la capacità di spuntare prezzi più alti?
Il problema di fondo è che ci deve essere una posizione etica forte contro la vendita delle vulnerabilità ad altri che non sia il produttore del software interessato. Chi non si fa turbare dall’etica, vende comunque sul mercato nero. Chi ne tiene conto non si troverà a vendere a dei delinquenti solo perché la cosa è fatta alla luce del sole.
Tuttavia, è chiaro che i NO non aiutano a risolvere i problemi, e qui c’è il problema del bug hunter che vuole guadagnare sulla propria attività. Sia chiaro che rimango della mia posizione iniziale: non è legittimo fare un lavoro che nessuno ha richiesto, e poi pretendere che “qualcuno comunque paghi”. A me ad esempio piacerebbe fare il Dungeon Master professionista, ma mi sono dovuto rassegnare a fare un lavoro richiesto e legale. Ma ci sono delle possibilità. L’unica volta che mi sono messo a fare il bug hunter (per scommessa) ho trovato con un amico alcune vulnerabilità in Netscape Communicator. Netscape allora ci ha “premiati” con 1000$, un cappellino e una maglietta. Per quanto non sia stato soddisfatto di come è stata poi gestita la cosa, sicuramente se il mio scopo fosse stato il guadagno, i 500$ che mi sono spettati avrebbero tranquillamente ripagato il tempo che ci ho speso (in proporzione alla “competenza” che mi è servita per trovare le vulnerabilità). D’altra parte Microsoft & C frequentano il sito di WabiSabiLabi, quindi in qualche modo sembrano disposte a pagare, almeno in alcuni casi. Quindi, forse il problema è il prezzo. Allora WabiSabiLabi potrebbe avere un altro ruolo, sempre di intermediazione ma più etico. Ad esempio, (la butto lì, ovviamente) potrebbe aiutare a fissare un “prezzo pubblico di mercato” dei diversi tipi di vulnerabilità, in funzione del prodotto interessato e della gravità. Il bug hunter poi, attraverso il sito, potrebbe proporre ma solo al produttore la vulnerabilità; questi può decidere di comprarla al prezzo di mercato, o di rifiutarla. Nel secondo caso, la vulnerabilità viene resa pubblica secondo criteri di responsible disclosure, ma insieme alla notizia che il produttore si è rifiutato di pagare, supponiamo, 500$ per quella vulnerabilità. Se la vulnerabilità è seria, allora il produttore ne avrà un danno in immagine (ha messo a rischio i suoi utenti per pochi soldi) che potrà superare il prezzo della vulnerabilità, ma il meccanismo di responsible disclosure limita i danni che possono essere causati dalla vulnerabilità in sè. Inoltre, il produttore non si mette al riparo dal danno di immagine dato dalla presenza stessa della vulnerabilità, che poteva invece “patchare silenziosamente”. Se invece la vulnerabilità non valeva il prezzo richiesto, allora il bug hunter fa la sua figuraccia. Il prezzo di mercato per quel tipo di vulnerabilità varia di conseguenza (sale se era buona, scende se era una bufala), e la volta successiva il produttore si troverà a pagare di più o di meno. In questo modo, è chiaro che il bug hunter si assume una serie di rischi: primo fra tutti, di impiegare un sacco di tempo per trovare una vulnerabilità che non lo ripaga del tempo speso o non viene comprata. Ma d’altra parte, è lo stesso rischio che corre un cercatore d’oro o un cacciatore di taglie. Se è bravo, ci può campare; altrimenti, si troverà un altro lavoro.
