About these ads

Archive

Posts Tagged ‘Jailbreak’

Lo Smartphone? Ha fatto il BOT!

February 23, 2011 2 comments

E’ stato appena pubblicato un interessante articolo di Georgia Weidman relativo al concept di una botnet di smartphone controllati tramite SMS. Il lavoro, annunciato alla fine del mese di gennaio 2011 e presentato alla Shmoocon di Washington, aveva da subito attirato la mia attenzione poiché, in tempi non sospetti, avevo ipotizzato che la concomitanza di fattori quali la crescente potenza di calcolo dei dispositivi mobili e la loro diffusione esponenziale, avrebbe presto portato alla nascita di possibili eserciti di Androidi (o Mele) controllate da remoto in grado di eseguire la volontà del proprio padrone.

Il modello di mobile bot ipotizzato (per cui è stato sviluppato un Proof-Of-Concept per diverse piattaforme) è molto raffinato e prevede il controllo dei terminali compromessi da parte di un server C&C di Comando e Controllo, mediante messaggi SMS (con una struttura di controllo gerarchica), che vengono intercettati da un livello applicativo malevolo posizionato tra il driver GSM ed il livello applicativo. La scelta degli SMS come mezzo di trasmissione (che in questo modello di controllo assurgono al ruolo di indirizzi IP) è dovuto all’esigenza di rendere quanto più possibile trasparente il meccanismo di controllo per utenti e operatori (l’alternativa sarebbe quella del controllo tramite una connessione  dati che tuttavia desterebbe presto l’attenzione dell’utente per l’aumento sospetto di consumo della batteria che non è mai troppo per gli Androidi e i Melafonini ubriaconi). Naturalmente il livello applicativo malevolo è completamente trasparente per l’utente e del tutto inerme nel processare i dati e gli SMS leciti e passarli correttamente al livello applicativo senza destare sospetti.

Georgia Weidman non ha trascurato proprio nulla e nel suo modello ipotizza una struttura gerarchica a tre livelli:

  • Il primo livello è composto dai Master Bot, controllati direttamente dagli “ammucchiatori”. I Master Bot non sono necessariamente terminali (nemmeno compromessi), ma dovendo impartire ordini via SMS possono essere dispositivi qualsiasi dotati di un Modem;
  • Il secondo livello è composto dai Sentinel Bot: questi agiscono come proxy tra i master e l’esercito di terminali compromessi. Le sentinelle devono essere dispositivi “di fiducia”, ovvero dispositivi sotto il diretto controllo degli “ammucchiatori” o membri della botnet da un periodo di tempo sufficientemente lungo da far ritenere che l’infezione sia ormai passata inosservata per il proprietario e degna pertanto di promuoverli al ruolo di sentinelle.
  • Il terzo livello è composto dagli slave bot. I veri e propri soldati dell’esercito di terminali compromessi che ricevono le istruzioni dalla sentinelle ed eseguono il volere del capo.

Da notare che questo modello gerarchico applica il paradigma del “divide et impera”. I terminali compromessi slave non comunicano mai direttamente con il master, e solo quest’ultimo, inoltre, conosce la struttura dell’intera botnet. L’utilizzo del SMS inoltre consente al master di poter cambiare numero di telefono all’occorrenza ed eludere così le forze del bene, ovvero gli eventuali cacciatori di bot.

Ovviamente tutte le comunicazioni avvengono tramite SMS cifrati (con un algoritmo di cifratura a chiave asimmetrica) e autenticati, inoltre la scoperta di un telefono infetto non pregiudica l’intera rete di terminali compromessi ma solo il segmento controllato dalla sentinella di riferimento (il master può sempre cambiare numero).

Quali possono essere gli utilizzi di una botnet così strutturata? Naturalmente rubare informazioni, per fini personali o di qualsiasi altro tipo (politici, economici, etc.). Purtroppo, per questa classe di dispositivi, che stanno trovando sempre di più applicazioni verso i livelli alti di una Organizzazione, gli exploit e i bachi sono all’ordine del giorno per cui teoricamente sarebbe possibile rubare il contenuto della memoria SD con un semplice SMS. Ma non finisce qui purtroppo: considerata la potenza di calcolo (abbiamo ormai un PC nel taschino) e la potenza di calcolo, questi dispositivi possono essere facilmente usati come seminatori di traffico, ovvero sorgenti di attacchi di tipo DDoS (Distributed Denial of Service), specialmente nel caso di connessioni Wi-Fi che si appoggiano su un operatore fisso  che offre possibilità  di banda maggiori e quindi più consone ad un attacco di tipo Distributed Denial Of Service. Questo si sposa perfettamente con la dinamicità di una botnet basata su SMS (in cui il master può cambiare numero per nascondersi) e con le infrastrutture degli operatori mobili (o fissi offerenti servizi Wi-Fi) che potrebbero non essere completamente pronte per affrontare simili tipologie di eventi informatici (come anche evidenziato dal recente report di Arbor Networks). Altra nefasta applicazione potrebbe essere lo spam, soprattutto se effettuato tramite SMS. Interessante inoltre la combinazione con il GPS che potrebbe portare al blocco totale delle comunicazioni GSM in determinate circostanze spazio-temporali (sembra fantapolitica ma è comunque teoricamente possibile).

Rimane ora l’ultimo punto che era rimasto in sospeso quando avevo trattato di questo argomento per la prima volta:  mi ero difatti chiesto la questione fondamentale, ovvero se il software malevolo di bot avesse necessità o meno di permessi di root. La risposta è affermativa, ma questo non mitiga la gravità del Proof-Of-Concept, ribadisce anzi l’importanza di un concetto fondamentale: alla base della sicurezza c’è sempre l’utente, il cui controllo sovrasta anche i meccanismi di sicurezza del sistema operativo, e questo non solo perché ancora una volta viene evidenziata drammaticamente la pericolosità di pratiche “smanettone” sui propri dispositivi (che possono avere conseguenze ancora più gravi se il terminale è usato per scopi professionali), ma anche perché gli utenti devono prendere consapevolezza del modello di sicurezza necessario, facendo attenzione alle applicazioni installate.

Lato operatori, urge l’assicurazione che gli aggiornamenti di sicurezza raggiungano sempre i dispositivi non appena rilasciati. Aggiungerei inoltre, sulla scia di quanto dichiarato da Arbor Networks, possibili investimenti infrastrutturali per l’eventuale rilevazione di eventi anomali dentro i propri confini.

A questo punto, il fatto che i produttori di sicurezza abbiano, quasi all’unanimità, inserito il mondo mobile al centro delle preoccupazioni di sicurezza per il 2011 perde qualsiasi dubbio sul fatto che si tratti di una moda passeggera, ed è asupicabile che  gli stessi stiano già correndo ai ripari, aggiungendo livelli di sicurezza aggiuntivi ai meccanismi intrinseci del sistema operativo con l’ausilio di tecnologie di DLP (come indicato dal report Cisco per il 2011), virtualizzazione e integrando sempre di più tecnologie di sicurezza nei dispositivi: ultimo annuncio in ordine di tempo? Quello di McAfee Intel che si dimostra, ancora una volta, molto attiva nel settore mobile.

About these ads

Sbucciare Una Mela In 6 Minuti

February 13, 2011 1 comment

Poteva, questo scorcio di 2011 regalarci (in)soddisfazioni di sicurezza informatica solo per il povero Androide? Niente affatto! Ed ecco che dalla Germania, in particolare dal Fraunhofer Institute for Secure Information Technology (SIT), arriva una interessante analisi sul livello di sicurezza del KeyChain Apple, ovvero l’architettura usata dai sistemi operativi di Casa Apple per la gestione dei dati personali (password, etc.). I risultati non sono certo esaltanti poiché gli autori dell’articolo, in 6 minuti, sono stati in grado di decifrare completamente il contenuto del KeyChain, da un gioiello di Casa Apple (iPhone 4 ed iPad), simulando le stesse condizioni al contorno di un furto (quindi dispositivo non Jailbreakato, cifrato con una password complessa, con la funzione di Data Protection attiva e con le attività di hack che sono state effettuate da un PC che non si era mai sincronizzato con il dispositivo).

L’amara considerazione è che quando un dispositivo iOS (la prova è stata effettuata con la versione 4.2.1) in cui è attiva la funzione di cifratura Hardware viene smarrito o rubato, l’utente è avvolto da una ingannevole sensazione di sicurezza. Sensazione familiare  di chi crede che non vi sia modo per il malintenzionato di accedere ai dati contenuti (perlomeno in presenza di una password complessa a protezione dei segreti). L’algoritmo AES256 che sottende al processo di cifratura sarebbe, in teoria, una solida garanzia. Peccato, purtroppo, che la chiave di cifratura del dispositivo non dipenda dalla complessità della password impostata dall’utente, ma è autoconsistente, ovvero tutte le informazioni per la sua creazione dipendono da porzioni di informazioni contenute all’interno del dispositivo e di conseguenza sono virtualmente in possesso di un eventuale malintenzionato che abbia illecitamente messo i propri artigli sull’apparato.

Questa caratteristica dei gioielli di Steve Jobs era già nota ed utilizzata, senza eccessivo sforzo, per decifrare porzioni del file system. La novità di questo 2011 consiste nel fatto che la stessa tecnica può essere utilizzata per ottenere le password contenute nel KeyChain. Nell’attuale versione dell’iOS Cuore di Mela (4.2.1), il keychain contiene, cifrate, informazioni quali: password utente di tutti i tipi e per tutti i gusti (email, groupware, VPN, WiFi, siti Web), ma anche password e certificati utilizzati in applicazioni di terze parti.

I passi effettuati per sbucciare la Mela sono tutto sommato relativamente semplici, a patto di conoscere il coltello lo script utilizzato per estrarre i dati che i ricercatori non hanno comunque rivelato, e si possono riassumere in:

  1. Ottenere l’accesso al file system;
  2. Copiare lo script di accesso al KeyChain nel file system;
  3. Eseguire lo script che rivela le account contenute e le relative password.

Banalmente il primo passo è necessario per accedere al keychain e può essere generalmente ottenuto jailbreakando il dispositivo ed installando un serverino SSH sullo stesso, facendo attenzione a non sovrascrivere i dati utente. Dopo il jailbreak una qualsiasi applicazione è in grado di accedere a tutti i file, incluso il keychain. Naturalmente il database delle credenziali è cifrato con la chiave del dispositivo, che non può essere estratta, ma che può essere utilizzata da altre applicazioni per rivelare i segreti contenuti sotto la buccia scocca del dispositivo.

Il passo successivo richiede l’iniezione di uno script di accesso al keychain mediante la connessione SSH appena stabilità. Lo script  non necessita di effettuare il reverse engineering del meccanismo di cifratura in quanto utilizza le funzioni di sistema per accedere alle informazioni del keychain.

Infine, la degna conclusione, nel terzo e ultimo passo viene eseguito lo script che stampa a video (ovvero esegue l’output su shell) le account.

Il tutto in soli 6 (sei) minuti, senza necessità di conoscere la password di decifratura del dispositivo. Un tempo che è comunque mediamente inferiore all’intervallo in cui l’utente medio realizza lo smarrimento o il furto del dispositivo, un tempo entro il quale l’utente malintenzionato potrebbe già essere entrato all’interno della posta elettronica della malcapitata vittima. E questo a prescindere dal fatto che l’utente possa o meno attuare la procedura di swipe remoto del dispositivo (un attaccante abile e soprattutto rivolto al risultato avrebbe già spento il dispositivo e cambiato la SIM).

Resta la (magra) consolazione che le password di alcuni servizi (ad esempio le password di siti Web) non vengono rivelate con questo tipo di attacco, pur venendo mostrate su schermo sono comunque marcate come protected e sono disponibili allo script solo dopo aver inserito la password di sblocco del dispositivo (quindi fuori scopo per lo scenario di attacco simulato). D’altro canto l’accesso alle credenziali del KeyChain è vittima conseguenza dell’usuale compromesso tra sicurezza e necessità di garantire una esperienza utente immediata: la password per i servizi di rete deve essere da subito disponibile senza necessità di intervento da parte per l’utente, per cui per avere accesso alla stessa è sufficiente avere accesso al file system.

Non c’è che dire… Un grattacapo in più per gli IT Manager che vedono ancora una volta funestate le proprie velleità professionali dall’accoppiata: smartphone/tablet->data leackage, grattacapo che getta nuova ombra sul fatto che questi gioielli siano effettivamente adatti per un uso di tipo enterprise. Lo scenario è ancora più complicato per i Tablet che in questo momento stanno trovando terreno fertile tra i livelli medio-alti che tipicamente sono meno sensibili ai problemi di sicurezza e soprattutto hanno una allergia cronica per l’inserimento di password.

A questo punto chi ha 6 minuti di tempo può scegliere di fare due cose: guardarsi il video sottostante che mostra la procedura (ma lo script di accesso non è stato rivelato), oppure correre al negozio sotto casa e comprarsi un Androide nuovo fiammante (ma non fatevi troppe illusioni perché gli autori dell’exploit sostengono che la diffusione verso altri terminali è solo questione di tempo).

 

Follow

Get every new post delivered to your Inbox.

Join 2,705 other followers