Cloak & Dagger is a new class of potential attacks affecting Android devices. These attacks allow a malicious app to completely control the UI feedback loop and take over the device — without giving the user a chance to notice the malicious activity. These attacks only require two permissions that, in case the app is installed from the Play Store, the user does not need to explicitly grant and for which she is not even notified. Our user study indicates that these attacks are practical. These attacks affect all recent versions of Android (including the latest version, Android 7.1.2), and they are yet to be fixed.
TL;DR — Main Takeaways
- We uncover a series of vulnerabilities and design shortcomings affecting the Android UI.
- These attacks abuse one or both of the SYSTEM_ALERT_WINDOW ("draw on top") and BIND_ACCESSIBILITY_SERVICE ("a11y").
- 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. 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 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). See the full list below.
- These attacks are practical: we performed a user study (with 20 human subjects), and no user understood what happened.
- Most of these attacks are due to design issues, and they are thus challenging to prevent. In fact, one may say that some of these functionality work "as intended"; Nonetheless, this work shows that this functionality can be abused.
- To date, all these attacks are still practical (see "Which versions of Android are affected" and "Responsible Disclosure" below).
List of Attacks
Attacks that abuse the “draw on top” permission:
Attacks that abuse “accessibility service” permission:
- Context-aware clickjacking & Context hiding: two techniques that make luring the user to enable the accessibility service practical, even when the latest security mechanisms (e.g., "obscured flag") are correctly implemented and enabled. (Note: others have identified ways to use clickjacking to get a11y. See "FAQ" below.)
- Invisible Grid Attack, allowing unconstrained keystroke recording, including password, private messages, etc.
Attacks that abuse both permissions:
- Unconstrained keystroke recording, including passwords. According to the documentation, this should not be possible (See "security note" here)
- Security PIN stealing
- Device unlock through PIN injection + perform arbitrary actions while keeping the screen off!
- Stealing two-factor authentication tokens (SMS-based, Google Authenticator, and other app-based tokens)
- Ad hijacking
- Web exploration
- Silent installation of God-mode app (with all permissions enabled)
- Stealthy phishing (for which the user finds herself logged in, as she would expect)
Which versions of Android are affected?
Here is the current status (as of June 19th, 2017). Previous versions are very likely to be vulnerable as well.
||Android 5.1.1 (32.0%*)
||Android 6.0.1 (31.2%)
||Android 7.1.2 (7.1%)
|Invisible Grid Attack||vulnerable||vulnerable||vulnerable|
|Clickjacking → a11y||vulnerable||vulnerable||vulnerable|
|Phone Unlocking (while screen off)||vulnerable||vulnerable||vulnerable|
|Leaky a11y (passwords, 2FA tokens, CCs)||vulnerable||vulnerable||vulnerable***|*
Relative numbers of devices running a given version of Android. The numbers are taken from Google's dashboard
, and they are clustered by Android "main versions", e.g., "Android 5.X".
** Google implemented a partial fix (only on Android 7.1.2): "on top" overlays do not appear anymore whenever an app's permission list is shown. However, this is only used for "normal" permissions, and not for "special" permissions, such as "draw on top" and a11y. This is problematic: since the "clickjacking → a11y" is still possible, a malicious app can use the "Phone Unlocking (while keeping the screen off) attack" to enable these permissions while keeping the screen off, thus making the silent installation of a God-mode app still practical. We suggest Google to extend their protection mechanism to the entire Settings app (or, at the very least, to "special" permissions as well).
*** Although Google marked our bug report as "Won't fix", we noticed that the Google keyboard actually received an update that, at first glance, seems to avoid leaking passwords. In fact, when typing passwords, the accessibility events generated by the Keyboard app itself now contains "Dot" instead of the actual character. However, we found a workaround for our attack: each accessibility event has access to the "hashcode" of the node generating the event. Since it's possible to enumerate the widgets and their hashcodes (which are designed to be pseudo-unique), the hashcodes are enough to determine which keyboard's button was actually clicked by the user.