Dopo aver visto come viene eseguito il boot sui dispositivi con iOS, passiamo ad un altro argomento: come funziona la sicurezza di iOS? Come infrangerla?
Introduzione
Per comprendere pienamente le decisioni prese da Apple nel tentativo di proteggere i propri dispositivi è necessario riflettere un momento sui diversi tipi di minacce rivolte verso un dispositivo così tanto utilizzato nel mondo.
Se pensiamo ad “alto livello” i dispositivi iOS affrontano circa gli stessi tipi di attacchi che un comune computer desktop potrebbe fronteggiare.
Possiamo suddividere tali attacchi in due grandi categorie: malware e exploit. I malware esistono da decenni nei personal computer e sono a diventati una minaccia anche sui dispositivi mobili; in maniera semplicistica, definiamo malware un qualsiasi software che compie azioni “dannose” quando viene eseguito su un dispositivo.
D’altra parte, gli exploit sfruttano alcuni difetti di base del software sul dispositivo per eseguire del codice arbitrario. Attacchi di questo tipo sono a volte chiamati drive-by-download perché, a differenza del caso di un malware, l’utente è per lo più vittima innocente e non sta tentando di installare nulla! Sfruttare gli exploit richiede due ingredienti di base: il primo è l’exploit stesso, difetto o una vulnerabilità sono dei sinonimi. Il secondo ingrediente è cercare un modo per sfruttare questa vulnerabilità, per eseguire il codice arbitrario.
La superficie di attacco
E’ evidente che limitare una superficie d’attacco, riduce di molto il rischio di infiltrazioni di qualche tipo nel sistema. La superficie di attacco è quella parte in iOS (ma anche in altri OS) che è esposta e che utenti non autorizzati possono vedere e/o modificare.
Apple ha ridotto di molto la superficie di attacco in iOS ,rispetto a macOS. Sarà un caso che ad esempio, ne Java ne Flash non sono disponibili su iOS?
Sia Java che Flash, hanno tutta una serie di vulnerabilità di sicurezza tali che non includendole in iOS, un utente malintenzionato deve impegnarsi molto per trovare un exploit da sfruttare. Allo stesso modo, iOS non elaborerà mai alcuni tipi di file, a differenza ad esempio di macOS. Ad esempio, i file .psd vengono tranquillamente gestiti in Safari su macOS, ma non in MobileSafari su iOS. Ancora, anche se iOS esegue il rendering nativo di file .pdf, questi file utilizzano solo alcune funzionalità caratteristiche di questo formato file: una volta, Charlie Miller, usando Preview (il visualizzatore nativo di pdf in macOS) ha riscontrato oltre 100 crash provando ad operare su una serie di file. Quando ha provato ad eseguire circa le stesse operazioni su iOS, solo il 7% di quei file ha causato un problema. Ciò significa che, riducendo le funzionalità PDF gestite da iOS, si riducono il numero di potenziali vulnerabilità di oltre il 90%. Meno superficie di attacco disponibile significa meno opportunità di sfruttare exploit.
Ridurre iOS al minimo indispensabile
Oltre a ridurre la superficie di attacco disponibile, Apple ha anche ridotto il numero di applicazioni utili che un utente malintenzionato potrebbe voler utilizzare per sfruttare gli exploit. L’esempio lampante è che non esiste una shell (/bin/sh) su un dispositivo iOS. Negli exploit di macOS invece, l’obiettivo principale è proprio provare ad eseguire una shell in “shellcode“! Poiché non è presente alcuna shell in iOS, è necessario sviluppare un altro obiettivo finale per gli exploit iOS. Anche se fosse disponibile una shell in iOS, non sarebbe utile perché un utente malintenzionato non sarebbe in grado di eseguire le classiche utility come rm, ls, ps e così via. Per questo motivo, gli aggressori cercano di eseguire le loro azioni o all’interno di un processo oppure caricano tutti gli strumenti necessari manualmente.
Separazione dei privilegi
iOS separa i processi utilizzando utenti, gruppi e altri meccanismi di autorizzazione abbastanza tradizionali nel mondo Unix. Ad esempio, molte delle applicazioni a cui l’utente ha accesso diretto, come Safari, Mail o app di terze parti, vengono eseguite in usermode, cioè nella modalità senza troppi privilegi. I processi di sistema più importanti invece vengono eseguiti come root, utente privilegiato amministratore del sistema. Utilizzando questo modello, un utente malintenzionato che ottiene il controllo completo di un processo come ad esempio quello di Safari, sarà limitato dal fatto che il codice che sta eseguendo sarà eseguito in usermode. Questo perchè non c’è bisogno che il processo che gestisce Safari sia eseguito come root!
Ci sono dei limiti a ciò che un simile exploit può fare: ad esempio non sarà in grado di apportare modifiche a livello di sistema. Allo stesso modo, le app dall’App Store sono limitate in ciò che possono fare perché verranno eseguite anch’esse in usermode.
Anche per questo articolo è tutto. Continueremo l’argomento nel successivo articolo, illustrando altre tecniche di sicurezza. Per eventuali domande, curiosità o feedback potete lasciare un commento qui in basso, a presto!