Tecniche e strumenti di penetration testing per Android Mobile apps
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Scuola Politecnica e delle Scienze di Base Corso di Laurea Triennale in Ingegneria Informatica Tesi di Laurea Triennale in Ingegneria del Software Tecniche e strumenti di penetration testing per Android Mobile apps Anno Accademico 2018/2019 candidato Carmine Cesarano matr. N46002883
Obiettivo e struttura della tesi
L’obiettivo del lavoro di tesi è quello di analizzare una particolare metodologia
utilizzata nell’ambito del testing di sicurezza di un’applicazione per dispositivi
mobili, nota come Penetration Testing. Il primo capitolo introduce il lettore alla
sicurezza informatica. Dopo aver dato una panoramica generale sul testing e
aver posto l’attenzione su una particolare tipologia di testing, quello di sicurezza,
saranno esposti nel secondo capitolo la metodologia di penetration testing, una sua
classificazione e le diverse fasi di cui esso si compone. Nel terzo capitolo di questo
elaborato, dopo aver descritto brevemente l’architettura Android, la struttura di
un’applicazione e il Security Model implementato dal sistema operativo, saranno
analizzati e comparati alcuni degli strumenti che vengono attualmente utilizzati
per il penetration testing su Android. Nell’ultimo capitolo, utilizzando ’Appie’,
uno dei framework analizzati, verrà replicato uno scenario di penetration testing su
un dispositivo Android virtualizzato. Lo scopo dell’esempio è duplice: mettere in
pratica la metodologia descritta per comprendere meglio il flusso delle operazioni
da effettuare e, allo stesso tempo, mettere in evidenza le vulnerabilità più diffuse
e più pericolose di cui può soffrire un’applicazione Android.
i
Indice
Obiettivo e struttura della tesi i
1 Introduzione 1
1.1 Introduzione alla Sicurezza Informatica . . . . . . . . . . . . . . . . 2
1.2 Software Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Testing di Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Penetration Testing 7
2.1 Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Tipi di Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 External Testing . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Internal Testing . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Gray Box Testing . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Red Team e Blue Team . . . . . . . . . . . . . . . . . . . . . 9
2.3 Fasi di un Penetration Testing . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Pre-Engagement Interaction . . . . . . . . . . . . . . . . . . 10
2.3.2 Open Source Intellingence (OSINT) Gathering . . . . . . . . 11
2.3.3 Threat Modeling . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4 Vulnerability Assessment . . . . . . . . . . . . . . . . . . . . 13
2.3.5 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.6 Post-Exploitation . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.7 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Limiti del Penetration Testing . . . . . . . . . . . . . . . . . . . . . 15
ii
Tecniche e strumenti di penetration
testing per Android Mobile apps
3 Penetration Testing in Android 17
3.1 Architettura del sistema operativo Android . . . . . . . . . . . . . . 18
3.2 Struttura di un applicazione . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Android Security Model . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Fasi di un pentesting in Android . . . . . . . . . . . . . . . . . . . . 23
3.5 Strumenti per il pentesting in Android . . . . . . . . . . . . . . . . 25
4 Esempio di Pentesting: Appie 27
4.1 Configurazione dell’ambiente . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Installazione delle app vulnerabili . . . . . . . . . . . . . . . . . . . 29
4.3 Treath Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1 Superficie di attacco . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2 Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.1 Improper export of component . . . . . . . . . . . . . . . . . 33
4.5.2 Insecure data storage . . . . . . . . . . . . . . . . . . . . . . 35
4.5.3 Insufficient transport layer protection . . . . . . . . . . . . . 35
4.5.4 Unintended Data Leakage . . . . . . . . . . . . . . . . . . . 37
4.5.5 Poor Authentication and Authorization . . . . . . . . . . . . 38
4.5.6 Broken Cryptography . . . . . . . . . . . . . . . . . . . . . . 39
4.5.7 Extraneous Functionality . . . . . . . . . . . . . . . . . . . . 39
5 Conclusioni 42
iii
Capitolo 1
Introduzione
Negli anni lo smartphone è diventato uno strumento indispensabile per la comu-
nicazione e la gestione dei dati personali. Qualsiasi operazione che riguardi ad
esempio: pagamenti, transazioni, identificazione digitale o storage di dati sensibili
può essere effettuata con facilità tramite uno smartphone. Negli ultimi dieci anni
sono due i competitor che si contendono il mercato in questione: Google e Apple,
con i rispettivi sistemi operativi per dispositivi mobili, Android e iOS. Tradizional-
mente il primo si contraddistingue per fatto di essere un progetto completamente
Open Source; è infatti distribuito sotto i termini della licenza libera Apache 2.0.
La caratteristica dell’open source permette allo sviluppatore di consultare libe-
ramente il codice sorgente ed effettuare un’analisi più avanzata del sistema alla
ricerca di bug, vulnerabilità e falle di sicurezza. Questa caratteristica, accom-
pagnata da un’estensione massiccia del bacino d’utenza del sistema operativo in
questione (nel primo trimestre del 2019, circa l’80% degli smartphone ha Android
come sistema operativo[1]), giustifica sicuramente l’interesse per lo sviluppo di
malware per dispositivi Android. Un malware è un applicazione malevola atta a
sottrarre le informazioni personali della vittima o a controllare il suo dispositivo.
A marzo del 2018 si contano circa 26 milioni di detection di malware sui dispositivi
Android[2].
1
Tecniche e strumenti di penetration
testing per Android Mobile apps
A causa di questi numeri allarmanti si è reso necessario, fin da subito, iniziare a
discutere di sicurezza informatica, implementare meccanismi di analisi finalizzata
alla detection, ma ancor prima di definire metodologie di testing di sicurezza, per
cercare di prevenire a priori gli attacchi.
1.1 Introduzione alla Sicurezza Informatica
Con il termine ‘sicurezza informatica’ si intende quel processo di prevenzione e
individuazione dell’uso non autorizzato di un sistema informatico. Tali attività
indesiderate possono essere eseguite da soggetti che hanno un qualche interesse
nei confronti dei dati contenuti in un sistema o che vogliono in qualche modo
danneggiare il sistema stesso. È necessario chiarire che la sicurezza informatica
non deve essere intesa come una proprietà che può o non può essere raggiunta. È
più concreto invece identificare, per un sistema informatico, un livello di sicurezza e
quindi stabilire quale livello il sistema debba raggiungere. Per un sistema software
è essenziale che la sicurezza, oltre ad essere verificata a posteriori, quando il sistema
è in esercizio, sia garantita preventivamente già durante il ciclo di sviluppo, quindi
operando la fase di testing.
2
Tecniche e strumenti di penetration
testing per Android Mobile apps
1.2 Software Testing
In modo del tutto analogo alla maggior parte dei processi fisici, un componente
software riceve un insieme di dati in ingresso per elaborarli e produce un insieme
di dati di uscita. Qualsiasi attività finalizzata alla valutazione delle caratteristiche
di un programma o di un sistema e alla verifica che i componenti degli stessi
diano i risultati previsti rientra nella definizione di software testing. Una prima
caratterizzazione del processo di testing può essere fatta ponendo l’attenzione sui
due principali obiettivi da raggiungere a valle di questo processo:
• Dimostrare allo sviluppatore e al suo cliente che il software rispetta i requisiti
stabiliti;
• Rilevare situazioni in cui il comportamento del software non è corretto o è
indesiderabile.
Il primo obiettivo porta al testing di convalida, in cui è previsto che il sistema
esegua correttamente un determinato set di casi di test che riflettono l’utilizzo
effettivo del sistema. Il secondo obiettivo porta al testing dei difetti, in cui i casi di
test sono progettati con l’obiettivo specifico di portare alla luce i malfunzionamenti
del software. È anche vero che non vi è un confine definito tra queste due tipologie
di testing. Durante i test di validazione è possibile trovare difetti del sistema;
durante i test dei difetti potrebbero emergere requisiti non soddisfatti dal sistema.
È importante tenere presente che il testing non può dimostrare che il software
è privo di difetti o che si comporterà come specificato in ogni circostanza. È
sempre possibile che in un test alcune casistiche siano state trascurate in quanto
le combinazioni possibili dei valori di input validi sono enormi e non possono
essere riprodotte in un tempo ragionevole. Tuttavia, un buon testing può rendere
la probabilità di malfunzionamenti abbastanza bassa da essere accettabile.
“Testing can only show the presence of errors, not their absence”, Dijkstra
3Tecniche e strumenti di penetration
testing per Android Mobile apps
Un’altra suddivisione può essere fatta sulla base della granularità:
• Test di Modulo: ha lo scopo di verificare correttezza e completezza nell’im-
plementazione di ogni componente minimo dotato di funzionalità autono-
me, facendo emergere tempestivamente eventuali difetti, in modo che essi
possano essere corretti facilmente prima dell’integrazione. È realizzato me-
diante un approccio white-box testing e si articola tipicamente in test case
idealmente indipendentementi tra di loro.
• Test di integrazione: viene eseguito quando due o più unità già testate ven-
gono aggregate in una struttura più grande per determinare se rispettano il
comportamento atteso quando si trovano ad operare insieme come un unico
componente.
• Test di sistema: le singole caratteristiche testate dei vari moduli possono
essere diverse e numerose e, anche se queste sono corrette, il sistema ottenuto
integrandole potrebbe non esserlo. Pertanto, effettuare dei test sull’intero
sistema è significativo. L’approccio utilizzato è per lo più di tipo black box,
quindi orientato ai test funzionali, in quanto si deve utilizzare il software in
modo più vicino possibile alle condizioni di normale operatività.
1.3 Testing di Sicurezza
Il testing di sicurezza è una particolare tipologia di testing del software mirata
a controllare la riservatezza di servizi e informazioni e la capacità di resistere a
tentativi di violazione (accidentali o intenzionali). Questa fase del testing è orien-
tata ad ottenere, per l’applicazione che si sta realizzando, caratteristiche come:
autenticità, controllo degli accessi, segretezza dei dati, integrità dei dati e non
ripudiabilità. Il testing di sicurezza può risultare molto impegnativo, complicato
e costoso per applicazioni che richiedono un elevato grado di sicurezza. Il testing
4Tecniche e strumenti di penetration
testing per Android Mobile apps
dei meccanismi di sicurezza viene sempre affiancato dalle analisi di rischio, che
possono aiutare ad analizzare e valutare l’impatto e gli eventuali danni di una
potenziale vulnerabilità. Mentre le analisi di rischio vengono affrontate con un ap-
proccio White Box testing, sfruttando una profonda conoscenza dell’architettura
interna del software, il testing dei meccanismi di sicurezza invece, viene solita-
mente effettuato con test funzionali di tipo Black Box. In questa fase del testing,
la analisi e la valutazione delle potenziali vulnerabilità del sistema possono essere
condotte in molti modi tra cui:
• Riesame dei requisiti funzionali e delle specifiche tecniche del sistema infor-
matico basandosi sulla documentazione disponibile;
• Riesame del codice sorgente dell’applicazione (code review);
• Verifica statica della qualità e della sicurezza del codice (SAST o Static
application security testing);
• Verifica dinamica della qualità e della sicurezza del codice (DAST o Dinamic
application security testing);
• Scansione automatica del software con strumenti di vulnerability scanning;
• Prove di attacco (o penetration testing) da parte di personale autorizzato.
Chiunque si occupa di sicurezza conosce il principio del security-by-design:
la sicurezza deve essere considerata e progettata fin dalle prime fasi di analisi e
sviluppo del sistema informatico. Solo progettando in questo modo è possibile
creare un sistema realmente sicuro. Grazie all’introduzione del GDPR 1 [3] questo
approccio sta diventando fortunatamente sempre più noto. Purtroppo, però non
tutti i progetti esistenti sono stati sviluppati in questo modo e spesso la sicurezza
viene trattata come un ottimizzazione da apportare in seguito. Dunque, risulta
1
General Data Protection Regulation
5Tecniche e strumenti di penetration
testing per Android Mobile apps
necessario predisporre di alcune tecniche e strumenti atti a valutare a posteriori il
grado di sicurezza del sistema ed identificare le sue vulnerabilità.
6Capitolo 2
Penetration Testing
2.1 Penetration Testing
Per costruire un sistema sicuro è indispensabile delineare un profilo del potenziale
attaccante, capire come potrebbe agire e provare a scoprire tutte le vulnerabilità
del sistema tramite un vulnerability assessment. Dopo aver fatto ciò è necessario
eseguire dei penetration test che permettono di simulare l’attacco da parte di un
eventuale utente malevolo. In aggiunta a quello che succede con un vulnerability
assessment, dove i tester scoprono le vulnerabilità che potrebbero essere utilizzate
dagli aggressori, con un penetration testing quelle vulnerabilità rilevate vengono
sfruttate ed utilizzate per valutare cosa gli aggressori potrebbero ottenere dopo
una violazione avvenuta con successo [4]. Come definito dalla Computer Security
Division del NIST1 :
Un penetration testing è un test di sicurezza in cui i tester tentano di eludere i
sistemi di sicurezza di un sistema. Lo scopo del penetration testing è quello di iden-
tificare i metodi di accesso al sistema sfruttando strumenti e tecniche comunemente
utilizzate dagli hacker[5].
1
National Institute of Standards and Technology
7Tecniche e strumenti di penetration
testing per Android Mobile apps
2.2 Tipi di Penetration Testing
Esistono diversi tipi di penetration testing e normalmente la scelta dipende da ciò
che è necessario testare e se lo scopo è quello di simulare un attacco da parte di
un insider o un outsider. I due approcci più ampiamente accettati sono quello
del External Testing e quello del Internal Testing [6]. La differenza principale tra
le due metodologie è la quantità dei dettagli di implementazione forniti al tester
circa il sistema da testare.
2.2.1 External Testing
Con i pentest2 esterni, anche definiti test Black Box, i tester simulano un attacco
eseguito da un’entità che non ha precedenti conoscenze sull’infrastruttura da te-
stare. Nell’ambito di questi test i valutatori potrebbero essere a conoscenza, ad
esempio, soltanto del sito web o dell’indirizzo IP della rete. Tutte le altre infor-
mazioni necessarie devono essere raccolte implementando tecniche generalmente
utilizzate nell’ambito dell’hacking (social engineering, network scanning, motori
di ricerca, ecc.).
2.2.2 Internal Testing
Un pentest interno viene di solito effettuato da un tester interno all’organizzazione.
Permette di simulare la situazione in cui un utente malevolo riesce ad ottenere pas-
sword e altri dati di accesso di un impiegato. In pratica corrisponde ad un test di
tipo White Box, in cui l’attaccante ha una conoscenza completa dell’infrastruttura
da testare [6][7].
2
penetration testing
8Tecniche e strumenti di penetration
testing per Android Mobile apps
2.2.3 Gray Box Testing
La combinazione di entrambi i precendenti approcci fornisce una visione globale
della sicurezza da un punto di vista sia interno che esterno. Questa combinazione
è nota come Gray Box Testing. In questo approccio, i tester hanno o sono forniti
di una certa conoscenza e sono posti in una posizione privilegiata. E’ il metodo
preferito quando è necessario diminuire i costi per il team di testing.
2.2.4 Red Team e Blue Team
I penetration test possono essere condotti come teaming blu, cioè con la conoscenza
e il consenso del personale IT dell’organizzazione che predispone il test, o teaming
rosso, cioè solo con la conoscenza e l’autorizzazione del reparto di direzione. Il
teaming rosso è quello più costoso e complesso da gestire, ma può fornire una
migliore indicazione sulla sicurezza del sistema e permette di proteggersi anche da
eventuali attacchi interni eseguiti ad esempio da dipendenti insoddisfatti.
2.3 Fasi di un Penetration Testing
In generale, il processo di penetration testing può essere suddiviso in diversi pas-
saggi o fasi. Anche se non vi è una struttura prefissata, in quanto gli approcci
9Tecniche e strumenti di penetration
testing per Android Mobile apps
possono variare molto a seconda delle competenze del tester, dello scopo del te-
sting e del sistema sotto esame, il Penetration Testing Execution Standard
(PTES) detta alcune linee guida articolate in 7 livelli principali che aiutano a
definire le procedure da seguire durante un penetration testing.
1. Pre-engagement Interactions
2. OSINT Gathering
3. Threat Modeling
4. Vulnerability Assessment
5. Exploitation
6. Post Exploitation
7. Reporting
2.3.1 Pre-Engagement Interaction
Prima di effettuare un penetration testing è opportuno definire con cura tutti i
requisiti necessari e programmare nel dettaglio tutte le operazioni che verranno
eseguite. È necessario inoltre avere autorizzazioni formali per ottenere tali requisiti
dato che il testing potrebbe causare gravi conseguenze al sistema in esame. Il
PTES considera l’ottenimento di questi requisiti come parte della fase di ‘Pre-
engagement’ [8]. I requisiti possono comprendere:
• Lista degli indirizzi IP da testare;
• Lista degli host da testare;
• Una stima dei tempi di esecuzione del testing;
• La definizione del periodo e degli orari durante il quale il testing è effettuato;
10Tecniche e strumenti di penetration
testing per Android Mobile apps
• Indirizzi IP delle macchine attraverso le quali vengono effettuate le simula-
zioni di attacco;
• Informazioni raccolte e risorse violate durante il test;
• Tecniche e strumenti che è possibile utilizzare e non;
• Azioni da intraprendere una volta che il sistema sarà violato con successo;
• Altri requisiti possono includere aspetti legali e contrattuali che specificano
le responsabilità individuali del tester.
2.3.2 Open Source Intellingence (OSINT) Gathering
Questa fase, detta anche di Information gathering, ha l’obiettivo di raccogliere
informazioni utili sul sistema sotto test che verranno poi utilizzate durante le
successive fasi del penetration testing. Solitamente le informazioni sono tutte
disponibili pubblicamente. Questa fase si può suddividere a sua volta in vari step:
Reconnaissance Per portare a termine questa fase con successo devono es-
sere incluse tecniche di reconnaisance sia passive che attive. La reconnaissance
passiva si avvale di risorse informative disponibili sul web e non prevede un in-
terazione diretta con l’obiettivo; di conseguenza questo tipo di attività non può
essere mai rivelata dall’obiettivo. Possono essere utilizzate tecniche di social engi-
neering o sfruttati i motori di ricerca. La reconnaissance attiva, invece, può essere
rilevata dal target come un comportamento sospetto o malevolo. Durante questa
attività infatti, viene profilato direttamente il target mappando l’infrastruttura del
sistema tramite fingerprinting, port scanning, network mapping e web profiling.
Il vantaggio di utilizzare entrambi i metodi è quello di poter identificare informa-
zioni storiche mantenute in rete tramite la raccolta passiva, e di validare quelle
11Tecniche e strumenti di penetration
testing per Android Mobile apps
informazioni con metodi attivi. Gli strumenti e le tecniche più comuni utilizzate
in questa fase di reconnaissance sono:
• Social Engineering: questa tecnica basa la sua natura sulla capacità del
tester di manipolare la psicologia umana. In questo caso il tester entra di-
rettamente nell’organizzazione che richiede il test e, con tecniche persuasive,
cerca di estrapolare più informazioni possibili dai dipendenti.
• Garbage Picking: il cassonetto dei rifiuti può fornire al pentester informa-
zioni sensibili, sia a livello hardware che software. Documenti che vengono
classificati come meno importanti, e gettati senza alcuna attenzione, potreb-
bero fornire informazioni come nomi, indirizzi, numeri di telefono e id dei
dipendenti.
• Internet Footprinting: è il metodo di reconnaissance che fornisce i risultati
più importanti. Possono essere identificate quattro tecniche:
1. Web Presence: navigando sulle pagine web della società, il pente-
ster può raccogliere molte informazioni, come ad esempio i dati dei
dipendenti.
2. DNS Reconnaissment: sfruttando i server DNS è possibile, partendo
dai nomi di dominio della rete di destinazione, ricavare gli indirizzi IP.
Vengono utilizzati strumenti come DNS Lookup o Nslookup
3. Network Enumeration: è il processo che utilizza un particolare tool
chiamato WHOIS; mediante l’interrogazione di appositi database con-
sente di stabilire a quale provider appartiene un determinato indirizzo
IP o uno specifico DNS3 , informazioni di contatto amministrativo e
tecnico, con nomi, numeri di telefono e indirizzi e-mail [9];
3
Domain Name System
12Tecniche e strumenti di penetration
testing per Android Mobile apps
4. Network-based Reconnaissance: è il processo di identificazione dei com-
puter e degli altri servizi attivi su una rete di destinazione utilizzando
strumenti come ping, traceroute e netstat.
Port Scanning La fase di port scanning permette di identificare gli host
presenti all’interno della rete target. Per questi sistemi poi è possibile identificare le
porte aperte e quelle filtrate, i servizi che sono in esecuzione, i dettagli del sistema
operativo, i percorsi di rete, ecc. Alcuni degli strumenti più comuni utilizzati
durante questa fase sono Nmap, Netcat, Superscan.
Enumeration Dopo aver identificato i sistemi attivi e i servizi in esecuzione,
essi dovrebbero essere classificati ed enumerati. L’enumerazione di fatto consiste
nel selezionare tra tutti quelli identificati un sottoinsieme dei punti di accesso più
vulnerabili e nell’eliminazione di eventuali falsi positivi.
2.3.3 Threat Modeling
Per portare a termine un penetration testing con successo, il tester oltre ad avere
più informazioni possibili sul target, deve avere una panoramica anche dei po-
tenziali attaccanti e del tipo di minacce che potrebbero derivare da un eventuale
attacco. Questo fornisce chiarezza per quanto riguarda la propensione al rischio
e permette la definizione di alcune priorità: quali minacce sono più importanti,
quali risorse è più importante proteggere, ecc.
2.3.4 Vulnerability Assessment
L’obiettivo di questo step è quello di identificare e analizzare le vulnerabilità del
sistema in esame e quindi assegnare un grado di pericolosità alle eventuali minac-
ce che ne possono derivare, monitorando gli eventuali danni provocati al sistema.
Esistono dei database che elencano e classificano le vulnerabilità note, come ad
13Tecniche e strumenti di penetration
testing per Android Mobile apps
esempio SecurityFocus [10], Exploit-DB [11] e PacketStorm [12]. Per questa at-
tività vengono abitualmente sfruttati alcuni tools che, grazie alla loro velocità di
scansione, permettono di analizzare automaticamente ed in breve tempo un ampio
numero di servizi.
2.3.5 Exploitation
Durante un penetration testing, la vera e propria violazione del sistema costituisce
una delle fasi più critiche. In questo step vengono sfruttate le vulnerabilità che sono
state identificate per violare le misure di sicurezza del sistema. Come descritto
in [13], un exploit è il mezzo attraverso il quale il penetration tester può ottenere
l’accesso ad una determinata risorsa. Poiché è probabile che gli exploit causino
danni temporanei o permanenti al sistema sotto test, è responsabilità del tester
determinare se è accettabile o meno usare un certo exploit. In alcuni casi si
rende necessario provare l’exploit prima in un ambiente controllato e simulato[14].
Mantenere una buona comunicazione con il cliente, di solito, supporta il tester in
queste decisioni.
2.3.6 Post-Exploitation
Una volta che il sistema è stato violato è necessario effettuare una serie di opera-
zioni che ricadono in una fase detta di post exploitation.
Privilege Escalation La posizione raggiunta con la fase di exploitation vie-
ne sfruttata per tentare di ottenere dei permessi più privilegiati. Questo viene
fatto per acquisire il controllo di risorse che normalmente sono precluse al gruppo
di utenti che è stato violato e magari per estendere il proprio controllo anche ad
altri sistemi della rete. Solitamente l’obiettivo viene prefissato è quello di ottenere
i privilegi di root del sistema.
14Tecniche e strumenti di penetration
testing per Android Mobile apps
Maintaining Access Nella fase di post exploitation inoltre vengono imple-
mentate tecniche per garantire un accesso facilitato al sistema, da utilizzare in un
momento futuro, come ad esempio il reindirizzamento di una porta o l’installazione
di una backdoor.
Cleaning-up Un’altra attività essenziale da eseguire nella fase di post ex-
ploitation è il ripristino dello stato iniziale del sistema che è stato esaminato. Ven-
gono quindi rimossi eventuali rootkit installati o programmi backdoor configurati,
ripristinate le configurazioni di dispositivi e dell’infrastruttura di rete, effettua-
ta la pulizia delle voci di registro aggiunte durante l’exploit e rimosse infine le
condivisioni e le connessioni stabilite durante l’attacco.
2.3.7 Reporting
È necessario ricordare che l’obiettivo principale di un penetration testing non è
solo compromettere il sistema o la rete, ma anche informare e portare consapevo-
lezza alle parti interessate, in particolare all’amministratore del sistema, su quali
vulnerabilità esistono. Il report deve essere un documento molto dettagliato che,
oltre ad esibire informazioni sulle vulnerabilità riscontrate, fornisce una valutazio-
ne dei possibili rischi che possono comportare, con il relativo grado di pericolosità.
Vengono inoltre aggiunti dei suggerimenti ritenuti opportuni per l’eliminazione
delle vulnerabilità riscontrate.
2.4 Limiti del Penetration Testing
I penetration testing sono strumenti utili che possono avere un enorme valore per
rafforzare la sicurezza di un qualsiasi dispositivo o sistema, tuttavia hanno dei
limiti. Prima di tutto, un penetration testing potrebbe non identificare tutte le
vulnerabilità a causa di limitazioni sul tempo o sui costi che è possibile investi-
15Tecniche e strumenti di penetration
testing per Android Mobile apps
re. Al contrario del tester, una volta che il sistema è in esercizio, un eventuale
attaccante ha tutto il tempo per ricercare difetti che non sono stati trovati nel-
la fase di testing. Oltre a questi limiti imeposti dal progetto, i risultati di un
pentration testing possono essere compromessi dall’uso di exploit noti pubblica-
mente. Normalmente i tester non scrivono exploit ad hoc, ma si basano su quelli
più ampiamente diffusi ed utilizzati. Un attaccante esperto potrebbe scrivere un
exploit personalizzato, adattandolo ad un determinato difetto e ad un determinato
ambiente di destinazione. Inoltre, è da considerare il fatto che i penetration te-
sting potrebbero essere limitati deliberatamente escludendo determinate tecniche
perché magari potrebbero provocare danni ingenti a sistema in esercizio. [15].
16Capitolo 3
Penetration Testing in Android
Il penetration testing è uno strumento essenziale per testare la sicurezza di un’ap-
plicazione mobile. Gli obiettivi del penetration testing sono identificare, correggere
e prevenire le falle e le vulnerabilità di sicurezza all’interno dell’applicazione e di
determinare il danno che potrebbero comportare se sfruttate. L’archiviazione non
sicura delle password, la divulgazione di informazioni personali, la configurazione
non adeguata dei privilegi, l’autorizzazione alla modifica di file che dovrebbero
essere invece protetti sono tutte vulnerabilità comuni trovate tra le più diffuse
applicazioni. Prima di scendere nel dettaglio e descrivere gli strumenti necessari e
le metodologie per condurre un penetration testing in Android, è necessario avere
una visione generale di quella che viene definita superficie di attacco, ossia l’insie-
me dei diversi punti di accesso che possono essere sfruttati durante un penetration
testing. Per fare ciò è indispensabile comprendere l’architettura del sistema ope-
rativo Android, quale sia la struttura di un’applicazione e come i suoi componenti
interagiscono tra di loro.
17Tecniche e strumenti di penetration
testing per Android Mobile apps
3.1 Architettura del sistema operativo Android
Android è uno stack software open source sviluppato per dispositivi mobili da
Google Inc. La sua architettura a livelli, in cui gli strati inferiori offrono servizi a
quelli superiori, permette un livello di astrazione dell’hardware via via crescente.
Il livello più basso è costituito da Kernel Linux. Oltre che esporre funzionalità
tradizionalmente offerte da Linux come l’astrazione dell’hardware del dispositivo
tramite i device driver, la gestione dei processi, la gestione della memoria, il ker-
nel viene migliorato con delle modifiche esclusive per Android. Il Binder Driver,
ad esempio, sostituisce i meccanismi IPC1 tipici di Linux ed utilizza una parte
della shared memory riservata al Kernel per permettere alle applicazioni e ai loro
thread di comunicare tra loro e scambiarsi dati. Al secondo livello dello stack si
trovano le Native Libraries, un insieme di librerie scritte in C/C++ che imple-
mentano a basso livello diverse funzionalità tra cui: grafica 2D e 3D, un DBMS2
relazionale, funzionalità a supporto delle tecnologie web, codec per acquisizione e
riproduzione audio e video, ecc. Allo stesso piano è posto il componente Android
Runtime all’interno del quale coesistono istanze multiple di una particolare VM3 ,
la Dalvik Virtual Machine, ottimizzata per sfruttare le risorse limitate dei dispi-
sitivi mobili (potenza della CPU, memoria RAM e batteria). La DVM è stata
successivamente sostituita con ART4 , molto più performante e che, al contrario
del suo predecessore, compila l’intero codice durante l’installazione dell’app e non
durante l’esecuzione della stessa. A seguire, nello stack è presente l’Application
Framework, un insieme di API Java che fornisce un set di componenti riutiliz-
zabili direttamente dalle applicazioni sviluppate in linguaggio Java. Il livello più
alto è costituito da in insieme di applicazioni di sistema che offrono funzionalità
di base come calendario, gestore email, dialer, contatti, ecc.
1
Inter Process Communiclation
2
Database management system
3
Virtual Machine
4
Android RunTime
18Tecniche e strumenti di penetration
testing per Android Mobile apps
3.2 Struttura di un applicazione
Analizzare la struttura di un applicazione ed individuare i suoi componenti princi-
pali risulta fondamentale per una corretta comprensione del modello di sicurezza
implementato in Android.
Activity L’Activity rappresenta il componente attraverso il quale l’utente
può interagire con l’applicazione. La composizione di uno o più moduli di questo
tipo realizzano di fatto l’interfaccia grafica dell’app. Le activity di un’applicazione
sono organizzate in uno stack la cui modalità di accesso segue una politica LIFO5 .
L’Activity ha un proprio ciclo di vita cioè, durante la propria esistenza, può passare
attraverso diversi stati:
1. ACTIVE : l’activity si trova in testa allo stack, è visibile ed è quella con cui
l’utente sta attualmente interagendo;
2. PAUSED: l’activity non è attiva ma è ancora parzialmente visibile, o per la
trasparenza di quelle superiori o perché queste non occupano l’intero spazio
5
Last in First Out
19Tecniche e strumenti di penetration
testing per Android Mobile apps
a disposizione. Essa non è sensibile agli eventi dell’utente ma mostra lo stato
precedente alla sua messa in pausa;
3. STOPPED: l’activity non è attiva, né visibile. Non è sensibile alle interazioni
dell’utente ed è tra le prime candidate ad essere eliminata.
4. INACTIVE : l’activity viene eliminata e non si trova più nello stack.
Service Un Service è adatto per operazioni da svolgere in background e
che quindi non necessitano di un interazione diretta con l’utente. Componenti
di questo tipo sono preservati dal sistema, che non li elimina se non in situazioni
estreme. Essi possono offrire determinati servizi a favore di un Activity. Il modello
di interazione tra un Activity e un Service è quello Client-Server.
Content Provider Il Content Provider è un meccanismo utilizzato per con-
dividere basi di dati di utilità generale presenti nel sistema operativo (contatti, ca-
lendario) oppure per permettere a più applicazioni di condividere le proprie strut-
ture dati. L’oggetto che permette di invocare un Content Provider è il Content
Resolver con il quale comunica secondo un paradigma Client-Server.
Broadcast Receiver I Broadcast Receiver forniscono la possibilità all’appli-
cazione di registrarsi a particolari eventi, segnalati dal sistema o da un’applicazione
ed inviati in broadcast. L’arrivo di un SMS o l’avviso di batteria scarica possono
esserne un esempio. Come i Service, i BR non implementano un’interfaccia grafica,
ma possono eseguire un Activity in risposta a determinati eventi segnalati. Sono
sfruttati spesso da applicazioni malevole che si mettono in attesa un determinato
tipo di evento per eseguire una qualsivoglia azione.
20Tecniche e strumenti di penetration
testing per Android Mobile apps
3.3 Android Security Model
Sandboxing Il modello di sicurezza di Android sfrutta le funzionalità offerte
dal kernel Linux di isolamento delle risorse e dei processi, trattando tuttavia gli
utenti in modo differente. In un sistema Desktop, un UID6 è assegnato ad ogni
utente fisico che può accedere al sistema. Essendo Android progettato per smart-
phone, solitamente ad uso personale, UID differenti sono utilizzati per identicare
differenti applicazioni. La creazione di un’istanza separata di una VM per ogni ap-
plicazione installata sul dispositivo crea una vera e propria Sandbox, che garantirà
l’isolamento di ogni app rispetto alle altre e rispetto al sistema operativo[16].
Permessi Oltre ad utilizzare la tecnica del sandboxing, Android protegge le
applicazioni anche a livello ICC7 utilizzando il concetto di permesso. Un permesso
è una stringa che un’applicazione deve possedere per far sì che un suo componente
possa utilizzare risorse sensibili (GPS, accesso alla rete, rubrica, ecc..) oppure
comunicare con altri componenti, attraverso internet ad esempio. Un reference
monitor provvede al controllo dei tentativi di accesso ad un componente. Ciascun
accesso viene identificato da un access permission label. Se l’access permission
label del secondo componente è tra quelli contenuti nel manifest dell’applicazione
allora la comunicazione è consentita[16]. I permessi in Android vengono suddivisi
in due grosse categorie:
• Permission NORMAL: non mettono a rischio la privacy dell’utente (acces-
so alla rete, accesso a periferiche per la connettività, impostazione di un
allarme, gestione della vibrazione, ecc.). Permessi di questo tipo vengono
automaticamente concessi dal sistema all’applicazione;
• Permission DANGEROUS : potenzialmente più lesive per la privacy (localiz-
zazione, contatti, attività telefoniche, accesso ai file, ecc.). L’installazione di
6
User Id
7
Inter-Component Communication
21Tecniche e strumenti di penetration
testing per Android Mobile apps
app che prevedono la concessione di tali permessi può procedere solo previa
autorizzazione esplicita dell’utente.
AndroidManifest Il manifest, oltre che contenere informazioni sulla struttura
dell’applicazione, come la dichiarazione delle componenti da cui è costituita op-
pure gli Intents che è in grado di gestire, costituisce il file in cui risiedono tutti i
permessi che un’applicazione richiede al sistema per svolgere il proprio compito.
Affinchè possa essere garantita l’interazione con le risorse esterne ad essa, ogni ap-
plicazione dovrà dichiarare esplicitamente in maniera statica a quali risorse vorrà
avere accesso. Ogni volta che un’app tenterà di incorporare o di accedere ad una
risorsa non dichiarata nel proprio manifest verrà sollevata un’eccezione di sicurezza
che interromperà l’esecuzione del programma[16].
Signing In Android tutte le applicazioni devono essere certificate affinché pos-
sano essere installate ed eseguite sul dispositivo. La creazione di tale certificato
non richiede l’intervento di una CA8 ; esso viene auto-generato dallo sviluppatore
in fase di rilascio dell’applicazione [16]. Questo meccanismo è necessario al sistema
per:
• Aggiornamenti: per aggiornare un’applicazione il sistema confronta la signa-
ture dell’upgrade con quella dell’applicazione installata;
• Modularità: Android permette alle applicazioni certificate con la stessa
signature di essere eseguite all’interno dello stesso processo UNIX;
• Condivisione dati tramite permessi: applicazioni diverse, ma con la stessa
signature e che utilizzano permessi signature-based possono condividere in
maniera sicura codice e dati tra loro.
8
Certification Authority
22Tecniche e strumenti di penetration
testing per Android Mobile apps
Intent I meccanismi di Binder, implementati all’interno del Kernel per permet-
tere l’IPC9 , sono completamente trasparenti agli sviluppatori. Ad un livello di
astrazione più alto troviamo perciò altri strumenti utilizzati per la gestione della
comunicazione tra le applicazioni. Vengono in particolare largamente utilizzati gli
Intent, ovvero dei messaggi che specificano una determinata azione da compiere
[16]. Permettono di invocare componenti esterne all’applicazione semplicemente
richiedendone l’esecuzione in maniera esplicita o implicita. Si parla di intent espli-
citi se utilizzati per far comunicare Activity della stessa applicazione. Il messaggio
seleziona in maniera precisa il componente candidato a compiere l’azione richie-
sta. Sono invece definiti intent impliciti i messaggi utilizzati per far comunicare
componenti di applicazioni diverse. L’intent in questo caso non specifica il com-
ponente di destinazione ma solo il tipo di azione da eseguire. Quando si fa uso
di un intent, è necessario che nel sistema sia installata un’applicazione che abbia
dichiarato nel proprio manifest la disponibilità a gestire quel determinato Intent.
3.4 Fasi di un pentesting in Android
Per un’applicazione Android, in accordo con il PTES, il processo di penetration
testing può essere diviso nei sette principali steps descritti precedentemente nel
paragrafo 2.3. Gli obiettivi finali delle diverse fasi non sono differenti da quelli
che vengono prefissati per un qualunque altro sistema non mobile; a cambiare
sono le metologie e gli strumenti utilizzati. Tuttavia, in Android, il susseguirsi
delle diverse fasi non è necessariamente lineare e le operazioni si possono alternare
ciclicamente.
Pre-Engagement Questa fase comprende la definizione degli obiettivi del test,
delle tempistiche e la documentazione di eventuali limiti o restrizioni. Lo scopo
9
Inter Process Communication
23Tecniche e strumenti di penetration
testing per Android Mobile apps
finale di questa fase è arrivare alla stipulazione di un contratto che specifichi tutti
questi dettagli.
OSINT Gathering È la fase di reconnaissment classica del pentesting. Su di-
spositivi Android è necessario profilare il target, ad esempio analizzando le funzio-
nalità, le descrizioni, dipendenze, proprietà, permessi e la cronologia delle versioni
di un componente o un’applicazione. Tutte queste informazioni di base sono forni-
te dal Google Play Store, o in generale reperite in rete sfruttando motori di ricerca
e consultando forum specializzati.
Threat Modeling In questa fase, è necessario riconoscere le minacce e l’impatto
che esse possono generare sul componente o sull’intera applicazione. Questa fase
dovrebbe includere la decompilazione dei binari compilati e lo studio dell’architet-
tura dell’applicazione per determinare i componenti e le relative funzionalità. Un
altro scopo di questa fase è determinare tutti i punti di accesso di un componente
Android, la cosiddetta superfice di attacco. Per un’applicazione, questi punti di
accesso sono definiti nell’Android Manifest; sono necessari dunque alcuni tool di
reverse engineering come APKTool per ricavare questo file.
Vulnerability Analysis È il processo mediante il quale si cerca di scoprire de-
bolezze e falle di sicurezza nei componenti Android, analizzando le informazioni
raccolte durante la fase precedente. Vengono eseguite, per ciascuno dei binari, sia
scansioni statiche che dinamiche per identificare problemi di compilazione, auto-
rizzazioni non necessarie, memorizzazione improprie dei dati locali, informazioni
non codificate.
Exploitation La fase di exploitation si concentra esclusivamente sullo stabilire
l’accesso ad un componente Android bypassando le misure di sicurezza. In que-
sta fase si tenterà di sfruttare tutte le vulnerabilità identificate. Ciò permette
24Tecniche e strumenti di penetration
testing per Android Mobile apps
di valutare il reale livello di rischio associato ad una vulnerabilità sfruttata con
successo.
Post Exploitation Lo scopo di questa fase è determinare il livello di compro-
missione del dispositivo e di mantenere il controllo per usi successivi, ad esempio
installando una backdoor. Nel sistema Android, è possibile sfruttare le vulnerabili-
tà di un’applicazione installata per compromettere l’intero dispositivo ed effettuare
l’escalation dei privilegi.
Reporting Il report è una parte essenziale di un penetration testing. Que-
sto rapporto documenterà la metodologia e gli exploit utilizzati, le vulnerabilità
riscontrate ed eventuali consigli per eliminarle.
3.5 Strumenti per il pentesting in Android
In letteratura sono numerevoli e di diverse tipologie gli strumenti utilizzati per
effettuare un penetration testing su un dispositivo Android. La scelta dipende
dalle esigenze, dalle finalità del testing e dal tipo di applicazione da testare. Per
portare a termine un penetration testing con successo è sempre necessario utiliz-
zare differenti tools, ognuno dei quali può coprire una determinata fase del testing.
Per questo motivo sono nati alcuni framework o addirittura sistemi operativi in-
teramente dedicati al pentesting che, racchiudendo un insieme di strumenti in un
unico ambiente, mirano a semplificare e velocizzare il lavoro dei tester. Ognuno
di essi è tarato con determinate configurazioni e per questo non è detto che corri-
spondano in toto alle necessità del tester. Prima di intraprendere un penetration
testing è necessario dunque avere una visione generale di quelli che sono gli stru-
menti esistenti e di quali sono le loro potenzialità. Nella tabella che segue sono
elencati i più diffusi sistemi operativi, framework o tools utilizzati nell’ambito del
penetration testing di applicazioni Android, specificando per ognuno di essi quali
25Tecniche e strumenti di penetration
testing per Android Mobile apps
fasi del penetration testing mobile riescono a coprire. Sono state omesse le fa-
si di pre-engagement, information gathering e di reporting che non si avvalgono
dell’utilizzo di alcun tool.
Tipologia Threat Vulnerability Exploitation Post
Modeling Analysis Exploitation
[17] Kali Linux OS X – X X
[18] Pentoo OS X – – –
[19] Andrax OS X X X –
[20] Androl4b OS X X – –
[21] Santoku OS X X X –
[22] Vezir Project OS X X – –
[23] BlackArch OS X X X –
[24] Mobisec OS – X X –
[25] Appie framework X X X –
[26] AndroBugs framework – X – –
[27] MARA framework X X – –
[28] MobSF framework X X – –
[29] Metasploit framework – – X X
Come è possibile notare, nessuno degli strumenti analizzati copre tutte le fasi
del penetration testing ed inoltre, molti di quelli analizzati includono funzionalità
superflue non dedicate ai dispositivi mobile. Di particolare rilevanza è il framework
’Appie’, completamente dedicato ad Android e che, al contrario di molti altri
framework, è pronto per l’uso, cioè non necessita di alcuna dipendenza esterna.
26Capitolo 4
Esempio di Pentesting: Appie
In letteratura esistono molti strumenti adoperati per un penetration testing su
Android. In questo lavoro di tesi si è fatto uso di un pacchetto software pre-
configurato denominato Appie (Android Pentesting Portable Integrated Environ-
ment). Esso è utilizzabile su qualunque macchina Windows-based senza la neces-
sità di installare una VM1 o utilizzare il DualBoot ed è completamente portable.
È uno strumento per le analisi di sicurezza su Android unico nel suo genere e
risulta essere una soluzione unica per operazioni di Security Assessment, Forensic
e analisi Malware.
4.1 Configurazione dell’ambiente
È necessaria una semplice installazione del pacchetto Appie su una macchina Win-
dows, dato che qualsiasi dipendenza di cui necessita è contenuta nello stesso pac-
chetto. Deve essere poi configurato un emulatore per device Android. In questo
lavoro è stato scelto il software Genymotion ed emulato un dispositivo ‘Google
Nexus 4’.
1
Virtual Machine
27Tecniche e strumenti di penetration
testing per Android Mobile apps
Per avere la certezza che Appie abbia visibilità del device virtualizzato tramite
Genymotion, viene eseguito il seguente comando:
Dopo aver configurato il dispositivo è necessario installare al suo interno un
server, il ‘Drozer Agent’ che, comunicando con un client preinstallato in Appie,
permette di effettuare diverse operazioni utili durante il testing.
Una volta avviato, il Server, di default, si metterà in ascolto sulla porta ’31415’.
Per permettere la connessione tra Client e Server, si esegue il comando: ’adb
forward tcp:31415 tcp:31415’ nella console di Appie. Per avviare invece il Client
sul PC si esegue il comando ‘drozer.bat console connect’.
28Tecniche e strumenti di penetration
testing per Android Mobile apps
4.2 Installazione delle app vulnerabili
Nell’ambito di questo lavoro sono state sottoposte al penetration testing delle
applicazioni che includono intenzionalmente alune vulnerabilità e falle di sicurezza:
FourGoats, HerdFinancial e Sieve. Di seguito, la procedura per installare una delle
applicazioni sul dispositivo target virtualizzato:
4.3 Treath Modeling
Drozer è uno strumento fondamentale nel testing di sicurezza per applicazioni
Android; esso permette di ridurre il tempo necessario per la valutazione delle vul-
nerabilità. Tramite questo tool è possibile ricavare prima di tutto l’identificativo
univoco dell’applicazione e poi altri dettagli come l’UserID, GID, i permessi del-
l’utente, la directory dei dati, il path del file apk, librerie condivise, versione e
nome dell’applicazione.
4.3.1 Superficie di attacco
È possibile richiedere a Drozer un report sulla superficie di attacco, cioè l’insieme
di tutti i componenti IPC che l’applicazione ha esportato per renderli disponibili
29Tecniche e strumenti di penetration
testing per Android Mobile apps
al sistema, all’utente o ad altre applicazioni.
Il risultato mostra i potenziali vettori d’attacco ed inoltre evidenzia che i servizi
esportati sono debuggable, caratteristica che verrà approfondita in seguito.
Activity Scavando più a fondo nella superficie di attacco, utilizzando alcuni
moduli specifici di Drozer, è possibile ad esempio richiedere la lista di tutte le
activity, esportate e non, di un’applicazione.
Content Provider È possibile raccogliere ulteriori informazioni sui Content
Provider; utilizzando il modulo ’app.provider.finduri’ vengono trovati alcuni URI
relativi ai Content Provider esportati ai quali possono fare accesso le altre app
installate sul device.
30Tecniche e strumenti di penetration
testing per Android Mobile apps
Services Per determinare quali sono nel dettaglio i servizi esportati si può
utilizzare ancora una volta il tool Drozer.
Il servizio esportato non richiede alcun permesso. Questo significa che qualun-
que app malevola installata sullo stesso dispositivo può accedere a quel servizio e
in particolare alla locazione del dispositivo.
Broadcast Receiver Ancora un volta, utilizzando Drozer è possibile ricavare la
lista dei broadcast receiver esportati di un app. Nell’applicazione in esame viene
esportato un broadcast che permette di inviare SMS.
Tutti questi componenti esportati formano di fatto la superficie di attacco del-
l’applicazione e sono potenziali punti di accesso per un utente malevolo. Verranno
successivamente sfruttati nella fase di Exploitation per accedere alle funzionalità
dell’applicazione tramite il client Drozer.
4.3.2 Reverse Engineering
Le applicazioni Android sono diffuse come file in formato ’.apk’ ; da essi è possibile
recuperare facilmente il codice sorgente utilizzando tecniche di reverse enginee-
ring. Questa vulnerabilità può essere sfruttata da un utente malevolo per analiz-
zare l’applicazione, determinare quali misure difensive siano state implementate e
per cercare quindi di bypassare tali meccanismi. Utilizzando lo strumento apktool
è possibile disassemblare il file APK per poi ispezionarlo. Tra gli altri file è sta-
to ricavato il file AndroidManifest.xml, essenziale per individuare altre eventuali
vulnerabilità.
31Tecniche e strumenti di penetration
testing per Android Mobile apps
Altra tecnica che può essere utilizzata per decompilare il file apk è convertirlo
in formato jar tramite il tool dex2jar. Dopo aver ricostruito il codice sorgente il
file jar può essere ispezionato con il tool JD-GUI .
4.4 Vulnerability Analysis
Di particolare rilevanza, tra i tools inclusi nel pacchetto Appie, è AndroBugs.
AndroBugs è un efficiente scanner di vulnerabilità per Android, implementato
completamente in linguaggio python, che aiuta i tester a trovare potenziali falle
di sicurezza nelle applicazioni.
32Tecniche e strumenti di penetration
testing per Android Mobile apps
Per l’applicazione in esame vengono rilevate molteplici vulnerabilità classificate
su diversi livelli di priorità tra cui: l’esistenza di componenti esportati (già rilevati
precedentemente tramite Drozer), l’utilizzo di intent impliciti, una verifica non
sicura dei certificati SSL, permessi per il sandboxing configurati scorrettamente,
abilitazione del debug mode, ecc.
4.5 Exploitation
Durante questa fase vengono sfruttate alcune delle vulnerabilità che sono state
rilevate nelle fasi precedenti.
4.5.1 Improper export of component
Durante la fase di ’Threat Modeling’ è stata ricavata una lista di tutti i componenti
che l’applicazione esporta e che possono essere lanciati da un altra applicazione
installata sul dispositivo. Ad esempio, si può aprire un’activity passando un intent
tramite Drozer senza disporre di particolari permessi e, in particolare, nell’esempio
mostrato, bypassare la procedura di autorizzazione.
Per quanto riguarda i Content Provider esportati, è possibile interrogare alcuni
degli URI trovati precedentemente.
33Tecniche e strumenti di penetration
testing per Android Mobile apps
Per accedere al primo è richiesto il permesso READ_KEYS ma per il secon-
do non è necessario alcun permesso. È possibile inoltre cambiare il valore della
password utilizzando il modulo ’app.provider.update’ di Drozer.
Sfruttando invece uno tra i servizi esportati, denominato ’Location Service’, si
potrà avere accesso alla geolocalizzazione del dispositivo.
Nelle precedenti fasi inoltre, era stato rilevato un broadcast receivere esporta-
to che permetteva di inviare un SMS. Ispezionando il sorgente dell’applicazione
con jd-gui si può ricavare la firma dell’intent da inviare per avviare il Broadcast
Receiver in questione.
34Tecniche e strumenti di penetration
testing per Android Mobile apps
4.5.2 Insecure data storage
Di default, i file creati da un’applicazione sono accessibili solo dalla stessa. Gli
sviluppatori, però spesso utilizzano i permessi MODE_WORLD_READABLE
e MODE_WORD_WRITEABLE per rendere questi file accessibili ad altre ap-
plicazioni. Ciò non limita in alcun modo un’applicazione malevola ad acceder-
vi. Nella directory ‘data/data/application’ di ogni applicazione c’è una cartella
‘shared_prefs’ e una cartella ‘database’. Con il comando ‘adb shell’ si apre una
shell remota sul dispositivo tramite la quale si può ispezionare il filesystem.
Il problema principale è che all’interno di queste cartelle sono archiviati nume-
rosi file world_readble che possono essere letti da qualsiasi app e da cui è possibile
ricavare dati sensibili come ad esempio le password.
4.5.3 Insufficient transport layer protection
Quasi tutte le applicazioni Android trasmettono dati ad un server con paradig-
ma Client-Server e nella maggior parte dei casi viene creato un canale sicuro per
impedire lo sniffing dei dati. Il non raggiungimento di questa proprietà potrebbe
comportare gravi conseguenze per la sicurezza dei dati. Si può mostrare la pre-
35Puoi anche leggere
