19

The "Affinity" of Android tasks seems really complex to handle. The StrandHogg vulnerability uses tricks with "Affinity" to render itself inside an another app.

The information that I've found this far does not provide exact details of vulnerability but as far as I know there is not a technical vulnerability but a poorly designed API which allows for clever social engineering attacks.

Is there a real use case for the API behavior that StrandHogg uses?

If I have understood correctly, the API the vulnerability uses allow attacker to place its own Activity on the victim "Back stack". From reading the API description and the provided example cases the main intent of this API is to allow embedded activities from other apps to be displayed within your own task. However, the StrandHogg vulnerability seems to the other way around: using API to push your own activity over another task's "Back stack".

My best guess is that the attack uses the weird behavior described on page 100 of presentation called "Manipulating Android tasks and back stack" from year 2011. However, I cannot imagine any sensible use case for the behavior described.

Mikko Rantalainen
  • 513
  • 2
  • 11
  • 2
    That's a fantastic question and I'm sad I will have to wait two days to put a bounty on it. –  Dec 04 '19 at 06:57
  • 1
    The real question is why Google never chose to patch it. – Martin Fürholz Jun 30 '20 at 15:56
  • 1
    @MartinFürholz It could be that Google never chose to patch it, as apps can prevent such behavior by settings in the Android manifest, e.g., taskAffinity="" or launchMode="singleInstance"; when a related but different family of attacks got publicity in 2020 (called "Strandhogg2" by some), Google did release some patches in May 2020. – auspicious99 Jun 30 '20 at 16:21
  • If nobody can figure out a real use case for the behavior used by StrandHogg, it would be safer to just block it instead of expecting EVERY app vendor to fix it via manifest, right? – Mikko Rantalainen Jul 01 '20 at 08:31
  • 1
    @MikkoRantalainen I think the use case is actually really the vulnerability: that apps can use a 'shared' task stack. That's why Google chose to actively scan for malicious apps that exploit this, instead of removing the option altogether. – Martin Fürholz Jul 01 '20 at 22:28
  • (Also backwards-compatibility.) – Martin Fürholz Jul 01 '20 at 22:37
  • @MartinFürholz: I understand looking for this to figure out which apps are malicious. However, you could still detect when an app tries to use this, report the app and then IMMEDIATELY kill the app. – Mikko Rantalainen Jul 03 '20 at 09:56

1 Answers1

3

It's not just the victim "back stack". There are various possibilities. For example, let's say the victim app has not yet been launched. An attacker can place their activity in the background. Then when a user taps the icon of the victim app to start it, the "back stack" that the attacker's activity is lurking in could then come to the foreground and be treated as the victim's "back stack", just because of its declared task affinity.

From reading the API description and the provided example cases the main intent of this API is to allow embedded activities from other apps to be displayed within your own task. However, the StrandHogg vulnerability seems to the other way around: using API to push your own activity over another task's "Back stack".

Regarding this use case, think of it this way: activity A is the intended embedded activity, coming from application 1. Application 2 is the one that would like to incorporate activity A. With the StrandHogg feature, application 1 can launch activity A into application 2's back stack, thus allowing the user the experience of activity A as an embedded activity within application 2, even though it is coming from another app. One can imagine that a legitimate use case would have application 2 first communicating with application 1 to request the embedding of activity A, and then application 1 using the StrandHogg feature to do so.

We could argue, and rightly so, that this is not the best way to support this kind of embedding, as it could be abused for phishing attacks and other attacks, but that's another question.

auspicious99
  • 493
  • 3
  • 17
  • Yes, but the question was "why does Android have such a feature in the first place"? Is there any sensible user case for allowing any app to *push* its own activity within back stack of any other task? I understand many use cases for pulling other tasks activity within my own back stack but not the other way around. – Mikko Rantalainen Apr 06 '20 at 12:32
  • Oh, I see. Yes, good question. The earliest publication I'm aware of that exposed the possibility of such tricks with Task Affinity, was in 2015, and I heard that Google has been informed about it, but they still haven't "fixed" it, for some strange reason or other. – auspicious99 Apr 06 '20 at 14:49
  • Also see the presentation reference from year 2011 in the original question. The weird behavior has been known for nearly a decade and Google is still dragging their feet. Nobody seems to know the reason. As far as I can see, preventing the *push* would fix the StrandHogg vulnerability and no sensible use case would suffer. – Mikko Rantalainen Apr 07 '20 at 07:27
  • 1
    Modified the answer to address the question of a real use case. – auspicious99 Jun 02 '20 at 02:56