How Android’s UI Security is Undermined by Accessibility
An assessment of the threat level and protection capabilities against overlay and accessibility based attacks on Android.
Anatoli Kalysch, Davide Bove and Tilo Müller; System Security and Software Protection Group.
Android’s accessibility API was designed to assist users with disabilities, or preoccupied users unable to interact with a device, e.g.,
while driving a car. Nowadays, many Android apps rely on the accessibility API for other purposes, including password managers but also malware. From a security perspective, the accessibility API is precarious as it undermines an otherwise strong principle of sandboxing in Android that separates apps. By means of an accessibility service, apps can interact with the UI elements of another app, including reading from its screen and writing to its text fields.
As a consequence, design shortcomings in the accessibility API and other UI features such as overlays have grave security implications. We reveal flaws in the accessibility design of Android allowing information leakages and denial of service attacks against fully patched systems. With an enabled accessibility service, we are able to sniff sensitive data from apps, including the password of Android’s own lock screen. To evaluate the effectiveness of our attacks against third-party apps, we examined the 1100 most downloaded apps from Google Play and found 99.25 % of them to be vulnerable. Although app-level protection measures against these attacks can be implemented, e.g., to prevent information leakage through password fields, the number of affected apps proves that these kind of vulnerabilities must be tackled by Google rather than app developers.
From December 2017 to March 2018, we submitted seven bug reports to Google, from which three have been marked as “won’t fix” while four are progressed but ranked with either low severity or no security bulletin class. We conclude our paper with a list of best practices for app-level protections for the time those bugs remain unfixed by Google.
Materials
Published Paper: How Android’s UI Security is Undermined by Accessibility.
Code: Github Repository.
Quick Attack vs. Defenses Overview
The following table provides an overview of accessibility and overlay-based attacks presented in this paper and in previous work. A check mark ✓ signals a vulnerable Android OS version while the x mark ✗signals effective protection mechanisms by the OS. In addition to our own attacks we re-implemented and evaluated attacks from prior work for Android 8 and 8.1 which introduced new UI security mechanisms.
| Attack | Vulnerable Android Versions | Possible Countermeasures | ||||
|---|---|---|---|---|---|---|
| 6.0 | 7.0 | 7.1.2 | 8.0 | 8.1 | ||
| Accessibility Event Sniffing | ✗ | ✓ | ✓ | ✓ | ✓ | a11y event sanitizing, fingerprint authentication |
| Accessibility Screen Recording | ✓ | ✓ | ✓ | ✓ | ✓ | secure flag and in-app keyboard |
| Accessibility-enabled Malicious IME | ✓ | ✓ | ✓ | ✓ | ✓ | in-app keyboard and behavior listener |
| Accessibility-based Ad Hijacking [2] | ✓ | ✓ | ✓ | ✓ | ✓ | a11y event sanitizing |
| Overlay and Accessibility assisted Password Stealing [2] | ✓ | ✓ | ✓ | ✓ | ✓ | a11y event sanitizing, window punching |
| Keyboard App Hijacking [2] | (✓) | (✓) | (✓) | ✗ | ✗ | in-app keyboard or enforcing Gboard update |
| Full App Passthrough / Clickable Overlays [3] | ✓ | ✓ | ✓ | ✓* | ✓* | window punching |
| Partial App Clickable Overlays [1] | ✓ | ✓ | ✓ | ✓* | ✓* | window punching |
| Context-aware Clickjacking / Hiding [2] | ✓ | ✓ | ✓ | ✓* | ✓* | window punching |
| Keystroke Inference [2] | ✓ | ✓ | ✓ | ✗ | ✗ | in-app keyboard and window punching |
Accessibility focused attacks seem not affected by the most recent version of Android, resulting in an incredibly powerful tool for attackers. However, apps still have possibilities to counteract this attack vector on their own. Accessibility event sanitizing offers powerful capabilities because it allows to define custom behavior for events, e.g., clean accessibility events of any relevant information, which is helpful for credential fields, or even suppress accessibility events which can prevent accessibility-based ad hijacking. To counteract the overlay and accessibility assisted password stealing introduced by Fratantonio et al. window punching can be used against the overlays and accessibility event sanitizing can prevent the events and their AccessibilityNodeInfo objects of the login activity and its UI elements to be leaked to the malicious a11y service.
The Keyboard App Hijacking which used the accessibility flag FLAG_RETRIEVE_INTERACTIVE_WINDOWS was fixed for Android’s stock input method, the Gboard app. This also results in previous versions being secured as well, as long as they have updated the application.
For more detailed information see the corresponding paper or the PoCs in the github repository.
Sources
[1] Earlence Fernandes, Qi Alfred Chen, Justin Paupore, Georg Essl, J Alex Halderman, Z Morley Mao, and Atul Prakash. 2016. Android UI deception revisited: Attacks and defenses. In International Conference on Financial Cryptography and Data Security. Springer, 41–59.
[2] Yanick Fratantonio, Chenxiong Qian, Simon P Chung, and Wenke Lee. 2017. Cloak and Dagger: from two permissions to complete control of the UI feedback loop. In Security and Privacy (SP), 2017 IEEE Symposium on. IEEE, 1041–1057.
[3] Joshua Kraunelis, Yinjie Chen, Zhen Ling, Xinwen Fu, and Wei Zhao. 2013. On malware leveraging the Android accessibility framework. In International Conference on Mobile and Ubiquitous Systems: Computing, Networking, and Services. Springer, 512–523.