kitkat_sicurezza

Android 4.4: quanto è più sicuro?

Roberto Orgiu

Abbiamo parlato parecchio di Android 4.4 in questi ultimi giorni, ma non ci siamo ancora inoltrati troppo in quello che è il comparto sicurezza di questo nuovo aggiornamento.

Iniziamo con SELinux, il set di regole introdotto in permissive mode (ovvero non facendo altro che tenere traccia di cosa succedeva nel sistema) con Android 4.3: in questa nuova release del robottino verde, è stato invece fatto girare in enforcing mode; ma cosa significa? In parole povere, vuol dire che ora il sistema dovrebbe contrastare attivamente tutti i tentativi di privilege escalation, come, ad esempio, la richiesta dei permessi di root. Come abbiamo già visto, probabilmente Google ha lasciato qualche finestra aperta, visto che Chainfire ha già ottenuto i massimi permessi (almeno su Nexus 5) poche ore dopo il rilascio di KitKat.

Android 4.3 ha introdotto anche il Keystore, ma è in quest’ultima release che questa tecnologia guadagna un algoritmo di cifratura a chiave pubblica, valida alternativa al più noto algoritmo di cifratura asimmetrica RSA. Benché la crittografia a curva ellittica non possa competere con il progresso dei computer quantistici, è comunque un ottimo punto di partenza per la protezione delle password sui nostri terminali.

Le novità però non si fermano qui: Android sarà in grado di avvisarci se una certificate authority non esattamente pulita viene inserita nel nostro dispositivo: di norma; questi escamotage vengono utilizzati dalle aziende per effettuare attacchi simili al man in the middle per scopi di sicurezza o di monitoring. Certo, nulla di trascendentale, ma fa sempre piacere sapere se qualcuno cerca di ficcanasare nella nostra navigazione web.

Scendendo più a basso livello, chi ha programmato in C sa benissimo quanto poco basti per causare un buffer overflow: riempiendo oltre il limite massimo le strutture dati di un determinato software è infatti possibile far crashare il software stesso o far eseguire (con notevole perizia e conoscenza sia del software bersaglio sia del sistema operativo su cui gira) comandi malevoli volti alla compromissione di dati o dell’intero sistema. Google ha cercato di metterci una pezza compilando tutto il C di Android con il flag FORTIFY_SOURCE, un parametro di sicurezza del compilatore che permette di identificare alcuni possibili punti di accesso per il buffer overflow. Ovviamente non è una panacea e sta a chi scrive il codice validare i dati in ingesso, ma certamente è un punto a favore di Google e del suo robottino verde al gusto KitKat.

L’ultima funzionalità (non certo per importanza), accoppiata al dm-verify può dare un notevole giro di vite ai tentativi di modifica delle certificate authority di cui parlavamo poche righe sopra. Partiamo con ordine e cerchiamo di capire cosa sia dm-verify: questo sistema viene lanciato al boot e si occupa di controllare l’integrità dei file grazie ad un albero di hash SHA-256, associandoli ognuno ad un blocco di memoria di 4KB. Grazie a questo tipo di struttura, modificando un solo file, se ne cambierà l’hash e la radice dell’albero non verrà riconosciuta come valida. Per validare quindi la firma contenuta nella root di questo albero viene utilizzata una chiave pubblica contenuta nella partizione di boot. Come possiamo quindi immaginare, con un sistema di verifica del genere, il root di dispositivi con bootloader bloccato (che implementa la firma del kernel) potrebbe risultare più complesso ma, una volta cambiato il kernel (con uno che disabiliti dm-verify o che accetti le nostre modifiche), il processo dovrebbe risultare simile a quello che veniva utilizzato con gli altri dispositivi. Perché tutto excursus? Perché grazie al pinning dei certificati e a dm-verify, Google dovrebbe essere in grado di evitare che chiunque si possa sostituire a lei tramite dei certificati SSL validi ma non appartenenti a Mountain View. Grazie a quest’ultima modifica, solamente i certificati inseriti in una whitelist hardcoded possono essere accettati: combinando questa feature con il controllo degli hash dei blocchi di memoria, dovrebbe risultare particolarmente complesso sostituirsi a Google stessa, incrementando quindi la sicurezza del sistema e la privacy degli utenti (sempre basandosi sulla buona fede di chi riceve i nostri dati). In barba a Prism.

Purtroppo c’è anche una nota dolente: il Master Key attack. Come funziona questo attacco? A grandi linee, esso sfrutta una combinazione di peculiarità dello standard ZIP e del meccanismo di decompressione degli APK: innanzitutto aprendo come un normale archivio .zip l’app bersaglio è possibile inserire un file malevolo che abbia lo stesso nome di uno dei file contenuti nell’APK originale, che però non andrà a sovrascrivere quello già presente, ma conviveranno uno accanto all’altro. Quando l’applicazione verrà installata, la versione più vecchia del file (quindi quella che non è stata infettata) verrà utilizzata per il controllo del checksum, validando quindi il package, ma al momento dell’estrazione, la nuova release del file (quella infetta) andrà a sovrascrivere i file già presenti con quelli malevoli (vengono estratti dopo e il sistema va quindi a rimpiazzare le versioni sane con quelle appena estratte). Ovviamente, questo genere di attacco funziona con APK opportunamente modificati che difficilmente riuscirebbero ad eludere i controlli del Play Store di Google quindi, tenendoci lontani da mercati alternativi di dubbia fama, dovremmo essere abbastanza protetti. Almeno prendendo per vero quello che sostengono gli ingegneri di Mountain View.

Fonte: XDA-Developers