Sfruttare un'applicazione debuggabile

Reading time: 7 minutes

Evitare controlli di root e debuggabilità

Questa sezione del post è un riassunto del post https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0

Passaggi per rendere un'app Android debuggabile e bypassare i controlli

Rendere l'app debuggabile

Contenuto basato su https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0

1. Decompila l'APK:

• Utilizza lo strumento APK-GUI per decompilare l'APK.
• Nel file android-manifest, inserisci android:debuggable="true" per abilitare la modalità di debug.
• Ricompila, firma e zipaligna l'applicazione modificata.

2. Installa l'applicazione modificata:

• Usa il comando: adb install <application_name>.

3. Recupera il nome del pacchetto:

• Esegui adb shell pm list packages –3 per elencare le applicazioni di terze parti e trovare il nome del pacchetto.

4. Imposta l'app per attendere la connessione del debugger:

• Comando: adb shell am setup-debug-app –w <package_name>.
• Nota: Questo comando deve essere eseguito ogni volta prima di avviare l'applicazione per garantire che attenda il debugger.
• Per persistenza, usa adb shell am setup-debug-app –w ––persistent <package_name>.
• Per rimuovere tutti i flag, usa adb shell am clear-debug-app <package_name>.

5. Preparati per il debug in Android Studio:

• Naviga in Android Studio su File -> Open Profile or APK.
• Apri l'APK ricompilato.

6. Imposta i breakpoint nei file Java chiave:

• Posiziona i breakpoint in MainActivity.java (specificamente nel metodo onCreate), b.java e ContextWrapper.java.

Evitare controlli

L'applicazione, in determinati punti, verificherà se è debuggabile e controllerà anche i binari che indicano un dispositivo rootato. Il debugger può essere utilizzato per modificare le informazioni dell'app, disattivare il bit di debuggabilità e alterare i nomi dei binari cercati per bypassare questi controlli.

Per il controllo di debuggabilità:

1. Modifica le impostazioni del flag:

• Nella sezione variabili della console del debugger, naviga a: this mLoadedAPK -> mApplicationInfo -> flags = 814267974.
• Nota: La rappresentazione binaria di flags = 814267974 è 11000011100111011110, indicando che il "Flag_debuggable" è attivo.

Questi passaggi garantiscono collettivamente che l'applicazione possa essere debuggata e che alcuni controlli di sicurezza possano essere bypassati utilizzando il debugger, facilitando un'analisi o una modifica più approfondita del comportamento dell'applicazione.

Il passaggio 2 comporta la modifica di un valore di flag a 814267972, che è rappresentato in binario come 110000101101000000100010100.

Sfruttare una vulnerabilità

È stata fornita una dimostrazione utilizzando un'app vulnerabile contenente un pulsante e un textview. Inizialmente, l'applicazione visualizza "Crack Me". L'obiettivo è modificare il messaggio da "Try Again" a "Hacked" durante l'esecuzione, senza modificare il codice sorgente.

Controllo della vulnerabilità

• L'applicazione è stata decompilata utilizzando apktool per accedere al file AndroidManifest.xml.
• La presenza di android_debuggable="true" nel AndroidManifest.xml indica che l'applicazione è debuggabile e suscettibile di sfruttamento.
• Vale la pena notare che apktool è impiegato esclusivamente per controllare lo stato di debuggabilità senza alterare alcun codice.

Preparazione dell'impostazione

• Il processo ha comportato l'avvio di un emulatore, l'installazione dell'app vulnerabile e l'uso di adb jdwp per identificare le porte Dalvik VM che sono in ascolto.
• Il JDWP (Java Debug Wire Protocol) consente il debug di un'applicazione in esecuzione in una VM esponendo una porta unica.
• Il port forwarding è stato necessario per il debug remoto, seguito dall'attacco di JDB all'applicazione target.

Iniezione di codice durante l'esecuzione

• Lo sfruttamento è stato effettuato impostando breakpoint e controllando il flusso dell'applicazione.
• Comandi come classes e methods <class_name> sono stati utilizzati per scoprire la struttura dell'applicazione.
• È stato impostato un breakpoint nel metodo onClick, e la sua esecuzione è stata controllata.
• I comandi locals, next e set sono stati utilizzati per ispezionare e modificare le variabili locali, in particolare cambiando il messaggio "Try Again" in "Hacked".
• Il codice modificato è stato eseguito utilizzando il comando run, alterando con successo l'output dell'applicazione in tempo reale.

Questo esempio ha dimostrato come il comportamento di un'applicazione debuggabile possa essere manipolato, evidenziando il potenziale per sfruttamenti più complessi come ottenere accesso shell sul dispositivo nel contesto dell'applicazione.

2024 – Trasformare qualsiasi applicazione in un processo debuggabile (CVE-2024-31317)

Anche se l'APK target non è fornito con il flag android:debuggable, ricerche recenti hanno dimostrato che è possibile forzare applicazioni arbitrarie a partire con il flag di runtime DEBUG_ENABLE_JDWP abusando del modo in cui Zygote analizza gli argomenti della riga di comando.

• Vulnerabilità: Validazione impropria di --runtime-flags forniti attraverso il socket di comando di Zygote consente a un attaccante che può raggiungere system_server (ad esempio tramite la shell privilegiata adb che possiede il permesso WRITE_SECURE_SETTINGS) di iniettare parametri extra. Quando il comando creato viene riprodotto da system_server, l'app vittima viene forkata come debuggable e con un thread JDWP in ascolto. Il problema è tracciato come CVE-2024-31317 ed è stato risolto nel bollettino di sicurezza Android di giugno 2024.
• Impatto: Accesso completo in lettura/scrittura alla directory dei dati privati di qualsiasi app (inclusi quelli privilegiati come com.android.settings), furto di token, bypass MDM e, in molti casi, un percorso diretto per l'escalation dei privilegi abusando degli endpoint IPC esportati del processo ora debuggabile.
• Versioni interessate: Android 9 fino a 14 prima del livello di patch di giugno 2024.

PoC rapida

# Requires: adb shell (device must be <2024-06-01 patch-level)
# 1. Inject a fake API-denylist exemption that carries the malicious Zygote flag
adb shell settings put global hidden_api_blacklist_exemptions "--runtime-flags=0x104|Lcom/example/Fake;->entryPoint:"

# 2. Launch the target app – it will be forked with DEBUG_ENABLE_JDWP
adb shell monkey -p com.victim.bank 1

# 3. Enumerate JDWP PIDs and attach with jdb / Android-Studio
adb jdwp               # obtain the PID
adb forward tcp:8700 jdwp:<pid>
jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8700

Il valore creato nel passo 1 interrompe il parser dal “fast-path” e aggiunge un secondo comando sintetico dove --runtime-flags=0x104 (DEBUG_ENABLE_JDWP | DEBUG_JNI_DEBUGGABLE) è accettato come se fosse stato fornito dal framework. Una volta che l'app è avviata, viene aperto un socket JDWP e trucchi di debug dinamico regolari (sostituzione di metodi, patching di variabili, iniezione live di Frida, ecc.) sono possibili senza modificare l'APK o l'immagine di avvio del dispositivo.

Rilevamento e Mitigazione

• Applicare la patch al livello di sicurezza 2024-06-01 (o successivo) – Google ha indurito ZygoteCommandBuffer in modo che i comandi successivi non possano essere contrabbandati in questo modo.
• Limitare l'accesso a WRITE_SECURE_SETTINGS / shell sui dispositivi di produzione. Lo sfruttamento richiede questo permesso, che normalmente è detenuto solo da app ADB o privilegiate OEM.
• Su flotte gestite da EMM/MDM, applicare ro.debuggable=0 e negare l'accesso shell tramite adb disable-verifier.

Riferimenti

• https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0
• https://resources.infosecinstitute.com/android-hacking-security-part-6-exploiting-debuggable-android-applications
• https://rtx.meta.security/exploitation/2024/06/03/Android-Zygote-injection.html
• https://blog.flanker017.me/cve-2024-31317/