Sicurezza del sistema operativo Android

L’architettura del sistema operativo Android, rappresentata in Figura 6^[1], ha caratteristiche uniche. Costruita con la filosofia di essere un ambiente completamente open, che ogni soggetto potesse modificare a suo piacimento, Android è formato da un insieme di componenti eterogenei, in buona parte “off-the-shelf” – ovvero liberamente disponibili sul mercato – e integrati.

Introdurremo brevemente le caratteristiche utili a capire il funzionamento di Android attraverso queste componenti, in modo da poter poi ragionare sulle principali problematiche di sicurezza.

Il kernel di Android (in rosso nell’immagine) è un kernel Linux generico, multi-utente, in uso su desktop e server. Una simile scelta permette ai produttori di comporre l’hardware dello smartphone che intendono commercializzare con molti gradi di libertà, in quanto è estremamente probabile che, per ogni componente hardware assemblato, sia disponibile il corrispondente driver Linux. La definizione di un kernel nuovo, ad hoc per Android, avrebbe magari potuto essere più performante, specie sui primi dispositivi con poca disponibilità hardware; tuttavia, avrebbe limitato le possibilità dei produttori di smartphone, che avrebbero dovuto attendere lo sviluppo del corrispondente driver per poter aggiungere uno specifico componente alla propria architettura, con il rischio di una riduzione della diffusione di Android.

L’Hardware Abstraction Layer (HAL – in azzurro) è un insieme di moduli di libreria, ognuno specifico per una componente hardware. Lo scopo di tutti gli HAL è semplificare la comunicazione tra i servizi dei livelli superiori del sistema operativo e l’hardware: ad esempio, questo permette ai livelli più alti del sistema operativo (in particolare al Java API Framework) di ignorare le specificità dei driver sottostanti per poter comunicare con i componenti hardware corrispondenti, nonché di utilizzare un set di istruzioni standard eseguite su astrazioni indipendenti dall’attuale componentistica dello smartphone. È compito poi delle funzioni di libreria dell’HAL tradurre i comandi nei corrispondenti sui driver specifici del kernel.

Android si basa su un insieme di librerie native (in viola), ovvero scritte in C/C++, che sono state inserite a supporto delle funzionalità, anche in questo caso, del Java API Framework e delle app. Tali librerie, ampiamente disponibili “off-the-shelf”, sono state inserite con la filosofia di riutilizzare quanto già disponibile, senza doverlo riscrivere. Rientrano in questo gruppo, tra le altre, le librerie per il rendering 2D e 3D (usate estensivamente dai videogiochi) e le librerie con i font e i codec audio/video supportati dallo smartphone.

L’Android Runtime (in giallo) è l’ambiente di esecuzione delle app. ART è una macchina virtuale in grado di eseguire il codice delle app, compilandolo nell’architettura nativa dello smartphone durante l’installazione. Per l’esecuzione, si basa su un insieme di librerie Java chiamate Core Libraries che corrispondono a un sottoinsieme dell’SDK di Java, più un insieme di classi specifiche di Android.

Il Java API Framework (in verde) implementa un insieme di servizi fondamentali che supportano l’esecuzione delle app, fornendo l’accesso ai servizi dei livelli sottostanti del sistema operativo, nonché la comunicazione tra app tramite uno specifico driver del kernel chiamato Binder. Ogni servizio è specifico per un certo tipo di attività: gestire l’installazione delle app, il loro ciclo di vita quando in esecuzione, la posizione, le telefonate e le notifiche, nonché il rendering delle schermate delle app. Questo componente del sistema operativo è stato completamente implementato da zero.

Infine, le app (in blu) occupano il livello gerarchico più alto e sfruttano tutti i servizi sottostanti per la loro esecuzione.

Aspetti e problemi di sicurezza di Android

Da un punto di vista della sicurezza, il sistema operativo ha una doppia valenza. Da una parte, come ogni pezzo di software, contiene delle vulnerabilità ed è soggetto al threat model del confused deputy che abbiamo presentato precedentemente. In questo caso, come per le app, l’attacco può provenire da app malevole installate dall’utente; tuttavia alcuni attacchi possono essere eseguiti anche dall’esterno tramite le connessioni di rete (Wi-Fi, 5G, Bluetooth, NPC), anche se in letteratura questi attacchi sono molto specifici, limitati e appartenenti soprattutto alle prime versioni del sistema operativo.

D’altra parte, Android è anche la componente che deve essere modificata in prima battuta per “hardenizzare” il canale di comunicazione tra app, per ridurre, come discusso, la probabilità che un malware installato possa attaccare con successo un’app vulnerabile o lo stesso sistema operativo. Come si può intuire la parte di hardening richiede, nel caso migliore, un’integrazione dei meccanismi di sicurezza esistenti oppure, nel caso peggiore, la loro parziale ridefinizione e riscrittura.

Sistemi di sicurezza in Android

L’eterogeneità architetturale di Android si manifesta anche nei corrispondenti sistemi di sicurezza, che prendono il nome di Android Security Framework (ASF) e sono principalmente distribuiti nel kernel e nel Java API Framework. Introdurremo di seguito i principali sistemi di sicurezza di Android senza pretese di completezza, riferendoci in particolare a quelli esistenti fin dalle prime versioni e che sono stati consolidati nel tempo, a riprova della loro affidabilità. Tuttavia, saranno sufficienti per ragionare sulle principali problematiche di sicurezza del sistema operativo.

Sistemi di sicurezza nel Kernel

In un kernel Linux generico il principale meccanismo di sicurezza è il DAC (Discretionary Access Control), applicato su ogni file del sistema, dove i permessi sono espressi in termini di diritti di lettura, scrittura ed esecuzione per il proprietario del file, per gli utenti che appartengono allo stesso gruppo del proprietario e, infine, per tutti gli altri. I permessi su ogni file sono assegnati dal proprietario in maniera insindacabile. Quest’ultimo punto è una debolezza di Android, perché permetterebbe a uno sviluppatore di avere troppo impatto sulla sicurezza del sistema.

A titolo di esempio, si supponga che uno sviluppatore dia troppi permessi ai file della propria app, fornendo accesso completo al gruppo “altri”. In questo caso, un malware installato riconoscerebbe immediatamente questa situazione e otterrebbe l’accesso a tutti i dati dell’app. Inoltre, il DAC non permette comunque di definire politiche di sicurezza che valgano per tutto il sistema e tutte le app installate.

Per superare questa limitazione, a partire da Android 4.2, il DAC è stato integrato con un modello MAC (Mandatory Access Control) tramite una componente chiamata SEAndroid (Security Enhanced Android)^[2], un’estensione di SELinux^[3] che permette di definire regole che valgono su tutto il sistema, di fatto limitando il problema precedente e permettendo ai produttori di scrivere le proprie politiche di sicurezza per il singolo smartphone. Samsung Knox^[4] è l’implementazione di Samsung di SEAndroid sui propri dispositivi.

Infine, un sistema di sicurezza definito da Android a livello Kernel, è la Sandbox^[5], che installa ogni app in un utente differente a livello Kernel, nell’ottica di aumentare la separazione tra app e diminuendo la probabilità di interazione tra malware e app.

Sistemi di sicurezza nel Java API Framework

Il Java API Framework implementa soluzioni di sicurezza native (ovvero sviluppate ad hoc per Android) per la protezione delle app e dell’utente. Uno di questi sistemi è ben noto allo stesso utente, ovvero il sistema dei permessi. Ogni app deve disporre di specifici permessi per accedere ai servizi del sistema operativo o di altre app. Alcuni permessi vengono dati di default (come, ad esempio, il permesso per accedere a Internet), mentre altri richiedono l’intervento dell’utente: a questa categoria fanno riferimento tutti i permessi che possono ledere la privacy dell’utente (ad esempio accedere alle foto o alla posizione dello smartphone), per i quali è ragionevole permettere la scelta all’utente stesso. Il mapping tra le app e i loro permessi viene gestito da un componente del Java API Framework chiamato package manager, che si occupa della quasi totalità degli aspetti di sicurezza a questo livello. È quindi il package manager che decide se una app abbia o meno i permessi richiesti per una certa operazione. Lo stesso è responsabile dell’installazione e della disinstallazione delle app.

Queste operazioni coinvolgono controlli di sicurezza importanti. In primo luogo l’app, che viene distribuita come un archivio compresso chiamato APK (Android PacKage) viene accettata solo se firmata dallo sviluppatore con la propria chiave privata. Pertanto il package manager verifica innanzitutto la firma e l’integrità di ogni file presente nell’app, installandola solo in caso di controllo con esito positivo.

Tuttavia questo controllo non identifica lo sviluppatore, che per poter firmare e distribuire le app non deve avere un certificato rilasciato da un’autorità riconosciuta: è sufficiente abbia una coppia di chiavi, pubblica e privata, che può autogenerarsi con tool ampiamente disponibili.

Pertanto, Android non ha l’obiettivo di identificare gli sviluppatori; questa è una scelta di business. Imporre l’identificazione dello sviluppatore potrebbe avere conseguenze sul numero di app sviluppate e distribuite, in quanto un certo numero di sviluppatori potrebbe non voler essere riconosciuto o avere più identità fittizie (ognuna con una coppia di chiavi diversa).

Durante l’installazione, il package manager provvede a interagire con il kernel per creare un nuovo utente a livello kernel per l’app (Sandbox) e generare in modo random il percorso dove installarla. Lo scopo di questa randomizzazione, utilizzata nelle più recenti versioni di Android, è nascondere ai malware la localizzazione delle app bersaglio, per ridurre la probabilità che queste siano individuate e attaccate.

Problemi di sicurezza in Android

Lo scopo dei meccanismi di protezione è fornire ad un sistema un insieme di garanzie di sicurezza. Ricapitolando, i sistemi di protezione dell’ASF precedentemente introdotti garantiscono:

1. la verifica dell’integrità dell’app in fase di installazione;
2. l’isolamento tra le app, grazie all’installazione su utenti diversi a livello kernel (Sandbox) e percorsi delle home randomici;
3. l’autorizzazione ad accedere alle risorse del sistema e di altre app tramite i permessi;
4. la possibilità di definire politiche di sicurezza da parte del produttore del dispositivo.

A fronte di tali garanzie, il lettore converrà che i meccanismi di protezione risultino convincenti e di fatto siano effettivamente focalizzati a ridurre la probabilità che un malware raggiunga un’app vulnerabile.

Qualora le garanzie promesse da questi – e da tutti gli altri meccanismi dell’ASF – fossero mantenute, probabilmente avremmo un sistema operativo da sempre sicuro. La storia di Android, come di qualunque altro sistema operativo, è però ricca di vulnerabilità e attacchi.

Cercheremo di capire perché, premettendo come la frase che più si addice a chi cerchi problemi di sicurezza in software complessi sia “il diavolo sta nei dettagli”.

Interazione e integrazione

Interazione. Come abbiamo visto, l’eterogeneità architetturale di Android si riscontra anche nei meccanismi dell’ASF. A livello kernel le regole di sicurezza sono espresse in termini di DAC/MAC su file e processi. A livello applicativo, le regole sono indicate in termini di permessi (“autorizzi l’app ad accedere alle tue foto?”). Appare evidente che diversi livelli dello stack Android parlino lingue diverse. In questo caso, i problemi di sicurezza si possono nascondere nell’interazione tra gli stessi: come si traduce il permesso “accesso alle foto” in un insieme di regole DAC a livello del sistema operativo che rispetti anche le regole MAC imposte dal produttore? Questa interazione avviene in modo corretto e completo? Ci possono essere conflitti o mancanze?

Non esiste documentazione ufficiale a riguardo e, qualora il lettore volesse capire come avviene ad esempio il processo di richiesta di posizione GPS da parte di un’app fino all’interrogazione del driver del GPS del dispositivo, dovrebbe analizzare il codice open-source di Android. Ma questo, ovviamente, lo può fare anche un attaccante.

Il problema dell’interazione tra meccanismi diversi è stata risolta, nel tempo, attraverso le diverse versioni di Android, seppur ogni modifica ai meccanismi di sicurezza di Android richieda comunque una verifica della correttezza di queste comunicazioni.

Integrazione. Oltre a un problema di diversità del linguaggio, l’eterogeneità architetturale di Android ha ripercussioni anche sull’integrazione tra i meccanismi di sicurezza e può snaturare algoritmi e protocolli delle singole componenti architetturali per realizzare uno specifico meccanismo.

A titolo di esempio, si consideri l’isolamento tra le app tramite la sandbox, che porta ogni app ad essere installata in un utente diverso a livello kernel. Seppur i vantaggi di questa separazione siano palesi in termini di hardening, per ottenere questo risultato alcune funzionalità native del kernel sono state modificate.

In Linux, ogni nuovo processo (figlio) viene generato a partire da un processo già esistente (padre) tramite una system call, ovvero una chiamata di funzione al kernel, detta fork^[6], che dapprima crea una copia esatta del processo-padre e poi sostituisce il codice del padre nella copia con quello del processo-figlio prima di eseguirlo. Si noti che con la fork entrambi i processi appartengono al medesimo utente.

La scelta della sandbox ha portato a un utilizzo non canonico della fork. Si pensi alla seguente ipotesi: quando un utente riceve su WhatsApp un allegato che vuole aprire con un’altra app, come fa l’app di WA, che appartiene a un utente, a creare e lanciare in un nuovo processo (di un altro utente) la seconda app a livello kernel? Certamente non con l’uso standard della fork, che non prevede questa possibilità.

Android risolve il problema tramite un processo ad hoc chiamato Zygote, dove la creazione di nuovi processi avviene tramite l’uso di una fork eseguita come root (quindi con massimi privilegi) che crea il nuovo processo, inserisce il codice dell’app da eseguire e cambia la proprietà del processo da root a quello dell’utente corrispondente.

Pertanto, la scelta necessaria è stata trasformare una system call con pochi privilegi e sicura in una con massimi privilegi e ad alto rischio. La conseguenza diretta sulla sicurezza di Android è stata una serie di vulnerabilità legate a questo processo, che ha permesso a diversi attaccanti di abusarne con conseguenze significative ^{[7], [8], [9]}.

Vulnerabilità dei meccanismi di sicurezza

Oltre agli esaminati problemi di integrazione e di utilizzi non standard, va notato che i meccanismi di protezione sono anch’essi pezzi di software e, come tali, possono contenere vulnerabilità sfruttabili per bypassarli.

A titolo di esempio, dalla prima versione di Android fino alla 4.2, il già discusso controllo dell’integrità dell’APK svolto dal package manager era eseguito in maniera non corretta. Per una scelta implementativa, si usavano due librerie diverse per verificare l’integrità di ogni file nell’APK e per installare i file verificati^[10]. L’utilizzo di queste due librerie conteneva una vulnerabilità, chiamata Master Key Vulnerability, tale per cui se nell’APK vi fossero stati due file con lo stesso nome, la verifica dell’integrità sarebbe stata eseguita sul primo, mentre il secondo, tramite la seconda libreria, sarebbe stato installato senza essere verificato. Di conseguenza, un attaccante avrebbe potuto prendere una app legale, inserirvi tramite app repackaging (cfr. Sezione 4.3.2) un file malizioso con lo stesso nome di un altro file presente e ridistribuirla. In questo modo, qualora l’app fosse stata installata, anche il file malizioso sarebbe stato installato automaticamente dal package manager nel dispositivo, senza alcun controllo di integrità su di esso.

Questo tipo di vulnerabilità viene cercato costantemente dal gruppo di sicurezza di Google, chiamato Android Security Teams, oltre che da una comunità di ethical hacker spinti alla ricerca di nuove vulnerabilità da motivi economici: dal 2014 Google ha attivato un Bounty Program, oggi chiamato Google and Alphabet Vulnerability Reward Program^[11], che remunera parti terze che rilevano e segnalano vulnerabilità nel sistema operativo.

Il risultato di questo processo è stata la scoperta e la risoluzione di un grande numero di vulnerabilità nelle diverse versioni di Android; e a “stretto giro”, ovvero entro poco tempo dall’uscita di ogni update del sistema operativo. La maggior parte degli aggiornamenti minori (ovvero non legati al rilascio e all’aggiornamento del sistema operativo a una nuova versione) sono in buona parte risoluzioni delle vulnerabilità scoperte.

A questo processo, negli anni e attraverso le diverse versioni del sistema operativo, si è affiancata un’attività di hardening sempre maggiore, spinta soprattutto da un crescente numero di malware per Android; questo ha portato Google ad applicare politiche sempre più restrittive per ridurre, da un lato, la probabilità di interazione tra malware e app vulnerabili e, dall’altro, per ridurre indirettamente il numero di vulnerabilità nelle app.

Ad esempio, in Android 9 è stato introdotto il divieto di utilizzare http nelle app, forzando l’uso di https: in questo modo si riduce la superficie di attacco dell’app forzando lo sviluppatore ad usare solo connessioni cifrate.

Per capire le ragioni di questa crescente fase di hardening da parte di Google, occorre fare una riflessione: l’ASF, così come ogni altro sistema di protezione, non è mai completo. Ovvero, non protegge tutto il sistema ma solo la maggior parte dei canali di comunicazione tra app e sistema operativo. Questo non è dovuto a pigrizia o impreparazione, ma è una “ragionevole scelta di compromesso”. I meccanismi di protezione hanno infatti un “costo” sul sistema operativo, sulle risorse del sistema e, non ultimo, sulla libertà dell’utente. Estremizzare i meccanismi di protezione può rendere il sistema molto più sicuro ma poco usabile, con la conseguenza di demotivare all’utilizzo di Android sia utenti che sviluppatori. A valle di questa riflessione, è chiaro come il processo di hardening costante svolto dalle prime all’ultima versione di Android abbia avuto come obiettivo quello di aumentare la superficie di sistema protetta dall’ASF, pur mantenendo un alto grado di usabilità.

Inoltre, l’evoluzione hardware degli smartphone ha certamente favorito lo sviluppo di nuovi meccanismi di sicurezza nelle ultime versioni di Android, che, qualora implementate su vecchi dispositivi con hardware limitato, avrebbero impattato molto più negativamente sulla “user experience”.

Side Channels

Alla fine, possiamo concludere che le ultime versioni dell’ASF forniscono una protezione più completa delle diverse componenti del sistema. Tuttavia, rimangono componenti che non sono protette o perché ritenute poco rischiose dal punto di vista della sicurezza, o perché esiste la necessità che siano condivise tra tutte le app in maniera libera. Si pensi, in questo secondo caso, alle impostazioni di sistema o alla scheda SD, entrambe per definizione accessibili da tutte le app. In particolare, la scomparsa delle schede SD dai recenti smartphone è proprio per la scelta delle app di non utilizzarle, trattandosi di una memoria condivisa e visibile a tutti.

Tuttavia queste componenti non protette possono diventare, se utilizzate opportunamente, dei canali di comunicazione non standard, detti side channels.

La storia della mobile security è ricca di esempi dove l’abuso dei side channels ha portato ad attacchi (detti side channel attacks) che hanno eluso l’ASF.

Per chiarire, nel grande numero di malware più o meno complessi che sfruttano side channel, usiamo un esempio semplice: quello del primo malware che ha dimostrato la sfruttabilità dei side channel in Android, che prende il nome di SoundComber.

SoundComber^[12] è uno dei primi malware basati sul threat model delle colluded app che abbiamo presentato in Figura 2 e formato da due app all’apparenza innocue, ovvero un registratore di note vocali (con il permesso di registrare l’audio) e un calendario (con il permesso di connettersi a Internet per sincronizzare gli appuntamenti). I due malware collaborano per rubare numeri di carte di credito digitati tramite la tastiera dello smartphone usando il “volume” come side channel.

Il principio è semplice: durante una telefonata dove l’utente invia il numero della sua carta di credito via telefono, digitando sulla tastiera virtuale, il primo malware registra il tasto digitato, riconosce il numero e cambia il livello del volume audio a una intensità pari al numero digitato. Il secondo malware legge il valore guardando il livello del volume e, per ogni cifra digitata dall’utente, invia a un server esterno il valore corrispondente.

Da quando SoundComber ha dimostrato la fattibilità di questi attacchi, molti attaccanti hanno cercato potenziali side channel e sviluppato malware che li sfruttassero. D’altro canto, ogni volta che un nuovo side channel veniva scoperto e sfruttato l’ASF è evoluto di conseguenza per proteggerli, pur mantenendo, ove possibile, l’utilizzo atteso.

Tuttavia, alcune protezioni possono essere “vulnerabili” a loro volta. Le componenti “off-the-shelf” di Android possono avere potenziali side channel nativi. In questi casi, Android li limita e protegge tramite opportuni meccanismi nell’ASF. Tali protezioni possono però risultare incomplete o, appunto, vulnerabili.

È il caso del servizio inotify^[13] di Linux che permette ai processi di venire notificati in caso di cambio di stato di un processo target (ad esempio quando il processo si avvia, è in esecuzione, viene bloccato…), secondo un modello publish-subscribe. Un simile servizio permetterebbe a un malware di essere notificato quando un’app bersaglio si esegue. Recentemente è stato dimostrato che la protezione dell’ASF è insufficiente e che un malware può sfruttare facilmente inotify per essere notificato circa l’avvio di un’app^[14].

Ma qual è l’impatto e come si sfrutta una simile vulnerabilità? Si supponga che l’app richieda, come quasi ogni app, l’inserimento di credenziali utente. Se il malware avesse la stessa identica interfaccia grafica dell’app bersaglio e venisse notificato da inotify quando questa si esegue, esso potrebbe eseguirsi immediatamente dopo ed essere mostrato all’utente al posto di quella originale, che verrebbe lanciata e subito messa in background. In questo modo, l’utente fornirebbe le sue credenziali al malware anziché all’app legale. Si noti che questa vulnerabilità colpisce tutte le versioni di Android fino a quella attuale (13) e che, al tempo della scrittura di questo testo, non è ancora stata risolta da Google.

Discussione

La fase di hardening degli ultimi 15 anni ha reso Android particolarmente sicuro. La ricerca di vulnerabilità presenti nelle prime versioni, come quelle correlate allo Zygote o all’utilizzo di side channel semplici (come le impostazioni), sarebbe in massima parte infruttuosa. La ricerca di side channel è invece ancora promettente – come dimostrato dall’esempio di inotify – ma, rispetto ai primi side channel, aumenta la difficoltà nel poterli sfruttare una volta individuati.

Va però sottolineato che ogni nuova versione di Android contiene nuove funzionalità a supporto degli sviluppatori di app. Queste funzionalità possono nascondere nuove vulnerabilità, non presenti nelle precedenti versioni di Android.

Note

^[1] Figura presa da https://developer.android.com/guide/platform

^[2] Security-Enhanced Android. https://source.android.com/docs/security/features/selinux?hl=it

^[3] https://www.redhat.com/en/topics/linux/what-is-selinux

^[4] https://www.samsungknox.com/it

^[5] Android Sandbox. https://source.android.com/docs/security/app-sandbox?hl=it

^[6] https://man7.org/linux/man-pages/man2/fork.2.html

^[7] https://securelist.com/attack-on-zygote-a-new-twist-in-the-evolution-of-mobile-threats/74032/

^[8] Armando, A., Merlo, A., Migliardi, M., & Verderame, L. (2012). Would You Mind Forking This Process? A Denial of Service Attack on Android (and Some Countermeasures). Proc. of IFIP-Sec 2012 (p. 13-24). Heraklion, Crete: Springer.

^[9] Lee, B., Lu, L., Wang, T., Kim, T., & Lee, W. (2014). From Zygote to Morula: Fortifying Weakened ASLR on Android. Proc. of 2014 IEEE Symposium on Security and Privacy. San Jose, California, USA: IEEE.

^[10] J. Forristal – BlueBox (2013). Master Key Vulnerability. https://nvd.nist.gov/vuln/detail/CVE-2013-4787

^[11] Google and Alphabet Vulnerability Reward Program. https://bughunters.google.com/

^[12] Schlegel, R., Zhang, K., Zhou, X., Intwala, M., Kapadia, A., & Wang, a. X. (2011). SoundComber: A stealthy and context-aware sound trojan for smartphones. Proc. 18th Annual Network and Distributed System Security Symposium (NDSS ’11). San Diego, California: The Internet Society.

^[13] https://man7.org/linux/man-pages/man7/inotify.7.html

^[14] Ruggia, A., Possemato, A., Merlo, A., Nisi, D., & Aonzo, S. (2023). Android, Notify Me When It Is Time To Go Phishing. Proc. of the 8th IEEE European Symposium on Security & Privacy (EuroS&P 2023). Delft, The Netherlands: IEEE.

 

Questo articolo è stato estratto dal white paper “Mobile Security – Nozioni e Riflessioni” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/mobile-security-nozioni-e-riflessioni/

 

Articolo a cura di Alessio Merlo