While many of us salivate over the newly released Android Nougat for Nexus devices, the vast majority of users are still on Android Marshmallow. An exploit the existence of which has been documented since at least the middle of 2015 is still affecting many modern Android devices.
Malicious applications are able to tapjack your actions into granting them a permission you never explicitly granted. Here is how the exploit works.
The Return of Tapjacking
Imagine that you open up Instagram and try to share a picture you recently took while you were on vacation. When you select to browse your gallery for a picture, Instagram asks you to grant it permission to access your storage. But when you tap “yes” you are met with an error message.
You are unable to grant the storage permission for Instagram because you have an active screen overlay enabled – in this case, one of the many applications that tint your screen so can use your phone at night without blinding yourself. This is a case of the Android permissions system working as intended: in order to grant an application a sensitive permission, you are required to disable any screen overlays you have on your device.
Marshmallow Permission Tapjacking. Tapping “Allow” will show all of my contacts.
Applications that have the ability to draw over your screen could potentially trick you into feeding it sensitive data. For instance, a screen overlay could place a fake password input on top of a real login screen in order to collect your passwords. An exploit like this is called ‘tapjacking’ and has popped and been patched on various Android versions throughout the years, with one of the worst examples lasting until Android 4.0.3. But recently, the exploit made a return with Android Marshmallow’s run-time permission model.
A developer by the name of Iwo Banaś created an application demonstrating the exploit. The way it works is fairly simple – when an application displays a permission dialog, the malicious application you installed will display use a system overlay to cover up the permission dialog’s text with whatever it wants. An unwitting user who clicks “allow” on the dialog will be tricked into granting a permission that they were asked for – but for which the request was hidden was the user’s view. Such an exploit utterly defeats the purpose of Android Marshmallow’s permission system, since the introduction of the new model was supposed to ensure that users would only permissions that they explicitly consented to.
Now, I know what you’re thinking of. If Android detected a system overlay and prevented me from granting Instagram storage permissions, wouldn’t it prevent this exploit from happening? The answer is no, in my testing it appears that on certain devices displaying a text overlay on top of a permission dialog does not trigger the safety mechanism. The developer of the proof-of-concept tapjacking application states that the exploit is effective because it relies on the user installing a secondary malicious application that targets API level 22 and below (pre-Marshmallow). This is due to the fact that before Android Marshmallow, all applications are granted permissions during installation.
Okay, so if you’re on Marshmallow all you would need to do is avoid installing any apps you don’t trust that request the permission to draw an overlay, right? If Android’s permission model was working as originally laid out, you would be right. But since the discovery of this exploit, even apps targeting API level 23 (Marshmallow) that request the overlay permission are a potential risk.
A Gap in the Permission Model?
Typical Apps using Overlays. Via: Medium
If you’re one of the many millions of people who use Facebook Messenger for chatting with your friends, then you’ve come across one of Android’s best features – the ability for apps to draw on top of other screens. How cool is it that you can have a bubble with your favorite Facebook group chat follow the user on top of any application they open? Although Facebook’s Messenger brought the “floating apps” idea into the mainstream, the concept has existed for some time in Android. Applications have been able to create overlays on top of your apps for some time, thanks to the existence of TYPE_SYSTEM_OVERLAY in Android’s WindowManager.
“Draw over other apps” Permission Menu
Before Android Marshmallow, applications would need to request for a permission called SYSTEM_ALERT_WINDOW during installation before it could display overlays on top of your screen. But this changed with the introduction of 6.0’s granular run-time permission model. Users would now have to grant permissions to applications when actually running the app, which would hopefully spur the average user into safeguarding their own private data from applications that suspiciously request seemingly functionally unrelated permissions.
SYSTEM_ALERT_WINDOW is not like other permissions, however. Developers cannot display a dialog to programmatically request the permission be granted by the end-user, like most other permissions on any app targeting Marshmallow. Instead, you have to manually navigate to the settings screen and enable the permission yourself. Of course, some apps such as Facebook Messenger will help you along the process.
Google requires this of developers because they have deemed the permission to be “particularly sensitive.”
Special Permissions
There are a couple of permissions that don’t behave like normal and dangerous permissions. SYSTEM_ALERT_WINDOW and WRITE_SETTINGS are particularly sensitive, so most apps should not use them. If an app needs one of these permissions, it must declare the permission in the manifest, and send an intent requesting the user’s authorization. The system responds to the intent by showing a detailed management screen to the user.
Given what we know above about tapjacking, this makes sense. But here’s the thing. Google doesn’t even follow its own rules. The screenshots of Facebook Messenger guiding you through the process of granting it the SYSTEM_ALERT_WINDOW permission that I showed you above? That only happens if you install the APK from outside of the Google Play Store. If you install an application from the Google Play Store, the SYSTEM_ALERT_WINDOW permission is automatically granted.
Facebook Messenger’s Manifest File. The app is automatically granted the overlay permission despite targeting API level 23.
Google has Sacrificed Safety for Convenience
For a long time before Android Marshmallow, SYSTEM_ALERT_WINDOW was considered a “dangerous” permission. With Android Marshmallow 6.0, the permission was changed to signature|system|appop which is what initially required developers to lead the user to the settings screen to grant the permission. But with Android version 6.0.1, SYSTEM_ALERT_WINDOW was modified so that the Google Play Store could grant automatically the permission without notifying the user. Why Google made this change is unclear to us. Google themselves have not come out and stated why they made this change, which is especially odd considering the language about SYSTEM_ALERT_WINDOW that still exists on their webpages.
It’s possible that enough developers were angered by the initial changes to SYSTEM_ALERT_WINDOW that required users to manually grant the permission that Google silently caved and just granted it to any application that requested it. But in doing so, Google has sacrificed safety for convenience. There is a reason why Google themselves considered the permission to be dangerous for the longest time, because it is. And the existence of the Marshmallow permission tapjacking exploit is enough evidence of the inherent dangers in automatically granting this permission to any app.
This tapjacking exploit has only recently been brought to our attention although it has existed for many months now. In our internal testing of devices among the XDA Portal team, we have confirmed that the exploit works on many modern devices running Android Marshmallow. Here is a quick run-down of the devices we tested on the latest available software versions for each respective device and whether or not the tapjacking exploit works. The devices marked “Vulnerable” are susceptible to a tapjacking exploit, while the devices marked “Not Vulnerable” are able to detect an app displaying the overlay and request that you disable it before continuing.
- Nextbit Robin – Android 6.0.1 with June security patches – Vulnerable
- Moto X Pure – Android 6.0 with May security patches – Vulnerable
- Honor 8 – Android 6.0.1 with July security patches – Vulnerable
- Motorola G4 – Android 6.0.1 with May security patches – Vulnerable
- OnePlus 2 – Android 6.0.1 with June security patches – Not Vulnerable
- Samsung Galaxy Note 7 – Android 6.0.1 with July security patches – Not Vulnerable
- Google Nexus 6 – Android 6.0.1 with August security patches – Not Vulnerable
- Google Nexus 6P – Android 7.0 with August security patches – Not Vulnerable
So far, those are all of the devices I was able to get the team to test. I could not find any correlation between security patch version and the exploit. As you can tell from our latest discussion regarding Android security updates, many people are not running on the latest security patches anyway, and are thus possible vulnerable to this exploit and others that are outlined on the Android Security Bulletin.
Moving Forward
Tapjacking Service Granted the Overlay Permission
We urge you to test this exploit on your device for yourself to see if you are vulnerable. We have compiled the APKs from the source code linked above (you can do it yourself, too) and have uploaded them to AndroidFileHost. In order to test the exploit, you need to install both the main tapjacking application as well as its helper service. Then, simply run the main application and click on the “test” button. If a text box floats on top of the permission dialog and when you click “allow” a list of your device’s contacts shows up, then your device is vulnerable to tapjacking. Don’t worry about the floating text box not entirely covering the permission dialog, this proof-of-concept app is not intended to perfectly demonstrate how to neatly hijack a permissions dialog, but rather to prove that it is indeed possible.
We hope that a fix is introduced that patches this exploit on all Marshmallow devices, and that OEMs update all of their devices to the latest security patch. Because the reality is that it will take many months for most pledged devices to get Nougat, so the only way for most users to stay out of harm’s way is to either install the latest security patches or to take monitor app permissions themselves. But with Google’s decision to automatically grant the potentially dangerous SYSTEM_ALERT_WINDOW permission, many users are unknowingly running apps that could potentially hijack their phones to grant more and more dangerous permissions.
0 comments:
Post a Comment