A malicious app with specific permissions can stealthily compromise users’ Android devices, researchers said.
“The possible attacks include advanced clickjacking, unconstrained keystroke recording, stealthy phishing, the silent installation of a God-mode app (with all permissions enabled), and silent phone unlocking + arbitrary actions (while keeping the screen off),” said researchers from Georgia Tech and the University of California, Santa Barbara.
The attack vector – called “Cloak and dagger” – doesn’t take advantage of bugs, but of several design shortcomings of the Android platform.
It affects all version of the popular mobile OS, including the latest, v7.1.2, aka Android Nougat.
“These attacks abuse one or both of the SYSTEM_ALERT_WINDOW (‘draw on top’) and BIND_ACCESSIBILITY_SERVICE (‘a11y’) [permissions],” the researchers said.
“If the malicious app is installed from the Play Store, the user is not notified about the permissions and she does not need to explicitly grant them for the attacks to succeed,” researchers said in a post. “In fact, in this scenario, ‘draw on top’ is automatically granted, and this permission is enough to lure the user into unknowingly enable a11y (through clickjacking).”
The researchers had no trouble placing such an app on Google Play.
“We submitted an app requiring these two permissions and containing a non-obfuscated functionality to download and execute arbitrary code (attempting to simulate a clearly-malicious behavior): This app got approved after just a few hours (and it is still available on the Google Play Store),” they said.
Google has been informed of this research, and of the security issues that can arise due to these design decisions. According to the responsible disclosure timeline presented by the researchers, the company won’t be fixing the “a11y” issue as they consider the feature to be working as intended, and has not followed up with a status update on the other issues.
Disclosure to Google
Researchers said they responsibly disclosed their findings to Google’s Android security team. A timeline of the disclosure steps and responses from Google are posted here (we will keep this updated as time passes):
• August 22nd, 2016 — We opened several issues on the bug tracker for the Android Open Source Project (AOSP).
• August 31st, 2016 — Android security team sets severity as “Moderate” for one of the bugs (“draw on top” → unconstrained keystroke recording).
• September 30th, 2016 — Android security team marks one of the reported bugs (“a11y” → unconstrained keystroke recording + leaking security PIN + unlocking device while keeping the screen off) as “work as intended”.
• October 10th, 2016 — We follow up pointing out that the Accessibility Service’s documentation states that a11y should not be able to access passwords (see “security note”), and that a11y should not be able to unlock the device and perform arbitrary actions while keeping the screen off.
• October 13th, 2016 — Android security team states that “The password will be repeated if the user explicitly turns that on in settings under Settings → Accessibility → Speak passwords. The option is off by default. If the user explicitly enables this feature, it is not a security vulnerability.”
• October 14th, 2016 — We follow up clarifying that our attack works even without this feature (In fact, our report does not even mention that.)
• October 18th, 2016 — Android security team marks this bug as “High severity”.
• November 28th, 2016 — Android security team downgrades this bug as “not a security issue” and marks it as “Won’t Fix (Intended Behavior)” because “limiting those services would render the device unusable”.
• December 19th, 2016 — A draft of our IEEE S&P’17 paper is shared with Adrian Ludwig, director of Android Security.
• March 15th, 2017 — We follow up, pointing out that the documentation states otherwise. We also follow up on all the other bugs we opened, asking for a status update.
• May 3rd, 2017 — We follow up a second time asking for a status update for the bugs we reported.
• May 4th, 2017 — Android security team keeps our a11y findings as “won’t fix”, but they state they will update the documentation. We did not receive updates about the other bugs we reported.
• May 8th, 2017 — We have a telco with the anti-malware and a11y Google teams during which we thoroughly discussed all the details of our research.
• May 19th, 2017 — The a11y team confirms the a11y-related issues we reported as “won’t fix”.
• May 22nd, 2017 — This website and our research paper at IEEE S&P are made public.
• Current — All the attacks discussed by this work are still practical, even with latest version of Android (Android 7.1.2, with security patches of May 5th installed).
In the wake of the public disclosure of the research, Google has noted they have updated Google Play Protect to detect and prevent the installation of such apps, and they have already built new security protections into Android O which are meant to protect against these issues.
Still, as the attacks are still practical, users should be careful what apps they download. When they do download an app, they should check if they take advantage of the two permissions.
To see which apps have the “draw on top” permission, go to the device’s settings, and check each individual app. For the “a11y” permission, go to Settings > Accessibility > Services, and check which apps require it.