Last Updated on February 2, 2011

Assistendo in questi giorni alle continue scoperte di bachi nell’Androide non posso fare a meno di chiedermi se queste siano dovute ad una effettiva insicurezza della creatura di Google (che comunque si difende bene a livello di bachi con i suoi 0,47 bachi ogni 1000 linee di codice ben al di sotto dei 5 bugs/Kloc considerati fisiologici) oppure siano una conseguenza del processo di diffusione dell’Androide anche in ambito enterprise, diffusione che attira i malintenzionati e pone l’accento sui problemi  di sicurezza, soprattutto se relativi alla possibilità di ottenere illecitamente le informazioni contenute, il cui valore è maggiormente critico per gli utenti business.

Non si è ancora spenta l’eco della botnet di androidi privi di volontà (o meglio esecutori della volontà remota di qualcun’altro), che già nuove avvisaglie di tempesta si innalzano dall’orizzonte della Shmoocon appena conclusa.

Durante l’evento, due ricercatori di sicurezza, Jon Oberheide e Zach Lanier, hanno evidenziato alcune debolezze nel cervello kernel dell’Androide e nella modalità di gestione delle applicazioni.

Tra le debolezze rilevate (a livello teorico):

• Il codice sorgente è facile da ottenere (e di conseguenza da sfruttare);
• Realizzando giochi e applicazioni esteticamente gradevoli (fun-looking), e riuscendo a convincere gli utenti a scaricarle, sarebbe teoricamente possibile realizzare un attacco agente direttamente sul kernel, dopo averne identificato le debolezze;
• La piattaforma è piena, a loro dire, di complicati appicicaticci facili da sfruttare.

I due ricercatori erano già saliti alla ribalta a novembre 2010 quando avevano presentato un proof-of-concept travestito nell’arcinota applicazione Angry Birds (un fake come si dice in termine tecnico), con cui erano stati in grado di bypassare il processo di approvazione dei permessi del sistema operativo e rubare incautamente il token di Autenticazione dall’Android AccountManager. In quell’occasione il codice malevolo era stato in grado di installare nell’Androide vittima e rigorosamente all’insaputa dell’utente, tre applicazioni in grado di accedere ai contatti, alle informazioni di posizione e agli SMS, trasmettendo, come se non fosse già abbastanza i dati a un server remoto.

E la drammatica conclusione era stata:

• Intercettare le credenziali è relativamente semplice;
• Le applicazioni che accedono allo storage, contengono bachi di sicurezza che un attaccante potrebbe sfruttare per causare un denial of service o bypassare i controlli di gestione dei diritti digitali (digital rights management);
• Le applicazioni fornite direttamente dai carrier facilitano la fiducia dell’utente e pertanto saltano il primo e fondamentale livello di sicurezza, quello che proviene dall’utente;
• Le applicazioni di terze parti hanno un livello di sicurezza aggiuntivo (ma manca un supporto per standard aperti);
• Gli attacchi di tipo Man-in-the-middle sono relativamente semplici da attuare.

In sostanza, forse per la relativa giovinezza di questo mercato, il codice delle app è infarcito di errori di programmazione dovuti all’esigenza di raggiungere per primi il mercato (il time-to-market non perdona!), errori che nel mondo dei PC si facevano parecchi anni orsono.

Visto che quasi tutte le vulnerabilità degli smartphone con un cuore di Androide sono legate ai permessi delle applicazioni e alla conseguente possibilità di rubare informazioni sensibili (e non solo), è auspicabile (come anche previsto da Cisco) che la prossima frontiera del mercato di sicurezza per gli smartphone saranno propio le tecnologie DLP (Data Leackage Prevention) per la prevenzione del furto o perdita di dati. Questo spiegherebbe anche perché i principali produttori di sicurezza (e protagonisti del mercato DLP, non ultimi McAfee, Symantec e Trend Micro), abbiano messo proprio l’Androide al Centro dei problemi di sicurezza per il 2011.