La mobile security è una branca della cybersecurity che si occupa specificamente degli aspetti di sicurezza legata ai dispositivi mobili (smartphone, tablet, watch, smart tv…), alla loro interazione con i servizi esterni e alla protezione dell’utente e dei suoi dati personali.

Nozioni preliminari

Per capire gli obiettivi della mobile security occorre introdurre il concetto di threat model, legato ai dispositivi mobili. Un threat model serve a fare assunzioni sulle capacità di un attaccante in un dato ecosistema, ed è il primo passo per capire e studiare problemi di cybersecurity in ogni sua declinazione.

Ricordiamo che nello scenario descritto nella Figura 1 gli utenti cercano e installano app per aumentare le funzionalità del proprio dispositivo. Dal punto di vista della sicurezza, le app possono essere o vulnerabili o malware. Nella prima categoria rientrano app benevole ma che, fisiologicamente, presentano dei problemi di sicurezza, definite vulnerabilità. In dettaglio, una vulnerabilità è un bug dell’app che ha un impatto sulla sicurezza del sistema o dell’utente. In un’assunzione realistica ogni app, come ogni software, presenta necessariamente qualche vulnerabilità. L’insieme di vulnerabilità di un software prende il nome di superficie di attacco.

I malware sono invece app malevole sviluppate dall’attaccante al fine di sfruttare vulnerabilità; il primo obiettivo è spingere l’utente ad installarle e/o eseguirle sul proprio dispositivo. Per questo motivo, i malware tendono a camuffarsi da app innocue, o si nascondono dentro app già esistenti tramite un processo, tipico del solo mondo mobile, che si chiama repackaging (cfr. Sezione 4.3.2).

In questo scenario, il threat model di riferimento è rappresentato in Figura 2, dove si assume che l’attaccante sia in grado di trovare vulnerabilità esistenti in una qualsiasi app o versione del sistema operativo Android. Inoltre, l’attaccante può produrre un malware e distribuirlo sugli app store ufficiali e non, nonché tramite canali terzi (e.g., caricandolo su un sito o inviandolo via e-mail), per sfruttare le vulnerabilità scoperte. Infine, si assume che il malware riesca a eseguirsi sullo smartphone, tramite interazione con l’utente o sfruttando le caratteristiche di Android. Una volta eseguito, lo stesso cerca di attaccare l’app vulnerabile o Android, sfruttando i canali di comunicazione messi a disposizione del sistema operativo. Infine, si assume che ogni app benevola non sia a conoscenza di alcuna propria vulnerabilità.

Tale threat model prende il nome di confused deputy, nome che sottolinea l’impossibilità dell’app di distinguere se le sue interazioni avvengano con un’altra app lecita o con un malware che sfrutti qualche sua vulnerabilità.

Una variante del confused deputy è quella delle colluded apps dove il malware, per ridurre le probabilità di essere identificato, divide il codice malevolo su più app maliziose ma all’apparenza innocue. Tuttavia, l’interazione tra queste app permette di perpetrare l’attacco.

Valutare il peso di una vulnerabilità: il concetto di rischio

La valutazione della pericolosità di una vulnerabilità si esprime in termini di rischio. Il rischio associato ad una vulnerabilità è il prodotto tra due metriche, ovvero la probabilità e l’impatto (Rischio = Probabilità x Impatto). La probabilità indica la facilità con cui un attaccante potrebbe sfruttare con successo la vulnerabilità. Facendo un paragone con il mondo reale, la probabilità indica quanto sia facile per un ladro violare la serratura di una casa ed entrarvi.

L’impatto si riferisce alle conseguenze di un attacco riuscito che sfrutta la vulnerabilità. Ad esempio, se l’attaccante, sfruttando la vulnerabilità, riesce ad impossessarsi di numeri di carte di credito, l’impatto sarà alto. Secondo il paragone precedente, l’impatto valuta quanto il ladro riesce a rubare una volta penetrato in casa.

A titolo di esempio, la Figura 3 indica il valore di rischio di una vera vulnerabilità^[1] su una scala da 1 a 10. L’alto valore di rischio (7.8) è dovuto ad un buon valore di impatto (6.9) e all’estrema facilità, per un malware, di sfruttarla (10).

Specializzazioni della Mobile Security

La mobile security si articola in specializzazioni (o branche) principali, rappresentate in Figura 4:

1. Vulnerability Assessment & Penetration Testing (VA/PT): persegue la definizione di metodologie di analisi dei sistemi operativi mobili e delle app al fine di riconoscere potenziali vulnerabilità (VA) e verificarne la sfruttabilità da parte di un attaccante (PT); l’obiettivo finale è scoprire e risolvere vulnerabilità in modo da diminuire la superficie di attacco delle app e del sistema operativo da parte dei malware.
2. Hardening: studia e crea tecniche atte ad incrementare la protezione dei sistemi operativi e delle app, spesso sotto forma di estensione e miglioramento dei sistemi di protezione esistenti. Lo scopo dell’hardening è ridurre la probabilità che un malware riesca a raggiungere e sfruttare una vulnerabilità, pur garantendo le interazioni legali tra app e sistema operativo tramite i canali di comunicazione previsti.
3. Malware Analysis: si occupa di cercare, analizzare e isolare nuovi pattern malevoli e malware che compaiono sugli app store, a prescindere dalle vulnerabilità che questi intendano sfruttare.

Sicurezza e Privacy sono due concetti che spesso possono confondere. Alcuni possono tendere a pensare che essi siano in qualche modo interconnessi, o che la privacy sia un sotto-caso particolare della security. I concetti sono, in realtà, ortogonali, avendo threat model diversi e molto ben distinti.

Nel mondo mobile, il threat model classico della security è il già discusso confused deputy, mostrato in Figura 5a. In questo caso, un’app vulnerabile che contiene dati di uno o più utenti viene attaccata con successo da un malware, portando ad un conseguente furto di dati personali dell’utente conservati nel database dell’app vulnerabile. Si noti che, sebbene questo attacco coinvolga il furto di dati personali, questo è a tutti gli effetti un problema di sicurezza.

Il threat model per la privacy nell’ecosistema mobile è invece mostrato in Figura 5b. Gli sviluppatori delle app utilizzano delle librerie, chiamate librerie di analytics^[2], offerte da grossi player dell’ICT come Meta (Facebook, Instagram, WhatsApp) e Google stesso. Tali librerie consentono agli sviluppatori di un’app di catturare eventi generati dagli utenti che hanno installato e usano l’app nel mondo, per fini di monitoraggio le cui motivazioni possono essere molteplici (miglioramento dell’app, aggiunta di funzionalità, analisi dei tempi medi di utilizzo, …).

Come si può intuire i dati raccolti da queste librerie di analytics, oltre che essere messi a disposizione dello sviluppatore della singola app, sono conservati anche dagli stessi fornitori delle librerie. Questi dati contengono informazioni sensibili, come le preferenze e le ricerche dell’utente, con quali altre app o siti interagiscono in un certo momento, ecc. Tali informazioni sensibili sono appetibili per aziende terze; pertanto, una buona parte del business model di questi player, che raccolgono dati sensibili tramite le librerie di analytics, si basa sulla vendita a terze parti di questi dati. Affinché questo avvenga in maniera legale, deve essere garantita la privacy degli utenti che hanno prodotto quei dati. Per questo motivo, i dati vengono dapprima aggregati e anonimizzati secondo tecniche allo stato dell’arte e poi venduti. In alcuni casi, dati aggregati e anonimizzati possono essere resi pubblici. In ogni caso se un attaccante, interno a qualche azienda (tali attori malevoli, sia nel campo della security che della privacy, vengono chiamati insider threat) o esterno, in caso di rilascio pubblico dei dati, sia in grado di de-anonimizzare qualche dato collegando anche solo un dato sensibile all’identità di una persona fisica, questo è un problema di violazione della privacy.

Come si può vedere, i due threat model sono molto differenti e i problemi che la security e la privacy affrontano nel contesto operativo mobile sono ragionevolmente ortogonali tra loro.

Obiettivi e costi dell’attaccante

Il malware non è altro che il mezzo tramite il quale un attaccante raggiunge il dispositivo e perpetra l’attacco a una vulnerabilità. Il malware deve essere sviluppato dall’attaccante e distribuito in modo da raggiungere lo smartphone. Per questo secondo punto esistono diverse tecniche, tra le quali la più famosa è il phishing (cfr. Sezione 4.1).

Riguardo lo sviluppo di un malware, questo processo ha costi in termini di tempo e risorse per l’attaccante. Pertanto, un malware viene prodotto solo se è conveniente per l’attaccante, ovvero se le probabilità di successo sono ragionevolmente alte e il guadagno derivante sensibilmente maggiore dei costi richiesti per realizzare il malware. Se “il gioco non vale la candela”, un attaccante non produce il malware e si interessa ad altri obiettivi. Da questo punto di vista, la protezione fornita dai sistemi di sicurezza ha in primis un effetto demotivante: più un sistema diventa difficile da attaccare e minore è il guadagno nel farlo, più il numero di malware è destinato con il tempo a diminuire.

Nel prosieguo ci concentreremo separatamente sulla sicurezza di Android e quella delle app. Prima di procedere, è importante sottolineare che i malware che attaccano Android hanno un obiettivo diverso rispetto a quelli che attaccano specifiche app.

Nel primo caso, l’obiettivo principale è prendere il controllo del sistema operativo (rooting) e, conseguentemente, di tutto il sistema. In caso di successo, ogni sistema di sicurezza di Android verrebbe bypassato e l’attaccante avrebbe pieno accesso a tutte le app e le risorse del sistema. La categoria di attacchi che persegue questo obiettivo prende il nome di privilege escalation e si basa sostanzialmente sullo sfruttamento di vulnerabilità nel sistema operativo. Inoltre, la privilege escalation può essere anche parziale: il malware non arriva a controllare l’intero sistema, ma almeno ad acquisire più diritti di quelli che spettano ad un’app.

Un obiettivo secondario di malware per il sistema operativo è bypassare i meccanismi di sicurezza per trovare nuovi canali di attacco alle app. Questi prendono il nome di side channel (cfr. Sezione 3.2.3).

Nel caso di malware che attaccano le app, questi sono realizzati per sfruttare una o più vulnerabilità specifiche di una o più app, che tendono a raggiungere seguendo i canali di comunicazione forniti (e protetti) da Android, o tramite i già citati side-channel. L’obiettivo è pertanto rubare dati contenuti nell’app (e.g., carte di credito, informazioni sensibili) oppure sfruttare le funzionalità dell’app all’insaputa dell’utente (e.g., usare un’app bancaria per fare trasferimenti di denaro).

Si noti che un malware si focalizza spesso su un insieme di app che condividono le stesse – o un sottoinsieme – delle vulnerabilità che sa attaccare. Questo è abbastanza comune per due motivi: in primis molte app si basano sulle stesse librerie che, se vulnerabili, rendono parimenti vulnerabili tutte le app che le usano; inoltre le app spesso hanno una radice comune, ovvero sono personalizzazioni di app generiche (chiamate white label^[3]): anche in questo caso, una vulnerabilità presente nella versione generica dell’app è presente con buona probabilità in tutte le sue personalizzazioni.

Le white label personalizzate sono abbastanza comuni negli app store, soprattutto nelle categorie delle attività commerciali: i titolari di queste attività non hanno, da una parte, “tempo e risorse” per creare un’app assumendo sviluppatori o affidandone lo sviluppo from scratch ad aziende terze, e, dall’altra, non hanno necessità di app particolarmente sofisticate (molte app sono solo informative e mappano le informazioni di un sito web).

Note

^[1] 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.

^[2] https://www.appbrain.com/stats/libraries/tag/analytics/android-analytics-libraries

^[3] https://www.appmachine.com/blog/white-label-app

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

Profilo Autore

Ha conseguito una laurea magistrale in Informatica nel 2005 presso l’Università degli Studi di Genova, ed il dottorato di ricerca in Informatica nel 2010 presso la stessa università. Dal 2010 la sua ricerca si concentra interamente nell’ambito della Cybersecurity, con un focus specifico sulla Mobile Security, dove negli anni contribuisce a definire metodi innovativi per l’analisi statica e dinamica della sicurezza di applicazioni Android, con ricadute in contesti reali (e.g., BYOD), a definire nuove metodologie di testing di applicazioni mobili e di protezione delle stesse quali
tecniche di offuscazione e protezione delle applicazioni da attacchi di repackaging.
Ha inoltre lavorato allo sviluppo di nuove tecnologie per l’autenticazione utente su dispositiviì mobili, a tecniche di profilazione dell’impronta energetica di attacchi e malware, ed a metodologie per la protezione dei dati personali degli utenti acquisiti dalle applicazioni mobili.
Ha contribuito alla scoperta di una serie di pericolose vulnerabilità, tra cui la Zygote Vulnerability, due vulnerabilità nei protocolli GSM ed UMTS, alcune nei Password Manager su Android, ed una sul servizio iNotify di Android, che avrebbero portato a diverse conseguenze sull’utente finale, dal furto di credenziali fino all’impossibilità di utilizzare il dispositivo mobile.
E’ autore di oltre 130 pubblicazioni scientifiche su riviste e conferenze internazionali ed ha ricevuto diversi riconoscimenti per l’attività di ricerca sulla Mobile Security.

https://www.ictsecuritymagazine.com/articoli/cose-la-mobile-security/