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.

Improve this question
7
  • 2
    That's a fantastic question and I'm sad I will have to wait two days to put a bounty on it.
    – user163495
    Commented Dec 4, 2019 at 6:57
  • 1
    The real question is why Google never chose to patch it.
    – Martin Fürholz
    Commented Jun 30, 2020 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
    Commented Jun 30, 2020 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
    Commented Jul 1, 2020 at 8: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
    Commented Jul 1, 2020 at 22:28

1 Answer 1

Reset to default
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.

Improve this answer
4
  • 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
    Commented Apr 6, 2020 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
    Commented Apr 6, 2020 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
    Commented Apr 7, 2020 at 7:27
  • 2
    Modified the answer to address the question of a real use case.
    – auspicious99
    Commented Jun 2, 2020 at 2:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .