Pentesting delle Applicazioni Android

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

Fondamenti delle Applicazioni Android

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

Android Applications Basics

ADB (Android Debug Bridge)

Questo è lo strumento principale 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 permette 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 Comandi ADB per imparare a usare adb.

Smali

A volte è utile modificare il codice dell’applicazione per accedere a informazioni nascoste (ad esempio password ben offuscate o flag). In questi casi può essere utile decompilare l’apk, modificare il codice e ricompilarlo.
In questo tutorial puoi imparare a decompilare un APK, modificare il codice Smali e ricompilare l’APK con la nuova funzionalità. Questo può essere molto utile come alternativa per diversi test durante l’analisi dinamica che verranno presentati. Quindi, tieni sempre a mente questa possibilità.

Altri trucchi interessanti

Acquisizione automatizzata di APK da più fonti (justapk)

pip install justapk (Python 3.11+). La CLI produce JSON su stdout e lo stato di avanzamento su stderr (pipe-friendly). Prova una catena di fallback deterministica attraverso APK20 → F-Droid → APKPure (mobile API) → APKMirror (HTML scrape) → Uptodown (mobile API) → APKCombo (HTML scrape). Le fonti protette da Cloudflare usano curl_cffi con imitazione del fingerprint TLS per imitare client reali e ridurre i blocchi dovuti al rilevamento dei bot.

justapk download <package>              # auto fallback
justapk download <package> -s apkpure   # pin a source / version / output dir
justapk search telegram
justapk info org.telegram.messenger
justapk convert app.xapk -o output/      # merges splits, re-signs with debug key

convert unisce XAPK/split APKs e le firma con una debug key, in modo che la APK signature/provenance risultante differisca dall’originale (usare per testing/analysis, non per production installs).

  • Estrai l’APK dal dispositivo:
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
  • Unire tutti gli splits e i base apks con APKEditor:
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

Tradecraft di malware Android (loaders, fileless DEX, persistence)

Staging nativo + fileless DEX loaders

Alcuni droppers Android incorporano una libreria nativa (lib*.so) che decripta e scrive un secondo ELF (es., l.so) in un percorso temporaneo, la carica via JNI, e poi carica la logica reale come DEX solo in memoria usando dalvik.system.InMemoryDexClassLoader. Questo riduce la visibilità statica del payload e evita di scrivere classes*.dex su disco.

Punti pratici per il triage:

  • Cerca librerie native che chiamano dlopen o System.loadLibrary molto presto, poi risolvono metodi Java tramite stringhe offuscate nello stack (es., decodificate XOR sullo stack).
  • Monitora la presenza di InMemoryDexClassLoader in log/stringhe o hook, il che indica l’esecuzione fileless DEX.

Hook Frida rapido per dumpare il buffer DEX in memoria:

Java.perform(() => {
const IM = Java.use('dalvik.system.InMemoryDexClassLoader');
IM.$init.overload('java.nio.ByteBuffer','java.lang.ClassLoader').implementation = function(buf, parent){
const arr = Java.array('byte', buf.array());
const fos = Java.use('java.io.FileOutputStream').$new("/sdcard/memdex.dex");
fos.write(arr); fos.close();
return this.$init(buf, parent);
};
});

Anti-analysis kill-switch

Packed loaders spesso si auto-terminano quando i controlli dell’emulatore o di analisi falliscono (es., la validazione CPU_ABI) chiamando:

android.os.Process.killProcess(android.os.Process.myPid());

Persistenza tramite foreground service + MediaPlayer loop

Un pattern leggero di persistenza è tenere in vita un foreground service con una pinned notification e riprodurre continuamente un loop audio quasi inaudibile tramite MediaPlayer. Questo mantiene il processo “attivo” e riduce le terminazioni dovute all’inattività del sistema operativo. Cerca l’uso di ForegroundService + MediaPlayer che loopa un asset piccolo (spesso pochi secondi).

Overlay di Accessibility + ACTION_SET_TEXT hijacking

Dopo che un utente concede Accessibility, banking trojans possono monitorare l’foreground app, mostrare un overlay realistico (spesso WebView HTML memorizzato come Base64) e sostituire i campi della transazione usando AccessibilityNodeInfo.ACTION_SET_TEXT. Questo permette la sostituzione silenziosa dell’indirizzo del destinatario mentre la vittima vede una UI plausibile.

Esempio minimale di sostituzione del testo:

Bundle args = new Bundle();
args.putCharSequence(AccessibilityNodeInfo.ACTION_ARGUMENT_SET_TEXT_CHARSEQUENCE,
"ATTACKER_USDT_ADDRESS");
node.performAction(AccessibilityNodeInfo.ACTION_SET_TEXT, args);

Infrastruttura push legittima come C2 gating

Invece di socket custom, alcuni malware usano Firebase Cloud Messaging (FCM) come canale C2. I messaggi FCM possono attivare controlli di telemetria (stato di carica, % batteria, temperatura, inattività dell’utente) e gate azioni come mining o fraud per stealth.

Staging di payload nativo cifrato con chiavi derivate dal nome file

I payload nativi possono essere distribuiti come blob ELF cifrati e decifrati con CipherInputStream(), usando una chiave derivata da SHA‑1 del filename scaricato. Ogni filename/version produce una chiave distinta, ostacolando il riuso statico degli IOC.

Jezail toolkit per Android con root per pentesting (REST API + web UI)

  • Funziona su un rooted device (Magisk/rootAVD) e avvia un HTTP server on tcp/8080 con una Flutter web UI e REST API.
  • Installa l’APK di release con i permessi: adb install -g -r jezail.apk, poi avvia l’app (il server si avvia automaticamente).
  • Endpoint: http://<device-ip>:8080/ (UI), http://<device-ip>:8080/api/json (API listing), http://<device-ip>:8080/api/swagger (Swagger).
  • Port-forward dell’emulatore per raggiungere UI/API dall’host: adb forward tcp:8080 tcp:8080 poi apri http://localhost:8080.

Android Enterprise & Work Profile Attacks

Android Enterprise Work Profile Bypass

Case Studies & Vulnerabilities

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Abusing Android Media Pipelines Image Parsers

Firmware Level Zygote Backdoor Libandroid Runtime

Analisi statica

Prima di tutto, per analizzare un APK dovresti dare un’occhiata al codice Java usando un decompiler.
Per favore, leggi qui per trovare informazioni sui diversi decompiler disponibili.

Cercare informazioni interessanti

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 backdoor di code execution o backdoor di autenticazione (credenziali admin hardcoded nell’app).

Firebase

Presta particolare attenzione alle firebase URLs e verifica se è mal configurato. Maggiori informazioni su cos’è Firebase e come sfruttarlo qui.

Comprensione di base dell’applicazione - 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 aperti tramite decompiler o rinominando l’estensione dell’APK in .zip e poi decomprimendolo.

Vulnerabilità identificate dal Manifest.xml includono:

  • Debuggable Applications: Le applicazioni impostate come debuggable (debuggable="true") nel file Manifest.xml rappresentano un rischio in quanto permettono connessioni che possono portare a exploitation. Per maggiori informazioni su come sfruttare applicazioni debuggable, consulta un tutorial su come trovare e sfruttare applicazioni debuggable su un dispositivo.
  • Backup Settings: L’attributo android:allowBackup="false" dovrebbe essere impostato esplicitamente per applicazioni che gestiscono informazioni sensibili per prevenire backup non autorizzati tramite adb, specialmente quando usb debugging è abilitato.
  • Network Security: Configurazioni di network security personalizzate (android:networkSecurityConfig="@xml/network_security_config") in res/xml/ possono specificare dettagli di sicurezza come certificate pins e impostazioni del traffico HTTP. Un esempio è permettere traffico HTTP per domini specifici.
  • Exported Activities and Services: Identificare le attività e i servizi esportati nel manifest può evidenziare componenti che potrebbero essere abusati. Ulteriori analisi durante il testing dinamico possono rivelare come sfruttare questi componenti.
  • Content Providers and FileProviders: Content provider esposti potrebbero permettere accessi o modifiche non autorizzate ai dati. Anche la configurazione dei FileProviders dovrebbe essere scrutinata.
  • Broadcast Receivers and URL Schemes: Questi componenti potrebbero essere sfruttati per attacchi, con particolare attenzione a come gli URL schemes sono gestiti per 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 motivi di sicurezza.

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

Tapjacking

Tapjacking è un attacco in cui una applicazione malevola viene lanciata e si posiziona sopra un’applicazione vittima. Una volta che oscura visibilmente l’app vittima, la sua interfaccia utente è progettata in modo da indurre l’utente a interagire con essa, mentre trasferisce l’interazione all’app vittima.
In pratica, sta accecando l’utente dal sapere che in realtà sta eseguendo azioni sull’app vittima.

Find more information in:

Tapjacking

Task Hijacking

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

More info in:

Android Task Hijacking

Archiviazione dati insicura

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 la condivisione di file tra diverse applicazioni. Queste modalità, però, non limitano l’accesso a questi file da parte di altre applicazioni, incluse quelle potenzialmente malevole.

  1. Static Analysis:
  • Verificare che l’uso di MODE_WORLD_READABLE e MODE_WORLD_WRITABLE sia accuratamente scrutinato. Queste modalità possono potenzialmente esporre i file a accessi non intenzionali o non autorizzati.
  1. Dynamic Analysis:
  • Controllare i permessi impostati sui file creati dall’app. In particolare, verificare se eventuali file sono impostati come leggibili o scrivibili worldwide. Ciò può rappresentare un rischio significativo per la sicurezza, poiché consentirebbe a qualsiasi application installata sul dispositivo, indipendentemente dalla sua origine o intento, di leggere o modificare questi file.

External Storage

Quando si gestiscono file su external storage, come SD Card, è necessario adottare alcune precauzioni:

  1. Accessibilità:
  • I file su external storage sono globalmente leggibili e scrivibili. Ciò significa che qualsiasi applicazione o utente può accedervi.
  1. Problemi di sicurezza:
  • Data la facile accessibilità, è sconsigliato memorizzare informazioni sensibili su external storage.
  • L’external storage può essere rimosso o accessibile da qualsiasi application, rendendolo meno sicuro.
  1. Gestione dei dati provenienti da external storage:
  • Eseguire sempre la validazione degli input sui dati recuperati da external storage. Questo è fondamentale perché i dati provengono da una fonte non attendibile.
  • È fortemente sconsigliato memorizzare eseguibili o file di class su external storage per il caricamento dinamico.
  • Se la tua applicazione deve recuperare file eseguibili da external storage, assicurati che questi file siano firmati e verificati criptograficamente prima del 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 un’app alla directory specifica per quell’app. Questo impedisce a applicazioni malevole di ottenere 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 talvolta è possibile trovare informazioni sensibili in chiaro in quella cartella.
  • Databases: Android permette a ogni applicazione di salvare facilmente database sqlite nel percorso /data/data/<packagename>/databases/ e talvolta è possibile trovare informazioni sensibili in chiaro in quella cartella.

Broken TLS

Accept All Certificates

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

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 sul dispositivo. Inoltre, puoi generare con Burp un certificato per un hostname diverso e usarlo.

Broken Cryptography

Processi di gestione delle chiavi inadeguati

Alcuni sviluppatori salvano dati sensibili nello storage locale e li criptano con una chiave hardcoded/prevedibile nel codice. Questo non dovrebbe essere fatto, poiché del reversing potrebbe permettere ad attaccanti di estrarre le informazioni riservate.

Use of Insecure and/or Deprecated Algorithms

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

Other checks

  • Si raccomanda di offuscare l’APK per rendere più difficile il lavoro di reverse engineering agli attaccanti.
  • Se l’app è sensibile (come le app bancarie), dovrebbe eseguire i propri controlli per verificare se il mobile è rooted e agire di conseguenza.
  • Se l’app è sensibile (come le app bancarie), dovrebbe verificare se viene usato un emulator.
  • Se l’app è sensibile (come le app bancarie), dovrebbe verificare la propria integrità prima di eseguirla per controllare se è stata modificata.
  • Use APKiD to check which compiler/packer/obfuscator was used to build the APK

React Native Application

Read the following page to learn how to easily access javascript code of React applications:

React Native Application

Xamarin Applications

Read the following page to learn how to easily access C# code of a xamarin applications:

Xamarin Apps

Superpacked Applications

According to this blog post superpacked is a Meta algorithm that compress the content of an application into a single file. The blog talks about the possibility of creating an app that decompress these kind of apps… and a faster way which involves to execute the application and gather the decompressed files from the filesystem.

Automated Static Code Analysis

Lo strumento mariana-trench è in grado di trovare vulnerabilities scansionando il code 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 in cui input malevoli potrebbero causare danni) e rules. Queste regole indicano la combinazione di sources-sinks che segnala una vulnerabilità.

Con queste informazioni, mariana-trench rivedrà il codice e troverà possibili vulnerabilità.

Secrets leaked

An application may contain secrets (API keys, passwords, hidden urls, subdomains…) inside of it that you might be able to discover. You could us a tool such as https://github.com/dwisiswant0/apkleaks

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Other interesting functions

  • Esecuzione di codice: Runtime.exec(), ProcessBuilder(), native code:system()
  • Invio SMS: sendTextMessage, sendMultipartTestMessage
  • Funzioni native 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 puoi installare l’applicazione e tutto l’ambiente (Burp CA cert, Drozer and Frida principalmente). Pertanto, un rooted device (emulato o no) è estremamente raccomandato.

Online Dynamic analysis

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

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

Grazie alla connessione ADB puoi usare Drozer e Frida all’interno degli emulatori.

Local Dynamic Analysis

Using an emulator

  • Android Studio (Puoi creare x86 e arm devices, e secondo this le ultime versioni x86 supportano librerie ARM senza bisogno di un lento emulatore ARM).
  • Learn to set it up in this page:

AVD - Android Virtual Device

  • Genymotion (Versione gratuita: Personal Edition, è necessario creare un account. Si raccomanda 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 sul pulsante evidenziato in rosso nell’immagine seguente:

Nota inoltre 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 differente con gli strumenti).

Use a physical device

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

  1. Settings.
  2. (FromAndroid 8.0) Select System.
  3. Select About phone.
  4. Press Build number 7 times.
  5. Go back and you will find the Developer options.

Una volta installata l’applicazione, la prima cosa da fare è provarla e investigare cosa fa, come funziona e prenderci confidenza.
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 (recommended on Pixel devices)

  • Patch boot.img with the Magisk app and flash via fastboot to get systemless root
  • Enable Zygisk + DenyList for root hiding; consider LSPosed/Shamiko when stronger hiding is required
  • Keep original boot.img to recover from OTA updates; re-patch after each OTA
  • For screen mirroring, use scrcpy on the host

Unintended Data Leakage

Logging

Gli sviluppatori dovrebbero fare attenzione a esporre informazioni di debugging pubblicamente, poiché può portare a leak di dati sensibili. Gli strumenti pidcat e adb logcat sono raccomandati per monitorare i log delle applicazioni per identificare e proteggere informazioni sensibili. Pidcat è preferito per la sua facilità d’uso e leggibilità.

Warning

Nota che da versioni più recenti di Android 4.0, le applicazioni sono in grado di accedere solo ai propri log. Quindi le applicazioni non possono accedere ai log di altre app.
Comunque, è ancora raccomandato di non loggare informazioni sensibili.

Copy/Paste Buffer Caching

Il framework basato su clipboard di Android abilita la funzionalità copia-incolla nelle app, ma comporta un rischio poiché altre applicazioni possono accedere alla clipboard, esponendo potenzialmente dati sensibili. È fondamentale disabilitare le funzioni di copia/incolla per sezioni sensibili dell’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 un attaccante, specialmente quando l’applicazione non può essere reverse-engineerata. Per mitigare questo rischio, evita di loggare durante i crash e se i log devono essere trasmessi tramite rete, assicurati che siano inviati via un canale SSL sicuro.

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 causare leak di dati sensibili a causa di implementazioni errate da parte degli sviluppatori. Per identificare possibili data leaks, è consigliabile intercettare il traffico dell’applicazione e controllare se informazioni sensibili vengono inviate a servizi di terze parti.

SQLite DBs

La maggior parte delle applicazioni userà database SQLite interni per salvare informazioni. Durante il pentest dai un’occhiata ai databases creati, ai nomi delle tables e delle columns e a tutti i dati salvati perché potresti trovare informazioni sensibili (che costituirebbero una vulnerabilità).
I database dovrebbero trovarsi in /data/data/the.package.name/databases come /data/data/com.mwr.example.sieve/databases

Se il database salva informazioni confidenziali ed è criptato ma puoi trovare la password dentro l’applicazione, è comunque una vulnerabilità.

Enumerare le tabelle usando .tables ed elencare le colonne delle tabelle con .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

From Drozer Docs: Drozer permette di assumere il ruolo di un’app Android e interagire con altre app. Può fare qualsiasi cosa che un’applicazione installata può fare, come utilizzare il meccanismo di Inter-Process Communication (IPC) di Android e interagire con il sistema operativo sottostante.
Drozer è uno strumento utile per sfruttare exported activities, exported services e Content Providers come imparerai nelle sezioni seguenti.

Exploiting exported Activities

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

Authorisation bypass

Quando un’Activity è esportata puoi invocare la sua schermata da un’app esterna. Pertanto, se un’activity con informazioni sensibili è esportata potresti bypassare i meccanismi di autenticazione per accedervi.

Learn how to exploit exported activities with Drozer.

Puoi anche avviare un’activity esportata da adb:

  • PackageName is com.example.demo
  • Exported ActivityName is com.example.test.MainActivity
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 nelle versioni più vecchie (versioni API < 21).

Tip

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

Sensitive information leakage

Le Activity possono anche restituire risultati. Se riesci a trovare un’attività esportata e non protetta che chiama il metodo setResult e restituisce informazioni sensibili, si verifica una sensitive information leakage.

Tapjacking

Se il tapjacking non è prevenuto, potresti abusare dell’attività esportata per far sì che l’utente esegua azioni inaspettate. Per maggiori info about what is Tapjacking follow the link.

Exploiting Content Providers - Accessing and manipulating sensitive information

Read this if you want to refresh what is a Content Provider.
Content providers sono fondamentalmente utilizzati per condividere dati. Se un’app ha content providers disponibili potresti essere in grado di estrarre dati sensibili da essi. È inoltre interessante testare possibili SQL injections e Path Traversals poiché potrebbero essere vulnerabili.

Learn how to exploit Content Providers with Drozer.

Exploiting Services

Read this if you want to refresh what is a Service.
Ricorda che le azioni di un Service iniziano nel metodo onStartCommand.

Un Service è fondamentalmente qualcosa che può ricevere dati, elaborarli e restituire (o meno) una risposta. Quindi, se un’applicazione esporta dei service dovresti controllare il codice per capire cosa fa e testarlo dinamicamente per estrarre info confidenziali, bypassare misure di autenticazione…
Learn how to exploit Services with Drozer.

Exploiting Broadcast Receivers

Read this if you want to refresh what is a 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.
Learn how to exploit Broadcast Receivers with Drozer.

Exploiting Schemes / Deep links

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

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 pacchetto e il dispositivo mobile chiamerà automaticamente l’app che dovrebbe aprire quel link.

<!-- 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.

Informazioni sensibili

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

Parametri nel percorso

Devi controllare anche se qualche deep link sta usando un parametro all’interno del percorso della URL come: https://api.example.com/v1/users/{username} , in tal 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 all’interno dell’applicazione potresti essere in grado di causare un Open Redirect (se parte del percorso è usata come nome di dominio), account takeover (se puoi modificare i dettagli degli utenti senza CSRF token e l’endpoint vuln usava il metodo corretto) e qualsiasi altra vuln. Maggiori info about this here.

Altri esempi

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

Ispezione del livello di trasporto e fallimenti di verifica

  • I certificati non vengono sempre ispezionati correttamente dalle applicazioni Android. È comune che queste applicazioni ignorino avvisi e accettino certificati self-signed o, in alcuni casi, tornino a usare connessioni HTTP.
  • Le negoziazioni durante lo handshake SSL/TLS sono talvolta deboli, impiegando cipher suite insicure. Questa vulnerabilità rende la connessione suscettibile ad attacchi man-in-the-middle (MITM), permettendo agli attaccanti di decrittare i dati.
  • Perdita di informazioni private è 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à malevole.

Verifica dei certificati

Ci concentreremo sulla verifica dei certificati. L’integrità del certificato del server deve essere verificata per aumentare la sicurezza. Questo è cruciale perché configurazioni TLS insicure e la trasmissione di dati sensibili su canali non cifrati possono rappresentare rischi significativi. Per passaggi dettagliati sulla verifica dei certificati server e la risoluzione delle vulnerabilità, this resource fornisce una guida completa.

SSL Pinning

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

Ispezione del traffico

Per ispezionare il traffico HTTP è necessario installare il certificato dello strumento proxy (es. Burp). Senza installare questo certificato, il traffico cifrato potrebbe non essere visibile attraverso il proxy. Per una guida sull’installazione di una CA custom, click here.

Le applicazioni che targettizzano API Level 24 and above richiedono modifiche al Network Security Config per accettare il certificato CA del proxy. Questo passaggio è critico per ispezionare il traffico cifrato. Per istruzioni sulla modifica del Network Security Config, refer to this tutorial.

Se viene usato Flutter devi seguire le istruzioni in this page. Questo perché, semplicemente aggiungendo il certificato nello store non funzionerà: Flutter ha la propria lista di CA valide.

Rilevamento statico di SSL/TLS pinning

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

Tool: SSLPinDetect

  • Open-source static-analysis utility che decompila l’APK in Smali (via apktool) e scansiona pattern regex curati di implementazioni di SSL/TLS pinning.
  • Riporta percorso file esatto, 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 with custom TrustManagers/KeyManagers, and Network Security Config XML pins.

Installazione

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

Uso

# 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

Esempi di regole pattern (JSON) Usa o estendi signatures per rilevare stili di pinning proprietari/custom. Puoi caricare il tuo JSON ed effettuare scan su larga scala.

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

Note e suggerimenti

  • Fast scanning on large apps via multi-threading and memory-mapped I/O; pre-compiled regex reduces overhead/false positives.
  • Raccolta pattern: https://github.com/aancw/smali-sslpin-patterns
  • Obiettivi tipici di rilevamento da valutare successivamente:
  • OkHttp: uso di CertificatePinner, setCertificatePinner, riferimenti ai package okhttp3/okhttp
  • TrustManager personalizzati: javax.net.ssl.X509TrustManager, override di checkServerTrusted
  • Contesti SSL personalizzati: SSLContext.getInstance + SSLContext.init con manager personalizzati
  • Pin dichiarativi in res/xml network security config e riferimenti nel manifest
  • Usa le posizioni corrispondenti per pianificare Frida hooks, patch statici, o revisioni di configurazione prima del testing dinamico.

Bypassare SSL Pinning

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

Ricerca di vulnerabilità web comuni

È importante cercare anche vulnerabilità web comuni all’interno dell’applicazione. Informazioni dettagliate su come identificarle e mitigarle sono fuori dallo scopo di questo sommario ma sono trattate estensivamente altrove.

Frida

Frida è un toolkit di instrumentazione dinamica per sviluppatori, reverse-engineer e ricercatori di sicurezza.
Puoi accedere all’applicazione in esecuzione e hookare i metodi a runtime per cambiare il comportamento, modificare valori, estrarre valori, eseguire codice diverso…
Se vuoi fare pentesting su applicazioni Android devi sapere come usare Frida.

Anti-instrumentation & workflow di bypass SSL pinning

Android Anti Instrumentation And Ssl Pinning Bypass

Dump Memory - Fridump

Controlla se l’applicazione sta memorizzando informazioni sensibili nella memoria che non dovrebbe, come password o mnemoniche.

Usando Fridump3 puoi eseguire un dump della memoria dell’app con:

# 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; lì puoi usare grep con un comando del tipo:

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 nel Keystore

In Android il Keystore è il posto migliore per memorizzare dati sensibili, tuttavia, con privilegi sufficienti è ancora possibile accedervi.

Poiché le applicazioni tendono a memorizzare qui dati sensibili in chiaro, i pentests dovrebbero verificarne la presenza, perché un utente root o qualcuno con accesso fisico al dispositivo potrebbe rubare questi dati.

Anche se un’app memorizza dati nel Keystore, tali dati dovrebbero essere crittografati.

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

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

Fingerprint/Biometrics Bypass

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

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 dell’applicazione così quando viene riportata in foreground inizia a caricare l’immagine prima dell’app vera e propria, in modo che sembri caricata più velocemente.

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

Le snapshot sono solitamente memorizzate in: /data/system_ce/0/snapshots

Android fornisce un modo per impedire la cattura di screenshot impostando il parametro di layout FLAG_SECURE. Utilizzando questa flag, il contenuto della finestra viene trattato come sicuro, impedendo che compaia negli screenshot o che venga visualizzato su display non sicuri.

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

Gli sviluppatori spesso 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 risiede nel permettere agli attackers di triggerare componenti non-exported dell’app o accedere a content providers sensibili reindirizzando questi Intents. Un esempio notevole è il componente WebView che converte URL in oggetti Intent tramite Intent.parseUri(...) e poi li esegue, potenzialmente portando a malicious Intent injections.

Punti essenziali

  • Intent Injection è simile al problema Open Redirect del web.
  • Gli exploit implicano 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 attackers.
  • La conversione da URL a Intent di WebView può facilitare azioni non intenzionali.

Android Client Side Injections and others

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

  • SQL Injection: Quando si gestiscono query dinamiche o Content-Providers assicurati di usare query parametrizzate.
  • JavaScript Injection (XSS): Verify that JavaScript and Plugin support is disabled for any WebViews (disabled by default). More info here.
  • Local File Inclusion: Le WebView dovrebbero avere l’accesso al file system disabilitato (abilitato di 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 può essere addirittura salvato su disco
  • Secure Flag in cookies

Analisi automatica

MobSF

Analisi statica

Vulnerability assessment of the application using a nice web-based frontend. You can also perform dynamic analysis (but you need to prepare the environment).

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 (Windows applications must be analyzed from a MobSF installed in a Windows host).
Inoltre, se crei un file ZIP con il codice sorgente di un’app Android o IOS (vai nella cartella radice dell’applicazione, seleziona tutto e crea un file ZIP), sarà in grado di analizzarlo anch’esso.

MobSF permette anche di fare 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 verrà uploadato l’hash invece del file.

Assisted Dynamic analysis with MobSF

MobSF può essere molto utile anche 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: Devi avviare prima una VM in genymotion e poi MobSF.
Il MobSF dynamic analyser può:

  • Dump application data (URLs, logs, 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 ad eccezione degli screenshot: devi premere quando vuoi uno screenshot oppure premere “Exported Activity Tester” per ottenere screenshot di tutte le attività esportate.
  • Catturare il traffico HTTPS
  • Usare Frida per ottenere informazioni a runtime

Per le versioni di Android > 5, avvierà automaticamente Frida e imposterà le impostazioni di proxy globali per catturare il traffico. Catturerà solo il traffico dall’applicazione testata.

Frida

Di default, userà anche alcuni Frida Scripts per bypassare SSL pinning, rilevamento root e rilevamento debugger e per monitorare API interessanti.
MobSF può anche invoke exported activities, catturare screenshots di esse e salvarle per il report.

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

Inoltre, hai alcune funzionalità ausiliarie di Frida:

  • Enumerate Loaded Classes: Stampa tutte le classi caricate
  • Capture Strings: Stampa 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 classi per pattern
  • Trace Class Methods: Trace un’intera classe (vedi input e output di tutti i metodi della classe). Ricorda che di default MobSF traccia diversi metodi delle Android Api considerati interessanti.

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, MobSF commands, e comuni shell commands in fondo alla pagina di analisi dinamica. Alcuni comandi interessanti:

help
shell ls
activities
exported_activities
services
receivers

HTTP tools

Quando il traffico HTTP viene catturato puoi vedere una visualizzazione grezza del traffico catturato sul pulsante “HTTP(S) Traffic” oppure una vista più gradevole nel pulsante verde “Start HTTPTools”. Dalla seconda opzione, puoi inviare le richieste catturate a proxies come Burp o Owasp ZAP.
Per farlo, avvia Burp –> disattiva Intercept –> in MobSB HTTPTools seleziona la richiesta –> premi “Send to Fuzzer” –> seleziona l’indirizzo del proxy (http://127.0.0.1:8080\).

Una volta terminata l’analisi dinamica con MobSF puoi premere “Start Web API Fuzzer” per fuzzare le richieste HTTP e cercare vulnerabilità.

Tip

Dopo aver eseguito un’analisi dinamica con MobSF le impostazioni del proxy potrebbero essere mal configurate e non potrai correggerle dall’interfaccia grafica. Puoi risolvere le impostazioni del proxy eseguendo:

adb shell settings put global http_proxy :0

Analisi Dinamica Assistita con Inspeckage

Puoi ottenere lo strumento da Inspeckage.
Questo strumento utilizza alcuni Hooks per informarti su cosa sta succedendo nell’applicazione mentre esegui un’analisi dinamica.

Yaazhini

Questo è un ottimo strumento per eseguire analisi statiche con una GUI

Qark

Questo strumento è progettato per cercare diverse vulnerabilità legate alla sicurezza nelle applicazioni Android, sia nel source code che nei packaged APKs. Lo strumento è anche 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 rootare il dispositivo di test.

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 facile consultazione
  • Decompila automaticamente i file APK nei formati Java e Smali
  • Analizza AndroidManifest.xml per vulnerabilità e comportamenti comuni
  • Analisi statica del codice sorgente per vulnerabilità e comportamenti comuni
  • Informazioni sul dispositivo
  • e altro
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER è un’applicazione da riga di comando utilizzabile su Windows, MacOS X e Linux, che analizza file .apk alla ricerca di vulnerabilità. Lo fa decomprimendo APKs e applicando una serie di regole per individuare tali vulnerabilità.

Tutte le regole sono contenute 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 download page

super-analyzer {apk_file}

StaCoAn

StaCoAn è uno strumento multipiattaforma che aiuta gli 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 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à Android che aiuta 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 obiettivo principale è rilevare e avvisare l’utente circa potenziali comportamenti dannosi sviluppati da un’applicazione Android.

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

Questo strumento cerca common behavior of “bad” applications 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 is a Mobile Application Reverse engineering and Analysis Framework. È uno strumento che mette insieme strumenti comunemente usati per il reverse engineering e l’analysis di mobile application, per assistere nel testing delle mobile application contro le minacce di sicurezza mobile di OWASP. Il suo obiettivo è rendere questo compito più semplice e più accessibile agli sviluppatori di mobile application e ai professionisti della sicurezza.

It is able to:

Koodous

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

Obfuscating/Deobfuscating code

Nota che, a seconda del servizio e della configurazione che usi per obfuscate il codice, i secrets potrebbero essere oppure no obfuscated.

ProGuard

From Wikipedia: ProGuard è uno strumento open source da riga di comando che riduce, ottimizza e obfuscates il codice Java. È in grado di ottimizzare il bytecode così come di rilevare e rimuovere istruzioni non utilizzate. ProGuard è software libero e viene distribuito sotto la GNU General Public License, versione 2.

ProGuard è distribuito come parte dell’Android SDK e viene eseguito quando si builda l’applicazione in modalità release.

DexGuard

Trovi una guida passo-passo per deobfuscate l’apk su 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 un InputStream;
  • passare il risultato a una classe che eredita da FilterInputStream per decriptarla;
  • eseguire alcune inutili operazioni di obfuscation per far perdere qualche minuto al reverser;
  • passare il risultato decriptato a un ZipInputStream per ottenere un file DEX;
  • infine caricare il DEX risultante come Resource usando il metodo loadDex.

DeGuard

DeGuard reverses the process of obfuscation performed by Android obfuscation tools. This enables numerous security analyses, including code inspection and predicting libraries.

Puoi caricare un APK obfuscated sulla loro piattaforma.

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

Questo è uno strumento LLM per trovare potenziali vulnerabilità di sicurezza nelle android apps e deobfuscate il codice delle android app. Usa la public API di Google Gemini.

Simplify

È un generic android deobfuscator. Simplify esegue virtualmente un’app per capirne il comportamento e poi prova a ottimizzare il codice in modo che si comporti in modo identico ma sia più facile da comprendere per un umano. Ogni tipo di ottimizzazione è semplice e generico, quindi non importa quale specifico tipo di obfuscation sia stato usato.

APKiD

APKiD fornisce informazioni su come è stato creato un APK. Identifica molti compilers, packers, obfuscators e altre cose strane. È il PEiD per Android.

Manual

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

Labs

Androl4b

AndroL4b è una virtual machine per Android security basata su ubuntu-mate che include una raccolta dei più recenti framework, tutorial e lab da diversi security geeks e researchers per reverse engineering e malware analysis.

References

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