Android e la sicurezza di ssl durante l’installazione delle app

M0rF3uS

Voglio condividere con voi un post a dir poco stupendo letto su root lab rdist, questo post non solo spiega come funziona un meccanismo principale di android, ma mette un grosso punto interrogativo anche sulla sicurezza di tale meccanismo.

Il post parla di SSL ed appunto di Android, ma cosa ci ha a che fare il protocollo di criptazione più usato con Android, per la navigazione web? l’autenticazione ai servizi? no, niente di tutto questo.

Quasi ogni giorno noi possessori di un telefono android installiamo app dall’android market, ed è qui che entra in gioco l’ssl.

Al summercon Jon Oberheide ha presentato un talk sulla sicurezza di Android. Ha portato come esempio una applicazione di tipo trojan chiamata RootStrap che esegue del codice arbitrario all’interno di Android, cercando occasionalmente la disponibilità di aggiornamenti dello stesso codice arbitrario presso un server remoto. Tutto questo è possibile perchè su android non vi è alcuna restrizione sul codice scritto per creare le applicazioni e nessun controllo sui futuri aggiornamenti dello stesso scaricati dall’applicazione, quindi potenzialmente una app può fare tutto ciò che vogliamo noi. L’unica limitazione che il codice ha è che viene eseguito con un UID non privilegiato (anche questo sappiamo che non è esattamente vero, ma è un argomento a parte, perchè li c’è uno strato di controllo in più).

Delle slide linkate la parte più interessate è quella che da un occhiata sul processo tramite il quale le applicazioni vengono installate sul dispositivo. Questo meccanismo, contrariamente alle altre parti di Android non è open source e quindi bisogna disassemblare il DEX file per capire come funziona.

Il meccanismo è questo: noi lanciamo il market e cerchiamo l’app che ci interessa, dopodiche decidiamo di installarla e come sappiamo, parte il download e di seguito l’installazione. Ma non è il telefono ad iniziare il download, il telefono manda la richiesta al server Google, e successivamente il server manda un messaggio di tipo INSTALL_APP al servizio Gtalk di android – una specie di go/no-go da parte del server al dispositivo -, solo allora parte il download e quindi l’installazione (ed è per questo motivo, molto probabilmente, che a volte il telefono sta diversi minuti con la scritta “download in corso” senza scaricare un byte, semplicemente il messaggio di “go” arriva con un pò di ritardo).

Questo messaggio viene consegnato tramite SSL ed include un hash SHA-1 dell’apk dell’applicazione. Questo ovviamente “è meglio di niente” (non vi è alcune autenticazione infatti), ma ha dei punti deboli.

Il motivo è semplice, il protocollo SSL è buono per le transazioni, le autenticazioni, e le comunicazioni di basso livello in genere; infatti garantisce una buona copertura point-to-point, ma non vi è alcuna garanzia sugli strati superiori. Il servizio GTalk usa SSL solo per assicurare la connessione, autenticare il certificato del server, niente più…non ci assicura che il codice dell’applicazione non sia maligno, non garantisce quindi una copertura end-to-end.

Al giorno d’oggi, raramente la comunicazione remota tra due punti coinvolge solo quei due punti, ci sono un sacco di intermediari in mezzo; per esempio, sebbene l’applicazione sia presente fisicamente su un unico server Google, bisogna tenere in conto che questa è sempre scritta, compilata, e firmata da un altro sistema, il pc dello sviluppatore pippo che si trova chi_sa_dove. Ed una qualsiasi anomalia in questa catena non ci consente di poter certificare che l’applicazione non sia stata manomessa.

Con Android un minimo di sicurezza dovrebbe essere garantito dalla firma delle applicazioni. Queste infatti vengono firmate con una firma JAR propria dello sviluppatore stesso. L’hash dell’apk viene usato per determinare se una nuova applicazione può accedere agli stessi dati della precedente in quanto l’hash determina l’UID con il quale l’applicazione viene eseguita. Ma questo sistema ci garantisce immunità solo da applicazioni che tentano di accedere ai dati di altre applicazioni, e che sono formate con una chiave diversa. Nessuno ci assicura che il codice dell’applicazione non sia malevolo a monte, anche perchè è lo sviluppatore stesso che firma le sue applicazioni, spesso con un certificato di tipo self-signed.

Quindi, con questi presupposti, e presupposto che il messaggio di INSTALL_APP è protetto dal solo SSL e non contiene nessun sistema di firma al suo interno i dubbi sono legittimi.

Maggiori informazioni si avranno soltanto quando si riuscirà a scoprire qualcosa di più sul servizio GTalk. Il sistema di installazione dovrebbe proporre un sistema di richiesta/risposta onde evitare installazioni automatiche non desiderate, l’apk installato dovrebbe essere collegato alla richiesta del singolo dispositivo firmata con una chiave di Google. Ed infine Google dovrebbe limitare la lista delle CA riconosciute a solo alcune riconosciute ed appartenenti ai domini google.

Questo è un ottimo esempio per capire come l’ssl è ottimo per il basso livello, per assicurare le connessioni; per il livello applicazioni, che è più alto, bisogna introdurre nuovi sistemi di sicurezza.

[Via Il Portalinux]