Pentesting di Applicazioni Android

Reading time: 39 minutes

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Nozioni di base sulle Applicazioni Android

Si raccomanda vivamente di iniziare leggendo questa pagina per conoscere le parti più importanti relative alla sicurezza di Android e i componenti più pericolosi in un'applicazione Android:

Android Applications Basics

ADB (Android Debug Bridge)

Questo è lo strumento principale necessario per connettersi a un dispositivo Android (emulato o fisico).
ADB permette di controllare i dispositivi sia via USB che via Network da un computer. Questa utility consente la copia di file in entrambe le direzioni, l'installazione e la disinstallazione di app, l'esecuzione di comandi shell, il backup dei dati, la lettura dei log, tra le altre funzioni.

Dai un'occhiata alla seguente lista di ADB Commands per imparare come usare adb.

Smali

A volte è interessante modificare il codice dell'applicazione per accedere a informazioni nascoste (per esempio password molto offuscate o flags). In tal caso, può essere utile decompilare l'apk, modificare il codice e ricompilarlo.
In this tutorial you can learn how to decompile and APK, modify Smali code and recompile the APK with the new functionality. Questo può essere molto utile come alternativa per diversi test durante l'analisi dinamica che verranno presentati. Quindi, tieni sempre presente questa possibilità.

Other interesting tricks

bash
adb shell pm list packages
com.android.insecurebankv2

adb shell pm path com.android.insecurebankv2
package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk

adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
  • Unisci tutti i splits e i base apks con APKEditor:
bash
mkdir splits
adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits
java -jar ../APKEditor.jar m -i splits/ -o merged.apk

# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed

Case Studies & Vulnerabilities

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Static Analysis

Prima di tutto, per analizzare un APK dovresti dare un'occhiata al codice Java usando un decompiler.
Please, read here to find information about different available decompilers.

Looking for interesting Info

Solo guardando le strings dell'APK puoi cercare password, URLs (https://github.com/ndelphit/apkurlgrep), api keys, encryption, bluetooth uuids, tokens e qualsiasi cosa interessante... cerca anche eventuali backdoors per code execution o backdoor di autenticazione (credenziali admin hardcoded nell'app).

Firebase

Presta particolare attenzione alle firebase URLs e verifica se sono configurate male. More information about whats is FIrebase and how to exploit it here.

Basic understanding of the application - Manifest.xml, strings.xml

L'esame dei file Manifest.xml e strings.xml di un'applicazione può rivelare potenziali vulnerabilità di sicurezza. Questi file possono essere accessi usando decompiler o rinominando l'estensione del file APK in .zip e poi scompattandolo.

Le Vulnerabilities identificate dal Manifest.xml includono:

  • Debuggable Applications: Applicazioni impostate come debuggable (debuggable="true") nel file Manifest.xml rappresentano un rischio poiché permettono connessioni che possono portare a sfruttamenti. Per capire come sfruttare applicazioni debuggable, fai riferimento a un tutorial su come trovare e sfruttare applicazioni debuggable su un dispositivo.
  • Backup Settings: L'attributo android:allowBackup="false" dovrebbe essere esplicitamente impostato per le applicazioni che trattano informazioni sensibili per prevenire backup non autorizzati dei dati tramite adb, specialmente quando usb debugging è abilitato.
  • Network Security: Le configurazioni di rete personalizzate (android:networkSecurityConfig="@xml/network_security_config") in res/xml/ possono specificare dettagli di sicurezza come certificate pins e impostazioni sul traffico HTTP. Un esempio è permettere traffico HTTP per domini specifici.
  • Exported Activities and Services: Identificare activity e service esportati nel manifest può evidenziare componenti che potrebbero essere abusati. Un'analisi più approfondita durante i test dinamici può rivelare come sfruttare questi componenti.
  • Content Providers and FileProviders: Content provider esposti potrebbero permettere accesso o modifiche non autorizzate ai dati. La configurazione dei FileProviders deve essere anch'essa scrutata.
  • Broadcast Receivers and URL Schemes: Questi componenti potrebbero essere sfruttati, prestando particolare attenzione a come gli URL schemes sono gestiti per eventuali vulnerabilità di input.
  • SDK Versions: Gli attributi minSdkVersion, targetSDKVersion, e maxSdkVersion indicano le versioni Android supportate, sottolineando l'importanza di non supportare versioni Android obsolete e vulnerabili per ragioni di sicurezza.

Dal file strings.xml si possono scoprire informazioni sensibili come API keys, custom schemas e altre note degli sviluppatori, evidenziando la necessità di una revisione accurata di queste risorse.

Tapjacking

Tapjacking è un attacco in cui un'applicazione malicious viene lanciata e si posiziona sopra un'app vittima. Una volta che oscura visivamente l'app vittima, la sua interfaccia utente è progettata in modo da ingannare l'utente a interagire con essa, mentre passa l'interazione all'app vittima.
Di fatto, sta cecando l'utente impedendogli di sapere che sta effettivamente eseguendo azioni sull'app vittima.

Find more information in:

Tapjacking

Task Hijacking

Un'activity con launchMode impostato a singleTask senza alcun taskAffinity definito è vulnerabile al Task Hijacking. Questo significa che un'applicazione può essere installata e, se lanciata prima dell'app reale, potrebbe hijackare il task dell'app reale (così l'utente interagirà con l'app malevola pensando di usare quella reale).

More info in:

Android Task Hijacking

Insecure data storage

Internal Storage

In Android, i file memorizzati in internal storage sono progettati per essere accessibili esclusivamente dall'app che li ha creati. Questa misura di sicurezza è applicata dal sistema operativo Android ed è generalmente adeguata per le esigenze di sicurezza della maggior parte delle applicazioni. Tuttavia, gli sviluppatori a volte utilizzano modalità come MODE_WORLD_READABLE e MODE_WORLD_WRITABLE per consentire che i file siano condivisi tra applicazioni diverse. Queste modalità però non limitano l'accesso a questi file da parte di altre applicazioni, incluse quelle potenzialmente malevole.

  1. Static Analysis:
  • Verifica che l'uso di MODE_WORLD_READABLE e MODE_WORLD_WRITABLE sia accuratamente esaminato. Queste modalità possono esporre i file ad accessi non intenzionati o non autorizzati.
  1. Dynamic Analysis:
  • Controlla i permessi impostati sui file creati dall'app. In particolare, verifica se qualche file è impostato come leggibile o scrivibile da tutti. Questo può rappresentare un rischio di sicurezza significativo, in quanto permetterebbe a qualsiasi applicazione installata sul dispositivo, indipendentemente dalla sua origine o intenzione, di leggere o modificare questi file.

External Storage

Quando si lavora con file su external storage, come le SD Card, si devono prendere alcune precauzioni:

  1. Accessibility:
  • I file su external storage sono globalmente leggibili e scrivibili. Ciò significa che qualsiasi applicazione o utente può accedere a questi file.
  1. Security Concerns:
  • Data la facile accessibilità, è consigliato non memorizzare informazioni sensibili su external storage.
  • L'external storage può essere rimosso o accessibile da qualsiasi applicazione, rendendolo meno sicuro.
  1. Handling Data from External Storage:
  • Esegui sempre la validazione dell'input sui dati recuperati dall'external storage. Questo è cruciale perché i dati provengono da una fonte non attendibile.
  • Sconsigliato memorizzare eseguibili o class files su external storage per caricamento dinamico.
  • Se la tua applicazione deve recuperare file eseguibili dall'external storage, assicurati che questi file siano signed e verificati crittograficamente prima del loro caricamento dinamico. Questo passaggio è vitale per mantenere l'integrità di sicurezza della tua applicazione.

External storage può essere accessed in /storage/emulated/0 , /sdcard , /mnt/sdcard

tip

A partire da Android 4.4 (API 17), la SD card ha una struttura di directory che limita l'accesso da parte di un'app alla directory specifica per quell'app. Questo previene che applicazioni malevole ottengano accesso in lettura o scrittura ai file di un'altra app.

Sensitive data stored in clear-text

  • Shared preferences: Android permette a ogni applicazione di salvare facilmente file xml nel percorso /data/data/<packagename>/shared_prefs/ e a volte è possibile trovare informazioni sensibili in clear-text in quella cartella.
  • Databases: Android permette a ogni applicazione di salvare facilmente database sqlite nel percorso /data/data/<packagename>/databases/ e a volte è possibile trovare informazioni sensibili in clear-text in quella cartella.

Broken TLS

Accept All Certificates

Per qualche motivo a volte gli sviluppatori accettano tutti i certificate anche se, per esempio, l'hostname non corrisponde, con righe di codice come la seguente:

java
SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

Un buon modo per testare questo è provare a catturare il traffico usando un proxy come Burp senza autorizzare la Burp CA all'interno del dispositivo. Inoltre, puoi generare con Burp un certificato per un hostname differente e usarlo.

Crittografia debole

Processi di gestione delle chiavi inadeguati

Alcuni sviluppatori salvano dati sensibili nell'archiviazione locale e li criptano con una chiave hardcoded/predictable nel codice. Questo non dovrebbe essere fatto, poiché un reversing potrebbe permettere agli attaccanti di estrarre le informazioni confidenziali.

Uso di algoritmi insicuri e/o deprecati

Gli sviluppatori non dovrebbero usare algoritmi deprecati per effettuare controlli di autorizzazione, memorizzare o inviare dati. Alcuni di questi algoritmi sono: RC4, MD4, MD5, SHA1... Se vengono usati hashes per memorizzare password, per esempio, dovrebbero essere usati hash resistenti al brute-force con salt.

Altri controlli

  • Si raccomanda di offuscare l'APK per rendere più difficile il lavoro di reverse engineer agli attaccanti.
  • Se l'app è sensibile (come le bank apps), dovrebbe eseguire i propri controlli per verificare se il mobile è rooted e agire di conseguenza.
  • Se l'app è sensibile (come le bank apps), dovrebbe verificare se è in uso un emulator.
  • Se l'app è sensibile (come le bank apps), dovrebbe verificare la propria integrità prima di eseguirla per controllare se è stata modificata.
  • Usa APKiD per verificare quale compiler/packer/obfuscator è stato usato per buildare l'APK

React Native Application

Leggi la pagina seguente per imparare come accedere facilmente al codice javascript delle applicazioni React:

React Native Application

Xamarin Applications

Leggi la pagina seguente per imparare come accedere facilmente al codice C# di applicazioni xamarin:

Xamarin Apps

Superpacked Applications

Secondo questo blog post superpacked è un algoritmo Meta che comprime il contenuto di un'applicazione in un singolo file. Il blog parla della possibilità di creare un'app che decomprima questo tipo di app... e di un modo più veloce che consiste nell'eseguire l'applicazione e raccogliere i file decompressi dal filesystem.

Automated Static Code Analysis

Lo strumento mariana-trench è in grado di trovare vulnerabilità scansionando il codice dell'applicazione. Questo strumento contiene una serie di known sources (che indicano allo strumento i punti in cui l'input è controllato dall'utente), sinks (che indicano allo strumento i punti pericolosi dove un input malizioso potrebbe causare danni) e regole. Queste regole indicano la combinazione di sources-sinks che segnala una vulnerabilità.

Con questa conoscenza, mariana-trench esaminerà il codice e troverà possibili vulnerabilità.

Segreti leaked

Un'applicazione può contenere segreti (API keys, passwords, hidden urls, subdomains...) al suo interno che potresti essere in grado di scoprire. Puoi usare uno strumento come https://github.com/dwisiswant0/apkleaks

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Altre funzioni interessanti

  • Code execution: Runtime.exec(), ProcessBuilder(), native code:system()
  • Send SMSs: sendTextMessage, sendMultipartTestMessage
  • Native functions dichiarate come native: public native, System.loadLibrary, System.load
  • Read this to learn how to reverse native functions
  • In-memory native code execution via JNI (downloaded shellcode → mmap/mprotect → call):

In Memory Jni Shellcode Execution

Other tricks

content:// protocol

Analisi dinamica

Prima di tutto, hai bisogno di un ambiente dove poter installare l'applicazione e tutto l'ambiente (Burp CA cert, Drozer e Frida principalmente). Pertanto, un dispositivo rooted (emulato o meno) è altamente raccomandato.

Analisi dinamica online

Puoi creare un account gratuito su: https://appetize.io/. Questa piattaforma ti permette di upload e execute APK, quindi è utile per vedere come si comporta un apk.

Puoi anche vedere i log della tua applicazione sul web e connetterti tramite adb.

Grazie alla connessione ADB puoi usare Drozer e Frida all'interno degli emulators.

Analisi dinamica locale

Usare un emulatore

  • Android Studio (Puoi creare dispositivi x86 e arm, e secondo questa le versioni x86 più recenti supportano le librerie ARM senza necessitare di un lento emulatore arm).
  • Impara a configurarlo in questa pagina:

AVD - Android Virtual Device

  • Genymotion (Versione gratuita: Personal Edition, è necessario creare un account. Si consiglia di scaricare la versione CON VirtualBox per evitare potenziali errori.)
  • Nox (Gratuito, ma non supporta Frida o Drozer).

tip

Quando crei un nuovo emulatore su qualsiasi piattaforma ricorda che più grande è lo schermo, più lento sarà l'emulatore. Quindi seleziona schermi piccoli se possibile.

Per installare google services (come AppStore) in Genymotion devi cliccare il pulsante evidenziato in rosso dell'immagine seguente:

Inoltre, nota che nella configurazione della Android VM in Genymotion puoi selezionare la Bridge Network mode (questo sarà utile se ti connetterai alla Android VM da una VM diversa con gli strumenti).

Usare un dispositivo fisico

Devi attivare le opzioni di debugging e sarebbe utile se potessi rootarlo:

  1. Settings.
  2. (Da Android 8.0) Seleziona System.
  3. Seleziona About phone.
  4. Premi Build number 7 volte.
  5. Torna indietro e troverai le Developer options.

Una volta installata l'applicazione, la prima cosa da fare è provarla e indagare cosa fa, come funziona e prendere confidenza con essa.
Suggerisco di eseguire questa analisi dinamica iniziale usando MobSF dynamic analysis + pidcat, così saremo in grado di capire come funziona l'applicazione mentre MobSF cattura molti dati interessanti che potrai rivedere in seguito.

Magisk/Zygisk quick notes (consigliato su dispositivi Pixel)

  • Patcha boot.img con l'app Magisk e flashalo via fastboot per ottenere systemless root
  • Abilita Zygisk + DenyList per nascondere il root; considera LSPosed/Shamiko quando è richiesto un nascondimento più forte
  • Mantieni il boot.img originale per recuperare dagli OTA; ripatchalo dopo ogni OTA
  • Per lo screen mirroring, usa scrcpy sull'host

Perdita di dati non intenzionale

Logging

Gli sviluppatori dovrebbero essere cauti nell'esporre pubblicamente le informazioni di debug, poiché ciò può portare a leaks di dati sensibili. Gli strumenti pidcat e adb logcat sono raccomandati per monitorare i log dell'applicazione per identificare e proteggere le informazioni sensibili. Pidcat è preferito per la sua facilità d'uso e leggibilità.

warning

Nota che da versioni successive ad Android 4.0, le applicazioni possono accedere solo ai propri log. Quindi le applicazioni non possono accedere ai log di altre app.
Comunque, è comunque raccomandato non loggare informazioni sensibili.

Copy/Paste Buffer Caching

Il framework clipboard-based di Android abilita la funzionalità copia-incolla nelle app, ma rappresenta un rischio poiché altre applicazioni possono accedere agli appunti, esponendo potenzialmente dati sensibili. È cruciale disabilitare copy/paste per le sezioni sensibili di un'applicazione, come i dettagli della carta di credito, per prevenire data leaks.

Crash Logs

Se un'applicazione crasha e salva log, questi log possono aiutare gli attackers, soprattutto quando l'app non può essere reverse-engineered. Per mitigare questo rischio, evita di loggare i crash, e se i log devono essere trasmessi in rete, assicurati che vengano inviati tramite un canale SSL per la sicurezza.

Come pentester, prova a dare un'occhiata a questi log.

Analytics Data Sent To 3rd Parties

Le applicazioni spesso integrano servizi come Google Adsense, che possono involontariamente leak sensitive data a causa di una implementazione scorretta da parte degli sviluppatori. Per identificare potenziali data leaks, è consigliabile intercettare il traffico dell'applicazione e verificare se informazioni sensibili vengono inviate a servizi di terze parti.

SQLite DBs

La maggior parte delle applicazioni userà internal SQLite databases per salvare informazioni. Durante il pentest dai un'occhiata alle databases create, ai nomi delle tables e delle columns e a tutti i data salvati perché potresti trovare sensitive information (che sarebbe una vulnerabilità).
I database dovrebbero essere localizzati in /data/data/the.package.name/databases come /data/data/com.mwr.example.sieve/databases

Se il database salva informazioni confidenziali ed è encrypted ma puoi find la password dentro l'applicazione, è comunque una vulnerability.

Enumera le tables usando .tables ed enumera le columns delle tables eseguendo .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

From Drozer Docs: Drozer allows you to assume the role of an Android app and interact with other apps. It can do anything that an installed application can do, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .
Drozer è uno strumento utile per exploit exported activities, exported services and Content Providers come imparerai nelle sezioni seguenti.

Exploiting exported Activities

Read this if you want to refresh what is an Android Activity.
Ricorda anche che il codice di un activity inizia nel metodo onCreate.

Authorisation bypass

Quando un Activity è exported puoi invocarne lo schermo da un'app esterna. Pertanto, se un activity con informazioni sensibili è exported potresti bypassare i meccanismi di authentication per accedervi.

Learn how to exploit exported activities with Drozer.

Puoi anche avviare un activity esportato da adb:

  • PackageName is com.example.demo
  • Exported ActivityName is com.example.test.MainActivity
bash
adb shell am start -n com.example.demo/com.example.test.MainActivity

NOTA: MobSF rileverà come dannoso l'uso di singleTask/singleInstance come android:launchMode in un'attività, ma a causa di this, apparentemente questo è pericoloso solo su versioni vecchie (API versions < 21).

tip

Nota che un authorisation bypass non è sempre una vulnerabilità; dipende da come funziona il bypass e quali informazioni vengono esposte.

Sensitive information leakage

Activities can also return results. Se riesci a trovare un'attività esportata e non protetta che chiama il metodo setResult e restituisce informazioni sensibili, c'è una sensitive information leakage.

Tapjacking

Se il Tapjacking non è prevenuto, potresti abusare dell'attività esportata per far eseguire all'utente azioni non previste. Per maggiori informazioni su cos'è il Tapjacking segui il link.

Exploiting Content Providers - Accessing and manipulating sensitive information

Leggi questo se vuoi rinfrescarti su cos'è un Content Provider.
I Content providers sono usati fondamentalmente per share data. Se un'app ha content providers disponibili potresti essere in grado di extract sensitive dati da essi. È anche interessante testare possibili SQL injections e Path Traversals poiché potrebbero essere vulnerabili.

Impara come sfruttare i Content Providers con Drozer.

Exploiting Services

Leggi questo se vuoi rinfrescarti su cos'è un Service.
Ricorda che le azioni di un Service iniziano nel metodo onStartCommand.

Un Service è fondamentalmente qualcosa che can receive data, la processa e returns (o non) una risposta. Quindi, se un'applicazione espone alcuni services dovresti check il code per capire cosa sta facendo e testarlo dynamically per estrarre info riservate, bypassare misure di autenticazione...
Impara come sfruttare i Service con Drozer.

Exploiting Broadcast Receivers

Leggi questo se vuoi rinfrescarti su cos'è un Broadcast Receiver.
Ricorda che le azioni di un Broadcast Receiver iniziano nel metodo onReceive.

Un broadcast receiver attenderà un tipo di messaggio. A seconda di come il receiver gestisce il messaggio potrebbe essere vulnerabile.
Impara come sfruttare i Broadcast Receivers con Drozer.

Exploiting Schemes / Deep links

Puoi cercare i deep links manualmente, usando strumenti come MobSF o script come questo.
Puoi open uno scheme dichiarato usando adb o un browser:

bash
adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]

Nota che puoi omettere il nome del package e il dispositivo mobile chiamerà automaticamente l'app che dovrebbe aprire quel link.

html
<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
<!-- fallback in your url you could try the intent url -->
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>

Codice eseguito

Per trovare il codice che verrà eseguito nell'App, vai all'activity chiamata dal deeplink e cerca la funzione onNewIntent.

Info sensibili

Ogni volta che trovi un deep link controlla che non riceva dati sensibili (come password) tramite parametri URL, perché qualsiasi altra applicazione potrebbe impersonare il deep link e rubare quei dati!

Parameters in path

Devi verificare anche se qualche deep link usa un parametro all'interno del path dell'URL come: https://api.example.com/v1/users/{username} , in quel caso puoi forzare un path traversal accedendo a qualcosa come: example://app/users?username=../../unwanted-endpoint%3fparam=value .
Nota che se trovi gli endpoint corretti dentro l'applicazione potresti essere in grado di causare un Open Redirect (se una parte del path è usata come domain name), account takeover (se puoi modificare dettagli degli utenti senza token CSRF e il vuln endpoint usa il metodo corretto) e qualsiasi altro vuln. Maggiori info a riguardo qui.

More examples

Un interessante bug bounty report sui link (/.well-known/assetlinks.json).

Transport Layer Inspection and Verification Failures

  • I certificati non sono sempre ispezionati correttamente dalle applicazioni Android. È comune che queste applicazioni ignorino gli avvisi e accettino certificati self-signed o, in alcuni casi, tornino a usare connessioni HTTP.
  • Le negoziazioni durante l'handshake SSL/TLS sono talvolta deboli, impiegando cipher suite insicure. Questa vulnerabilità rende la connessione suscettibile a attacchi man-in-the-middle (MITM), permettendo ad attacker di decriptare i dati.
  • Leakage of private information è un rischio quando le applicazioni si autenticano usando canali sicuri ma poi comunicano su canali non sicuri per altre transazioni. Questo approccio non protegge i dati sensibili, come cookie di sessione o dettagli utente, dall'intercettazione da parte di entità maligne.

Certificate Verification

Ci concentreremo sulla verifica dei certificati. L'integrità del certificato del server deve essere verificata per migliorare la sicurezza. Questo è cruciale perché configurazioni TLS insicure e la trasmissione di dati sensibili su canali non cifrati possono comportare rischi significativi. Per passaggi dettagliati su come verificare i certificati server e correggere vulnerabilità, questa risorsa fornisce indicazioni complete.

SSL Pinning

SSL Pinning è una misura di sicurezza in cui l'applicazione verifica il certificato del server confrontandolo con una copia nota memorizzata all'interno dell'app stessa. Questo metodo è essenziale per prevenire attacchi MITM. Implementare SSL Pinning è fortemente consigliato per applicazioni che gestiscono informazioni sensibili.

Traffic Inspection

Per ispezionare il traffico HTTP è necessario installare il certificato del proxy tool (es. Burp). Senza installare questo certificato, il traffico cifrato potrebbe non essere visibile tramite il proxy. Per una guida su come installare una CA custom, click here.

Le applicazioni targettate a API Level 24 and above richiedono modifiche alla Network Security Config per accettare il certificato CA del proxy. Questo passo è critico per ispezionare il traffico cifrato. Per istruzioni su come modificare la Network Security Config, refer to this tutorial.

Se viene usato Flutter devi seguire le istruzioni in questa pagina. Questo perché aggiungere semplicemente il certificato nello store non funzionerà, dato che Flutter ha la propria lista di CA valide.

Static detection of SSL/TLS pinning

Prima di tentare bypass runtime, mappa velocemente dove il pinning è applicato nell'APK. La scoperta statica ti aiuta a pianificare hook/patch e a concentrarti sui percorsi di codice corretti.

Tool: SSLPinDetect

  • Utility open-source di static-analysis che decompila l'APK in Smali (via apktool) e scansiona pattern regex curati di implementazioni di SSL/TLS pinning.
  • Riporta il file path esatto, il numero di riga e uno snippet di codice per ogni match.
  • Copre framework comuni e percorsi di codice custom: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init con custom TrustManagers/KeyManagers, e Network Security Config XML pins.

Install

  • Prereqs: Python >= 3.8, Java on PATH, apktool
bash
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt

Uso

bash
# Basic
python sslpindetect.py -f app.apk -a apktool.jar

# Verbose (timings + per-match path:line + snippet)
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v

Esempio di regole di pattern (JSON) Usa o estendi signatures per rilevare stili di pinning proprietari/custom. Puoi caricare il tuo JSON e scansionare su larga scala.

json
{
"OkHttp Certificate Pinning": [
"Lcom/squareup/okhttp/CertificatePinner;",
"Lokhttp3/CertificatePinner;",
"setCertificatePinner"
],
"TrustManager Override": [
"Ljavax/net/ssl/X509TrustManager;",
"checkServerTrusted"
]
}

Notes and tips

  • Scansione rapida su app grandi tramite multi-threading e memory-mapped I/O; regex pre-compilate riducono overhead e falsi positivi.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Tipici target di rilevamento da triage successivamente:
  • OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
  • Custom TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
  • Custom SSL contexts: SSLContext.getInstance + SSLContext.init with custom managers
  • Declarative pins in res/xml network security config and manifest references
  • Usa le posizioni corrispondenti per pianificare Frida hooks, patch statiche o revisioni di configurazione prima dei test dinamici.

Bypassing SSL Pinning

Quando SSL Pinning è implementato, diventa necessario bypassarlo per ispezionare il traffico HTTPS. Sono disponibili vari metodi per questo scopo:

Looking for Common Web Vulnerabilities

È importante cercare anche vulnerabilità web comuni all'interno dell'applicazione. Informazioni dettagliate su come identificarle e mitigarle esulano dal riassunto ma sono ampiamente trattate altrove.

Frida

Frida è un toolkit di instrumentazione dinamica per developer, reverse-engineers e security researchers.
Puoi accedere all'app in esecuzione e hookare metodi a runtime per modificare il comportamento, cambiare valori, estrarre valori, eseguire codice diverso...
Se vuoi pentest applicazioni Android devi sapere come usare Frida.

Anti-instrumentation & SSL pinning bypass workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Dump Memory - Fridump

Verifica se l'applicazione sta memorizzando informazioni sensibili nella memoria che non dovrebbe memorizzare, come password o mnemoniche.

Using Fridump3 you can dump the memory of the app with:

bash
# With PID
python3 fridump3.py -u <PID>

# With name
frida-ps -Uai
python3 fridump3.py -u "<Name>"

Questo eseguirà il dump della memoria nella cartella ./dump, e lì potrai usare grep con qualcosa del tipo:

bash
strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"

Dati sensibili in Keystore

Su Android il Keystore è il posto migliore per memorizzare dati sensibili, tuttavia, con privilegi sufficienti è ancora possibile accedervi. Poiché le applicazioni tendono a memorizzare qui sensitive data in clear text, i pentests dovrebbero verificarlo come root user oppure qualcuno con accesso fisico al dispositivo potrebbe riuscire a rubare questi dati.

Anche se un'app ha memorizzato dati nel keystore, i dati dovrebbero essere cifrati.

Per accedere ai dati all'interno del keystore puoi usare questo Frida script: https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js

bash
frida -U -f com.example.app -l frida-scripts/tracer-cipher.js

Fingerprint/Biometrics Bypass

Usando il seguente Frida script potrebbe essere possibile bypass fingerprint authentication che le applicazioni Android potrebbero eseguire per proteggere determinate aree sensibili:

bash
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>

Immagini in background

Quando metti un'applicazione in background, Android memorizza una snapshot of the application così quando viene riportata in foreground inizia a caricare l'immagine prima dell'app in modo che sembri che l'app sia stata caricata più rapidamente.

Tuttavia, se questa snapshot contiene informazioni sensibili, qualcuno con accesso alla snapshot potrebbe rubare quelle informazioni (nota che è necessario root per accedervi).

Gli snapshot sono solitamente memorizzati in: /data/system_ce/0/snapshots

Android fornisce un modo per impedire la cattura di screenshot impostando il parametro di layout FLAG_SECURE. Usando questo flag, i contenuti della finestra sono trattati come sicuri, impedendo che compaiano in screenshot o che vengano visualizzati su display non sicuri.

bash
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);

Android Application Analyzer

Questo strumento può aiutarti a gestire diversi strumenti durante l'analisi dinamica: https://github.com/NotSoSecure/android_application_analyzer

Intent Injection

Spesso gli sviluppatori creano componenti proxy come activities, services e broadcast receivers che gestiscono questi Intents e li passano a metodi come startActivity(...) o sendBroadcast(...), il che può essere rischioso.

Il pericolo consiste nel permettere ad attaccanti di attivare componenti dell'app non-exported o di accedere a content providers sensibili reindirizzando questi Intents. Un esempio notevole è il componente WebView che converte URL in oggetti Intent tramite Intent.parseUri(...) ed esegue poi tali Intent, potenzialmente portando a malicious Intent injections.

Punti essenziali

  • Intent Injection è simile al problema Open Redirect del web.
  • Gli exploit prevedono il passaggio di oggetti Intent come extras, che possono essere reindirizzati per eseguire operazioni non sicure.
  • Può esporre componenti non-exported e content providers agli attaccanti.
  • La conversione da URL a Intent di WebView può facilitare azioni non intenzionali.

Android Client Side Injections e altri

Probabilmente conosci questo tipo di vulnerabilità dal Web. Devi prestare particolare attenzione a queste vulnerabilità in un'app Android:

  • SQL Injection: Quando gestisci query dinamiche o Content-Providers, assicurati di usare query parametrizzate.
  • JavaScript Injection (XSS): Verifica che il supporto a JavaScript e ai Plugin sia disabilitato per qualsiasi WebView (disabilitato per default). More info here.
  • Local File Inclusion: Le WebViews dovrebbero avere l'accesso al file system disabilitato (abilitato per default) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies: In diversi casi, quando l'app Android termina la sessione, il cookie non viene revocato o potrebbe addirittura essere salvato su disco
  • Secure Flag in cookies

Analisi automatica

MobSF

Analisi statica

Valutazione delle vulnerabilità dell'applicazione tramite una comoda interfaccia web. È anche possibile eseguire analisi dinamiche (ma è necessario preparare l'ambiente).

bash
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Nota che MobSF può analizzare Android(apk), IOS(ipa) and Windows(apx) applications (Le applicazioni Windows devono essere analizzate da una copia di MobSF installata su un host Windows).
Inoltre, se crei un file ZIP con il codice sorgente di un'app Android o IOS (vai nella cartella root dell'applicazione, seleziona tutto e crea un file ZIP), sarà in grado di analizzarlo.

MobSF consente anche di fare il diff/Compare delle analisi e di integrare VirusTotal (dovrai impostare la tua API key in MobSF/settings.py e abilitarla: VT_ENABLED = TRUE VT_API_KEY = <Your API key> VT_UPLOAD = TRUE). Puoi anche impostare VT_UPLOAD su False, in tal caso l'hash sarà upload invece del file.

Assisted Dynamic analysis with MobSF

MobSF può anche essere molto utile per l'analisi dinamica su Android, ma in questo caso dovrai installare MobSF e genymotion sul tuo host (una VM o Docker non funzioneranno). Nota: è necessario avviare prima una VM in genymotion e poi MobSF.
Il MobSF dynamic analyser può:

  • Dump application data (URLs, log, clipboard, screenshot fatti da te, screenshot fatti da "Exported Activity Tester", email, database SQLite, file XML e altri file creati). Tutto questo viene fatto automaticamente eccetto per gli screenshot: devi premere quando vuoi uno screenshot oppure premere "Exported Activity Tester" per ottenere screenshot di tutte le attività esportate.
  • Catturare HTTPS traffic
  • Usare Frida per ottenere informazioni di runtime

Dalle versioni Android > 5, avvierà automaticamente Frida e imposterà le impostazioni proxy globali per catturare il traffico. Catturerà solo il traffico dell'applicazione testata.

Frida

Di default userà anche alcuni Frida Scripts per bypassare lo SSL pinning, il root detection e il debugger detection e per monitorare API interessanti.
MobSF può anche invocare attività esportate, catturarne gli screenshot e salvarli per il report.

Per avviare il testing dinamico premi il bottone verde: "Start Instrumentation". Premi "Frida Live Logs" per vedere i log generati dagli script Frida e "Live API Monitor" per vedere tutte le invocazioni ai metodi hookati, gli argomenti passati e i valori restituiti (questo apparirà dopo aver premuto "Start Instrumentation").
MobSF permette anche di caricare i propri Frida scripts (per inviare i risultati dei tuoi Frida scripts a MobSF usa la funzione send()). Ha anche diversi script pre-scritti che puoi caricare (puoi aggiungerne altri in MobSF/DynamicAnalyzer/tools/frida_scripts/others/), basta selezionarli, premere "Load" e poi "Start Instrumentation" (potrai vedere i log di quegli script dentro "Frida Live Logs").

Inoltre, hai alcune funzionalità ausiliarie di Frida:

  • Enumerate Loaded Classes: stamperà tutte le classi caricate
  • Capture Strings: stamperà tutte le stringhe catturate durante l'uso dell'applicazione (molto rumoroso)
  • Capture String Comparisons: può essere molto utile. Mostrerà le 2 stringhe confrontate e se il risultato è stato True o False.
  • Enumerate Class Methods: inserisci il nome della classe (es. "java.io.File") e stamperà tutti i metodi della classe.
  • Search Class Pattern: cerca le classi tramite pattern
  • Trace Class Methods: traccia un'intera classe (vedi input e output di tutti i metodi della classe). Ricorda che di default MobSF traccia diversi metodi interessanti delle Android API.

Una volta selezionato il modulo ausiliario che vuoi usare devi premere "Start Intrumentation" e vedrai tutti gli output in "Frida Live Logs".

Shell

MobSF fornisce anche una shell con alcuni comandi adb, comandi MobSF, e comuni comandi shell nella parte inferiore della pagina di analisi dinamica. Alcuni comandi interessanti:

bash
help
shell ls
activities
exported_activities
services
receivers

Strumenti HTTP

Quando il traffico http viene catturato puoi vedere una vista grezza del traffico catturato sul pulsante "HTTP(S) Traffic" in basso oppure una vista più gradevole nel pulsante verde "Start HTTPTools". Dalla seconda opzione, puoi send le captured requests a proxies come Burp o Owasp ZAP.
To do so, power on Burp --> turn off Intercept --> in MobSB HTTPTools select the request --> press "Send to Fuzzer" --> select the proxy address (http://127.0.0.1:8080\).

Once you finish the dynamic analysis with MobSF you can press on "Start Web API Fuzzer" to fuzz http requests an look for vulnerabilities.

tip

After performing a dynamic analysis with MobSF the proxy settings me be misconfigured and you won't be able to fix them from the GUI. You can fix the proxy settings by doing:

adb shell settings put global http_proxy :0

Analisi Dinamica Assistita con Inspeckage

You can get the tool from Inspeckage.
This tool with use some Hooks to let you know what is happening in the application while you perform a dynamic analysis.

Yaazhini

Questo è un ottimo tool per eseguire static analysis con una GUI

Qark

Questo tool è progettato per cercare diverse vulnerabilità legate alla sicurezza delle applicazioni Android, sia nel codice sorgente sia negli packaged APKs. Lo strumento è inoltre capace di creare un "Proof-of-Concept" deployable APK e ADB commands, per sfruttare alcune delle vulnerabilità trovate (Exposed activities, intents, tapjacking...). Come con Drozer, non è necessario eseguire il root del dispositivo di test.

bash
pip3 install --user qark  # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
qark --java path/to/parent/java/folder
qark --java path/to/specific/java/file.java

ReverseAPK

  • Mostra tutti i file estratti per un facile riferimento
  • Decompila automaticamente i file APK in formato Java e Smali
  • Analizza AndroidManifest.xml alla ricerca di vulnerabilità e comportamenti comuni
  • Analisi statica del codice sorgente per vulnerabilità e comportamenti comuni
  • Informazioni sul dispositivo
  • e altro
bash
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER è un'applicazione a riga di comando utilizzabile su Windows, MacOS X e Linux, che analizza i file .apk alla ricerca di vulnerabilità. Lo fa decomprimendo gli APK e applicando una serie di regole per rilevarle.

Tutte le regole sono centralizzate in un file rules.json, e ogni azienda o tester può creare le proprie regole per analizzare ciò di cui ha bisogno.

Scarica i binari più recenti dalla pagina di download

super-analyzer {apk_file}

StaCoAn

StaCoAn è uno strumento crossplatform che aiuta sviluppatori, bugbounty hunters e ethical hackers nello svolgimento di static code analysis su applicazioni mobili.

Il concetto è che trascini e rilasci il file della tua applicazione mobile (un .apk o .ipa file) sull'applicazione StaCoAn e questa genererà per te un report visivo e portatile. Puoi modificare le impostazioni e le wordlists per ottenere un'esperienza personalizzata.

Scarica latest release:

./stacoan

AndroBugs

AndroBugs Framework è un sistema di analisi delle vulnerabilità per Android che aiuta gli sviluppatori o hackers a trovare potenziali vulnerabilità di sicurezza nelle applicazioni Android.
Windows releases

python androbugs.py -f [APK file]
androbugs.exe -f [APK file]

Androwarn

Androwarn è uno strumento il cui scopo principale è rilevare e avvisare l'utente riguardo a potenziali comportamenti maligni sviluppati da un'applicazione Android.

La rilevazione viene eseguita tramite la static analysis del Dalvik bytecode dell'applicazione, rappresentato come Smali, utilizzando la libreria androguard.

Questo strumento cerca comportamenti comuni di applicazioni "malevole" come: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution...

python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3

MARA Framework

MARA è un framework per il Reverse engineering e l'Analisi delle applicazioni mobile. È uno strumento che mette insieme tool comunemente usati per il mobile application reverse engineering e l'analisi, per assistere nel testing delle applicazioni mobile contro le minacce OWASP mobile security. Il suo obiettivo è rendere questo compito più semplice e accessibile a sviluppatori di applicazioni mobile e professionisti della sicurezza.

Può:

Koodous

Utile per rilevare malware: https://koodous.com/

Obfuscating/Deobfuscating code

Nota che, a seconda del servizio e della configurazione che usi per offuscare il codice, i segreti possono risultare offuscati oppure no.

ProGuard

From Wikipedia: ProGuard is an open source command-line tool that shrinks, optimizes and obfuscates Java code. It is able to optimize bytecode as well as detect and remove unused instructions. ProGuard is free software and is distributed under the GNU General Public License, version 2.

ProGuard è distribuito come parte dell'Android SDK e viene eseguito durante la build dell'applicazione in release mode.

DexGuard

Trovi una guida passo-passo per deoffuscare l'apk in https://blog.lexfo.fr/dexguard.html

(Da quella guida) L'ultima volta che abbiamo controllato, la modalità di funzionamento di DexGuard era:

  • caricare una risorsa come InputStream;
  • passare il risultato a una classe che eredita da FilterInputStream per decrittarlo;
  • fare un po' di offuscamento inutile per far perdere qualche minuto a un reverser;
  • passare il risultato decrittato a ZipInputStream per ottenere un file DEX;
  • infine caricare il DEX risultante come Resource usando il metodo loadDex.

DeGuard

DeGuard inverte il processo di offuscamento eseguito dagli strumenti di offuscamento Android. Questo abilita numerose analisi di sicurezza, inclusa l'ispezione del codice e l'identificazione delle librerie.

Puoi caricare un APK offuscato sulla loro piattaforma.

[Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app

This is a LLM tool to find any potential security vulnerabilities in android apps and deobfuscate android app code. Uses Google's Gemini public API.

Simplify

It is a generic android deobfuscator. Simplify virtually executes an app to understand its behavior and then tries to optimize the code so it behaves identically but is easier for a human to understand. Each optimization type is simple and generic, so it doesn't matter what the specific type of obfuscation is used.

APKiD

APKiD gives you information about how an APK was made. It identifies many compilers, packers, obfuscators, and other weird stuff. It's PEiD for Android.

Manual

Read this tutorial to learn some tricks on how to reverse custom obfuscation

Labs

Androl4b

AndroL4b is an Android security virtual machine based on ubuntu-mate includes the collection of latest framework, tutorials and labs from different security geeks and researchers for reverse engineering and malware analysis.

Riferimenti

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks