This is a follow up to our blog post during RSA, where we explained how a hacker, by combining two features of Android, Accessibility Services and the ability to draw over other apps, may gain control of the mobile device, including acquiring elevated privileges and exposing the content of all apps on the device. With this exploit, a hacker could persistently monitor all of a victim’s activity, and read and possibly compose corporate emails and documents via the victim’s device. This also enables ransomware exploits, where a hacker may elevate their permissions to remotely encrypt or wipe the device, potentially forcing the victim to pay money to get access to their own device.
Recall from the last post (click here to read it) that Android created Accessibility Services to provide user interface enhancements to help users interact with their device. The ability to draw over apps allows graphical overlays to programs that may allow touches to enact on the program below it, even if the overlay is not transparent. Combining these two features, a malicious hacker can trick a user into granting virtually unlimited permissions to their malware.
Android adds protection
Recognizing this potential, starting with Lollipop (5.x), Google added additional protection to the final “OK” button that would grant these accessibility permissions. In other words, Android programmers wanted to make sure that if a user was going to turn on Accessibility Services, the OK button could not be covered by an overlay, and the user would be sure to know what they are allowing.
I was in a hotel when it occurred to me that although the hotel door mostly blocked my view of the hallway outside, there was a peephole that was not blocking the view. This was my epiphany that led me to think that if there were a hole in the overlay, the OK button could be “mostly covered” and still accept a touch in the potentially very small area that was not covered, thereby bypassing the new protection and still hiding the true intent from the user. Elisha Eshed, back in the Skycure office (now Symantec Endpoint Protection Mobile), was quick to jump on this and verify that this method works on Lollipop devices, extending the attack surface of Accessibility Clickjacking to ALMOST ALL (98.8% at the time of discovery, 95.4% at the time of this post) active Android devices.
We will be covering additional details in an upcoming webinar on this topic. Register to attend here.
Accessibility Clickjacking Attack Video Example
In this short video of this exploit in practice, you can see that it only takes a small hole in the overlay to obscure the Accessibility Services screen and still bypass the current protection.
- The user is taken to accessibility settings.
- The user is prompted to navigate to the properties of the service we’re trying to enable.
- The user is prompted to enable the selected service.
- To make the user unknowingly approve the service’s permissions: He is tricked into clicking “the eye”, which is in fact the unobscured left part of the “OK” (approval) button.
To fully protect your device from an accessibility clickjacking attack, it is advised to use an updated version of Android, download only apps from trusted sources, such as the Google Play Store, and run an updated version of a Mobile Threat Defense solution.
Note that Marshmallow (6.x) takes an additional precaution against this type of attack by requiring the user to manually and specifically allow an app to create a system overlay by changing permissions in Settings -> Apps -> Draw over apps settings. So although Marshmallow may still be vulnerable by utilizing social engineering, it is more difficult to exploit.
Symantec Endpoint Protection Mobile takes pride in abiding by vendor’s responsible disclosure policy. Per that policy, we notified Google of this issue in March 2016. Following our correspondence with the Google Android Security team, they have decided not to fix this issue and accept this risk as a consequence of its current design. Due to the importance and widespread prevalence of Android, and after coordination with Google’s security team, we decided to publish this blog post and inform users of this security issue.
We would like thank the Google Security team for their quick response and ongoing commitment to the security of their users.