Diffondi il sapere

15 luglio 2014. Google annuncia sul proprio blog orientato alla sicurezza la nascita di un team dedicato all’individuazione delle vulnerabilità zero-day in qualsiasi software usato dagli utenti. La guida è affidata a Chris Evans, già responsabile del team di sicurezza di Google Chrome (passerà poi a occuparsi della sicurezza in Tesla).

 

A caccia di Hacker

Nel marzo 2014 George Hotz (nome in codice geohot), il primo ad aver hackerato un iPhone per eseguire un jailbreak e conosciuto per l’hacking della PS3 che lo porterà alla querela da parte della Sony ritirata solo dopo la promessa di non interferire più nei suoi prodotti, durante il Pwnium hacking contest vince la competizione sfruttando una catena di exploit che gli permette di hackerare un Chromebook 11 eseguendo un programma in maniera permanente su Chrome OS. Oltre alla ricompensa, riceve l’offerta di entrare nel Google Project Zero.

Nel team, oltre a Hotz, troviamo altri white hacker:

  • Ben Hawkes, che ha scoperto decine di vulnerabilità in software come Adobe Flash, Microsoft Office, Apple iOS e Linux kernel

  • Tavis Ormandy, che ha scoperto gravi vulnerabilità in Libtiff, Sophos antivirus, Microsoft Windows e FireEye (con Natalie Silvanovich)

  • Ian Beer, il primo esperto di sicurezza a pubblicare per il Project Zero prima che il progetto fosse reso pubblico, ha scoperto vulnerabilità nei prodotti Apple, una delle quali ha obbligato quest’ultima a riscrivere una parte significativa del proprio kernel

 

A caccia di fantasmi

Lo studio di vulnerabilità come Heartbleed portò il team di sicurezza di Google a scoprire diverse altre falle in software usati dagli utenti finali. Intanto Edward Snowden aveva portato alla luce nel 2013 le operazioni di sorveglianza e compromissione di massa messe in atto dalla NSA americana anche verso gli utenti di Google. Fu così che l’idea, probabilmente partorita già nel 2010, divenne realtà e annunciata il 15 luglio 2014 con l’istituzione ufficiale di un team, il Project Zero appunto, che dovesse dedicarsi alla ricerca delle vulnerabilità non solo nel software Google, ma in qualsiasi software utilizzato dai suoi utenti.

 “Se facciamo crescere la fiducia degli utenti in Internet, indirettamente questo aiuta Google”

– Chris Evans

Obiettivo primario di questo team è scovare i cosiddetti bug zero-day, non ancora noti alle aziende.

Una finalità “principalmente altruistica” secondo quanto affermato da Chris Evans volta a rassicurare gli utenti e in prospettiva, per ammissione dello stesso Evans, considerata vantaggiosa in quanto un utente tranquillo è anche un cliente che usa più facilmente gli strumenti informatici a tutto vantaggio di altri settori della stessa azienda quali quello pubblicitario.

 

Scoperte di rilievo

  • 30 settembre 2014, individuata falla di sicurezza in Windows 8.1 chiamata NtApphelpCacheControl, che permetteva a un normale utente di ottenere privilegi di amministratore
  • 19 febbraio 2017, scoperta falla, chiamata Cloudbleed, relativa ai reverse proxy di Cloudflare che causava un buffer overflow ad alcuni loro server, rendendo pubbliche aree di memoria contenenti informazioni private quali cookie HTTP, token di autenticazione e altri dati sensibili (alcuni dei quali finirono nella cache dei motori di ricerca)
  • 27 marzo 2017, scoperta vulnerabilità nel popolare gestore di password LastPass
  • 2 gennaio 2018, pubblicata la scoperta di Spectre e Meltdown

 

Non è tutto oro ciò che luccica?

“Ma riparare una falla in un sistema complicato come Windows potrebbe richiedere più tempo. Google vuole solo mettersi in mostra”

– Chet Wisniewski

Ma se per Google è essenziale la velocità di risoluzione al punto di aver stabilito un protocollo automatico per cui una nuova vulnerabilità venga resa pubblica dopo 90 giorni, anche se non risolta, altre aziende non sono dello stesso avviso, prima fra tutte Microsoft, per la quale la pubblicazione di una vulnerabilità dovrebbe essere “coordinata” e “responsabile”: i ricercatori della sicurezza dovrebbero accordarsi e aspettare la disponibilità di patch prima di rendere pubblico un bug. Soprattutto se ciò avviene, come fa Google, rendendo pubblico anche un PoC (proof-of-concept, o prova del concetto) a dimostrazione della fattibilità e fondatezza, fornendo potenzialmente un’utile dritta ai cyber-criminali.

 

© RIPRODUZIONE  RISERVATA

 


Diffondi il sapere

1 thought on “Da Project Zero a Mito

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *