10-19, 10:40–11:20 (Europe/Luxembourg), Salle Europe
Both Android and iOS operating systems interact with the users using a constrained graphical interface, typically occupied at its majority by one application at a time while many of them can run in the background. That being said, a user must rely on the GUI provided by the application itself to verify its legitimacy. This type of behavior has raised concerns within the security research community that have been proved to be well founded, judging from the fact that multiple malware campaigns use GUI confusion as their main attack vector.
In this paper we present a novel GUI attack that leverages the fact that an Android activity maintains its graphical state and can receive touches, while it's in the top of the back stack of the device home screen. Whilst most of the techniques that have been introduced so far require the SYSTEM_ALERT_WINDOW permission, the one we present is permissionless and makes use only of the FLAG_NOT_TOUCH_MODAL flag.
By using this technique, we were able to create overlapping views over system dialogues, luring the user to unintentionally approve dangerous permissions and access to system services. Third party applications are also at risk, as it is possible to garble their UI by projecting fraudulent views that ostensibly belong to the targeted application's context. For the latter to be successful, the PACKAGE_USAGE_STATS permission must be obtained in order to identify the application that is currently in the foreground.
Google addressed the issue (CVE-2021-39617) by not dispatching touches to critical decision windows which are fully or partially obscured, but 3rd party applications are still affected.
Brief Outline:
- The Android User Interface
- GUI Confusion Attacks: The story so far
- A behavior so far unnoticed
- Attacking System Dialogs
- Attacking 3rd party applications
- Defense and Takeaways
Detailed Outline:
- The presentation starts with an overview of the Android User Interface, focusing on the components that are relative to the attack that I am going to describe.
- Then I am going to present a brief overview of the GUI Confusion techniques so far, and their mass scale usage as an attack vector from many modern malware campaigns. The objective is to give context to the audience about these attacks as well as to underline their impact and why they should not be underestimated.
- The next (main) section describes the Android's back stack and focuses on the following behavior:
-- When a new activity is pushed on the top of the stack, the overlapped one maintains its graphical state as well as the ability to receive touches from the user. The same behavior applies to system dialogues and system menus that are used to enable or disable special permissions.
-- When a transparent activity is pushed on the top of the stack it literally integrates the GUI of the one that was pushed lower. This creates the illusion that the overlapped activity is the one in the foreground.
- An Android application can create a transparent activity and apply to its window one or a combination of many flags that are defined in the android.view.WindowManager.LayoutParams class.
- These flags can be used to define how a view reacts to user taps and choose to consume or dispatch them to an underlying view.
- In the next section I am going to describe my GUI confusion technique which leverages the behavior described in the previous section.
I first classify my targets as "Single-Step" (SS) and "Multi-Step" (MS) decision makers, where in the first class belong the dialogs where a single tap suffices to determine a critical permission approval. For the second class the user must be guided to a particular component of a particular screen to approve or decline a special permission (e.g., draw on top of other apps).
SS dialogs (like the ones that belong to Contacts/Camera/Call-Logs etc. permission controllers) can be overlapped using a single specially crafted activity.
For MS dialogs I use a trampoline Activity which reforms itself according to a step indexing.
In both cases a tap is dispatched to the underlying view as long as the overlapping window carries the FLAG_NOT_TOUCH_MODAL flag. The taps can be tracked without implementing any special technique, since a single tap moves the activity to the PAUSE state. This event can't be interpreted as a signal to:
-- End the activity for SS dialogs
-- Respawn a reformed activity for MS dialogs
-- Hijack the user interaction for 3rd party applications
- Finally, I demonstrate how from zero permissions my application gets dangerous and/or special permissions approved.
- In the next section I demonstrate how to attack 3rd party Applications using only the PACKAGE_USAGE_STATS permission in order to track the activity that is currently in the foreground. The difference with similar "App Switch" attacks is that the overlay integrates the GUI of the victim app regardless of the activity that is currently active. As a show case I demonstrate an approval to a fraudulent bank transaction which without my attack would be rejected by the user.
- In the last core section, I describe how to defend Android applications from this attack since, even though Google provided a fix for system dialogs, 3rd party applications are still vulnerable.
- Wrapping up and key takeaways.
A cybersecurity professional with expertise in mobile, web, and network penetration testing. Dimitrios holds a degree in Computer Science, majoring in Cryptography and Security, and has worked with top companies like Microsoft and Google. He is frequent speaker at prominent security conferences such as BlackHat, Nullcon, Insomni'hack, and Troopers. He is passionate about reverse engineering and was a member of one of Greece's first reverse engineering research groups.