Quali sono le possibili minacce di sicurezza in iOS? - iPhone Italia

Quali sono le possibili minacce di sicurezza in iOS?

19 febbraio 2018 di Matteo D'Alessio

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!

Per restare sempre aggiornato sul tema di questo articolo, puoi seguirci su Twitter, aggiungerci su Facebook o Google+ e leggere i nostri articoli via RSS. Iscriviti al nostro canale YouTube per non perderti i nostri video!

REGOLAMENTO Commentando dichiari di aver letto e di accettare tutte le regole guida sulla discussione all'interno dei nostri blog.
  • Ricordo a tutti che utilizzando questo link:

    https://docs.google.com/spreadsheets/d/1lmudaUZHJ3u60tVGuA7xTui1pUFyeEt3RmDhfGP0_y4/edit#gid=0

    Potete accedere alla lista completa di tutti gli articoli.

  • Federico Anzalone

    Complimenti per l’ottimo articolo, sapete spiegare in modo semplice argomenti che normalmente non sono alla portata di tutti. Con gli ultimi sviluppi del mondo mobile/desktop essere informati su cosa lavorano hacker e malintenzionati è sempre più importante.

    Continuate il vostro ottimo lavoro! 👍🏻

  • Grazie Federico.

  • Poly17

    questo articolo è stato veramente interessante!!

  • the gix

    Articolo molto interessante!

  • Leandro Rocchi

    Ottimo articolo, solo alcune precisazioni. Java, di per se, non ha più vulnerabilità di qualsiasi altro linguaggio o framework di sviluppo (anche Swift ne ha ad esempio) che possono essere usate per accedere a parti di SO interdette. Il problema della “sicurezza” di Java è data più sulla Virtual Machine messa a disposizione per interpretare il codice Java. Per arginare il problema della relativa pericolosità di Java basterebbe fornire delle VM opportunamente sviluppate.

  • Credevo fosse sottointeso che gli applicativi in Java possano girare *se* c’è dietro l’appoggio della VM che ovviamente non è supportata da iOS per i motivi descritti, grazie!

  • Leandro Rocchi

    E’ sottinteso per gli addetti ai lavori ma per chi non è uno sviluppatore o non si intende di informatica, non è una cosa così scontata 😀

    Detto questo, Apple potrebbe anche, in teoria, sviluppare una virtual machine Java creata appositamente per l’ecosistema di iOS impendendo l’accesso a quelle aree che devono rimanere interdette (come ad esempio ha fatto Google con la Dalvik e la ARC, due JVM sviluppate appositamente per i dispositivi Android)

  • Si, teoricamente si potrebbe ma praticamente sarebbe un potenziale vettore d’attacco: basta pensare ad un cve nel quale in runtime la Dalvik caricava dei dex con codice arbitrario in un apk senza eseguire controlli sulla firma.

    Però non sarebbe una brutta idea, anche se credo non lo faranno mai

  • Leandro Rocchi

    Ma il problema della Dalvik (e anche se in minor parte anche di ARC) è proprio il fatto che la JVM dava accesso a quasi tutto il sistema, soprattutto su dispositivi con root abilitato. Quello che dico io è creare una JVM che segua le linee guida di Apple e che quindi sia “chiusa” sufficientemente; limitando quindi lo sviluppo di applicazioni java ma rimanendo coerenti con la filosofia iOS. Sono d’accordo con te che Apple non lo farà mai, vuole spingere Swift e fa anche bene.

  • Ho capito, intendi una specie di ambiente sandboxato dove ogni app gira praticamente in chroot(2) e l’idea non sarebbe affatto male! Bisognerebbe solo valutarne le prestazioni.

  • Leandro Rocchi

    si esattamente. Fermo restando che se fai il jailbreak poi rischi di poter apportare modifiche e quindi mandi tutto in malora (ma questo può avvenire già ora con il jailbreak)