StrandHogg - Hijacking Android applications

Introduction

At the beginning of December, a "new" Android vulnerability gained prominence in the media specialized in Information Security. Named StrandHogg by the company responsible for the disclosure, this vulnerability exploits legitimate uses of the Android Framework for malicious purposes. This article aims to explain how attackers use the Framework for this attack, under what conditions it can be carried out and possible ways to prevent it.

AMS and Android Multi-tasking

Android applications are made up of four essential parts: Activities, Services, Broadcast Receivers and Content Providers. In this article we'll focus on Activities, which are every window, menu, prompt, notification that appears on the screen. The Android system allows for multiple applications to be active at the same time, so tasks have been created. When each application is launched, it creates its own task and its Activities are all stacked as they are activated. When you press the back button, the Activity at the top of the stack is removed and the previous one is shown to the user. The default behavior provided by Android is just to stack or remove Activities from this stack, but for some special cases, parameters have been created to customize Activities in order to provide new functionalities for applications and thus expand the ability to handle multiple tasks. These parameters include:

Launch Mode: Defines how the Activity should be launched by the Activity Manager, there are four options: standard, singleTask, singleInstance or singleTop.
Task Affinity: Defines the Activity's affinity for creating Tasks. For the Manager, different apps with the same affinity belong to the same task. By default, the affinity is defined by the package name of the root application, but can be changed to any string.
Allow Task Reparenting: Boolean value that defines whether the Activity can switch stacks during its execution if a task of the same affinity is launched.

Manipulating and hijacking tasks

Taking advantage of the Framework's lack of control over the attributes mentioned above, it is possible for an application to arbitrarily manipulate the task stack of other applications and carry out attacks on them, simply by knowing the name of the target application's Affinity and then manipulating the attributes according to the attack it wishes to carry out. There are two scenarios for exploiting this vulnerability. Each scenario depends on certain conditions, either for the applications (target or malware) or the user's actions, taking into account that the user would need to have a malicious application installed on their cell phone. In the first scenario, the malware controls the stack, so it has some privileges over the target application's Activities. Being in position 0 (or root) of the stack allows it to control instantiations of Activity class methods and even intercept Intents triggered or directed to stack activities. This scenario opens up the possibility of the following attacks:

Phishing: a fraud attack whose purpose is to extract sensitive information or credentials from a user by making them believe that the malware is a legitimate application.
Denial of Service: a denial of service attack occurs when the attacker makes a resource unavailable or inaccessible to the user.
Spyware: software whose purpose is to monitor activities on the device and steal information
The other scenario, although more limited, is just as critical as the first. In this case, the malware tricks the Activity Manager so that it interprets its Activities as belonging to an application, then when the application is started, the Manager reorganizes the activities by affinity, taking the malware to the victim stack.

Example 1 - spoofing

State 0: User homescreen
State 1 & 2: The user starts the malicious application posing as a legitimate application and then opens a second Activity (M2), which will be responsible for the attack, for which the following attributes have been defined:
TaskAffinity = "com.alvo.teste"
AllowTaskReparenting = True
State 3: The user starts the Target application which has launchMode set to Single Task, so when the Manager initializes its Task, it searches for the malware Activity which has the same affinity and places it on the application stack, so the user will see the Activity of the newly initialized application.

Example 2 - phishing

State 0: User has malware running in the background
State 1 & 2: The user is using a legitimate application that has a video in some Activity, so the Manager realizes that there are more than one video player, one of which will be targeted by the malware.
State 3: When the user selects the target player, it will run on top of the malware, due to the attributes:
TaskAffinity = "com.player.target"
LauchMode = singleTask
Thus, the malware will have control over this new Activity and at the end of the video when the user presses the back button it will return to the malware's Activities.

Prevention

In this scenario, where legitimate Framework functionalities are used for attacks, citing good Application development practices is irrelevant, since some scenarios are independent of the target's attributes in order to work. Ideally, some changes to the way these multi-tasking tools are made available to developers, such as limiting affinities, improving the Manager, signing affinities, are some examples of changes that would make these features more secure. However, no changes have been made so far, so it's up to the developer to think about how to prevent this type of attack. One way, which is not optimized, is to use some of Android's own functions that allow it to monitor which activities are in the application's stack and check them against a whitelist. If it detects any activity not foreseen in the code, the application can overwrite it with an activity alerting the user to a possible attack and which application may have been responsible. This solution, although functional, has some trade-offs: it requires more memory consumption, but not enough to impact the user experience; and it also requires the developer to predict as many cases as possible for the whitelist, so that there are no cases where legitimate applications are identified as malicious. It is therefore up to developers to weigh up the cost of this mitigation.

References

https://developer.android.com/guide/components/activities/tasks-and-back-stack
https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-ren-chuangang.pdf
https://promon.co/security-news/strandhogg/