Elaborato svolto per la tesi triennale "Fast Track" (UniTS)

1. 1
UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria Elettronica e Informatica
Summary of “50 Ways to Leak Your Data:
An Exploration of Apps’ Circumvention of
the Android Permissions System”
Tesi di Laurea Triennale
AA. 2019-2020
Laureando:
Tommaso BALDO
Relatore:
prof. Alberto BARTOLI
___________________________________

2. 2
SOMMARIO
Introduzione ............................................................................................................................3
Fase di analisi ..........................................................................................................................4
Risultati.....................................................................................................................................6
Conclusione..............................................................................................................................8
Bibliografia...............................................................................................................................9

3. 3
INTRODUZIONE
Nel contesto in cui viviamo, caratterizzato da una crescente digitalizzazione, i dati
personali, ed ancor più il loro utilizzo, rivestono un’importanza meritevole di
protezione e tutela in quanto costituiscono un bene della persona.
Nel sistema operativo Android, le PII (Personally Identifiable Information), le
risorse di sistema e gli ID permanenti, sono protetti da permessi specifici che ne
controllano l’accesso. La gestione di questi è in mano all’utente: spetta a lui
accettare o negare le richieste fatte dallo sviluppatore al momento del bisogno.
Tuttavia, esistono vari metodi per aggirare tale sistema.
L’articolo preso in esame (1) si pone l’obiettivo di testare l’efficacia e trovare prove
della vulnerabilità nel sistema dei permessi, in particolare quelli legati ai dati
geografici e agli ID permanenti. Soprattutto questi ultimi sono di grande
importanza poiché identificano in modo unico un certo dispositivo o utente e non
possono essere in alcun modo modificati o cancellati.
Ci sono due diversi tipi di canale per ottenere le
informazioni: “covert channel” e “side
channel”. Il primo è un canale di comunicazione
tra due app che permette di scambiare dati
sensibili. Ciò permette ad un’app che può
accedere ad una certa risorsa di passare
l’informazione ad un’altra che non ha lo stesso
permesso. Il secondo invece è un percorso
alternativo che sfrutta delle features non
convenzionali per accedere ad un certo dato.
Sono state testate 88113 diverse app, scelte tra le
più popolari per ciascuna categoria. Dal
momento che ci possono essere differenze
significative tra una versione e la successiva,
sono state testate 252864 differenti versioni.
Oltre al file .apk, sono stati scaricati anche i
metadati relativi all’app.
Fig. 1: Rappresentazione grafica dei canali

4. 4
FASE DI ANALISI
Per individuare le possibili vulnerabilità del sistema dei permessi è stata creata
un’apposita pipeline, che ha analizzato in modo automatico tutte le app del corpus,
sfruttando una combinazione di analisi dinamica e statica. Il processo in questione
è particolarmente complesso e si compone di più fasi.
Analisi dinamica
In un primo momento, le app vengono eseguite su dei Nexus 5 e si osserva come
reagiscono ai vari input dell’utente, simulati con l’aiuto di un generatore
randomico di input.
L’osservazione prende in esame due livelli diversi: sistema e rete. Nel primo si
annotano tutte le volte che una certa app, contraddistinta dall’ID unico assegnato
da Android, apre un file per leggere o scrivere. A livello di rete viene utilizzato uno
strumento di monitoraggio per forzare un redirect di ogni dato ad un local host.
Quest’ultimo ha tre mansioni principali: ispeziona il traffico di rete, ricostruisce il
flusso di dati e lo assegna all’app che lo ha generato ed infine esegue
l’intercettazione del traffico “TLS” utilizzando un certificato installato.
È importante individuare il dominio di destinazione di un pacchetto contenente
una PII “rubata” per capire il responsabile. Nella maggior parte dei casi emerge che
i colpevoli sono degli SDK installati nelle varie app. È bene notare che questi
ereditano gli stessi permessi dell’applicazione in cui sono inseriti. Ciascuna app
viene eseguita per una decina di minuti e poi subito disinstallata ed i vari dati
collezionati vengono inseriti in un database.
Successivamente si analizza l’intero traffico di dati alla ricerca di trasmissioni
contenenti PII. Un confronto tra le informazioni inviate ed i permessi concessi
all’app, consente di verificare se l’applicazione ha estratto informazioni pur non
avendo il permesso necessario. L’analisi del traffico di rete è un’operazione
complicata a causa dell’utilizzo di tecniche di offuscamento. Per aggirare tale
ostacolo è stata utilizzata una suite di decoding realizzata per un lavoro precedente
(2).

5. 5
Nel corso dello studio sono emerse nuove tecniche di offuscamento e tale suite è
stata aggiornata di conseguenza. Ad ogni aggiornamento è stato rianalizzato
l’intero dataset.
Reverse engineering e analisi statica
Una volta individuate tracce di possibili violazioni del sistema, si prosegue con la
fase di reverse engineering, che viene svolta manualmente scomponendo il file .apk
e analizzando il codice smali.
È emerso che le app con lo stesso SDK “colpevole” seguono la stessa procedura.
Quindi, anziché analizzare ciascuna app, è sufficiente analizzare l’SDK
responsabile per capire in che modo avviene il raggiro del sistema.
Il passo successivo consiste nel contrassegnare un “fingerprint” per ciascuna
tecnica, solitamente il nome di un file o un messaggio d’errore specifici, che
permetta di riconoscere un determinato exploit. La presenza di un certo
“fingerprint” in un’altra app segnala che quest’ultima potrebbe sfruttare il relativo
canale. La ricerca dei vari “fingerpirint” nel corpus assicura di individuare tutte le
app abilitate all’utilizzo del relativo canale che, eventualmente, non sono state
individuate durante l’analisi dinamica a causa della sua natura randomica.
Fig. 2: Funzionamento della pipeline

6. 6
RISULTATI
I vari risultati ottenuti sono stati catalogati in base al tipo di permesso aggirato. In
totale sono stati trovati sei diversi canali: quattro di tipo “side” e due “covert”.
Tabella 1: I risultati ottenuti divisi per tipo di dato, relativo permesso e utilizzo
Illustro alcuni esempi.
Read_Phone_State
Due aziende cinesi, Salmonads e Baidu, hanno sviluppato due SDK differenti che
utilizzano la memoria SD come covert channel. Questi SDK sono implementati in
numerose app: nel primo caso per servizi di analytics e di monetizzazione, nel
secondo per servizi di mappatura e API di geocoding. In entrambi i casi si è potuto
osservare che un’app con l’SDK avente il permesso “READ_PHONE_STATE” è in
grado di ottenere e salvare l’IMEI del telefono in uno specifico percorso della
memoria SD in modo da renderlo visibile a tutte le altre app con lo stesso SDK ed il
permesso di accedere alla memoria.
Nel caso di Salmonads, oltre all’IMEI, vengono salvati anche un advertising ID, per
il target advertising, e l’indirizzo MAC del telefono, protetto dal
“ACCESS_NETWORK_STATE”. L’SDK di Salmonads è stato trovato su sei app, di
cui solo una con il permesso “READ_PHONE_STATE”. In totale, queste app sono
state installate 17.6 milioni di volte. I numeri per l’SDK di Baidu invece sono di
gran lunga maggiori: 153 app con la stringa che identifica il covert channel descritto
sopra, tra cui Samsung’s Health e due app della Disney con più di 500 milioni di
installazioni ciascuna. Di queste 153 solo 20 non avevano il permesso per leggere
l’IMEI.

7. 7
Access_Network_State
Il motore grafico Unity è presente in tantissimi giochi disponibili nel Play Store.
Analizzando la libreria libunity.so si è scoperto che Unity crea un socket e sfrutta
“ioctl”, una chiamata di sistema che può comportarsi in modo simile a “bind” o
“close”, per ottenere l’indirizzo MAC del dispositivo.
Access_WiFi_State
L’indirizzo MAC del router WiFi è importante perché consente di scoprire le varie
connessioni tra i dispostivi e di associare dispositivi diversi ad uno stesso utente.
Durante la ricerca, sono stati trovati due canali per accedere a tale informazione: la
lettura dell’ARP cache ed una richiesta diretta al router.
Nel primo caso, vi è l’esempio di un SDK prodotto da OpenX. Con semplice lettura
della ARP cache, eseguita leggendo il file /proc/net/arp, l’SDK è riuscito ad ottenere
le informazioni sul router.
Nel secondo caso, invece, tre app per il controllo da remoto prodotte da Peel hanno
aggirato il permesso con una semplice richiesta: è bastato infatti richiedere il file
igd.xml necessario per la configurazione. Il router ha risposto con vari dettagli, tra
cui il suo stesso indirizzo MAC inserito nel UUID.
Geolocalizzazione
Termino quindi la disamina analizzando un “side channel” per ottenere dati
geografici. Sono state individuate ben 70 app che inviavano dati sulla
localizzazione a 45 domini diversi. L’esempio riportato illustra come l’app
Shutterfly sfrutta l’accesso alla galleria per estrarre la locazione del telefono dal file
.EXIF, incluso nei metadati della foto stessa; quelli relativi alla posizione sono
presenti solamente se l’utente ha la localizzazione attiva al momento della foto. Una
volta processati, Shutterfly inserisce latitudine e longitudine in un oggetto JSON
poi inviato al proprio server. È importante osservare come questo canale sia di fatto
retroattivo: analizzando i vari metadati delle foto presenti in galleria è possibile
stabilire una vera e propria cronologia dei luoghi.

8. 8
CONCLUSIONE
La ricerca svolta ha rivelato un ristretto numero di “side” e “covert channels” ma,
osservando il numero di installazioni di ciascuna app, gli utenti esposti sono
centinaia di milioni. Tale numero può aumentare in maniera esponenziale se
consideriamo che in alcuni casi non è necessario avere installato un SDK specifico
ma è sufficiente conoscere la procedura; ad esempio, nel caso di Baidu è necessario
conoscere solo il file in cui è salvato il codice IMEI.
Dal punto di vista legale, l’utilizzo di questi canali è segnalato come una chiara
violazione della privacy dell’utente tramite pratiche ingannevoli: è ovvio che, se un
utente nega un certo permesso, l’app in questione non è autorizzata in alcun modo
ad accedere a tale risorsa. La legislazione e la conseguente pena variano da stato a
stato; nei paesi europei, ad esempio, sono una violazione del General Data
Protection Regulation (GDPR) 679/2016. Grazie al lavoro svolto, successivamente
reso pubblico, si vogliono fornire i dati e gli strumenti necessari agli organi
legalmente competenti ed alle stesse software houses per identificare tali pratiche e
prendere provvedimenti contro queste, tutelando il diritto alla privacy e
riservatezza degli utenti. Non è un caso, infatti, che la stessa Google abbia
riconosciuto i meriti e l’importanza del lavoro premiando gli autori con un “bug
bounty”, e che alcuni dei problemi segnalati siano già stati sistemati nell’ultima
release di Android.

9. 9
BIBLIOGRAFIA
1. “50 Ways to Leak Your Data: An Exploration of Apps’ Circumvention of the
Android Permissions System”, Joel Reardon et al., 2018.
2. “Won’t Somebody Think of the Children?”, Reyes et al., 2018.