1 of 61

Cloak & Dagger

From Two Permissions to Complete�Control of the UI Feedback Loop

Yanick Fratantonio

joint work with�Chenxiong Qian, Simon Chung, Wenke Lee

IEEE Symposium on Security and Privacy 2017

May 24th, 2017

2 of 61

UI Feedback Loop

Output channel

Input channel

Know what is currently displayed to the user

Modify what the user sees

Know what the user is clicking on

Inject user input

Cloak & Dagger Attacks

3 of 61

Two Permissions

4 of 61

SYSTEM_ALERT_WINDOW (“draw on top”)

  • Draw arbitrary windows/overlays on top of the screen
    • Can be completely custom: shape, content, transparency
    • Can be clickable xor passthrough

​

  • This permission is used quite often
    • 454 out of 4,455 top apps (10.2%)

​

  • Used by Facebook, Skype, Uber, LastPass, ...

5 of 61

BIND_ACCESSIBILITY_SERVICE (a11y)

  • Mechanism for apps to assist users with disabilities

​

  • Many powerful capabilities
    • It is notified for each UI event
    • It can inject UI events (e.g., clicks)

​

  • Used by 24 out of 4,455 top apps
    • Password managers (LastPass), antivirus apps, app lockers, ...

6 of 61

A11y security mechanism

  • Accessibility service cannot read “sensitive information” off the screen.
  • Example: password fields

“Since an event contains the text of its source privacy can be compromised by leaking sensitive information such as passwords. To address this issue any event fired in response to manipulation of a PASSWORD field does NOT CONTAIN the text of the password.”

7 of 61

Why would a user grant these permissions?

  • “The user needs to explicitly approve! Not stealthy!”

​

8 of 61

Why would a user grant these permissions?

  • “The user needs to explicitly approve! Not stealthy!”

​

  • “Draw on top” is automatically granted for Play Store apps!

9 of 61

Why would a user grant these permissions?

  • “The user needs to explicitly approve! Not stealthy!”

​

  • “Draw on top” is automatically granted for Play Store apps!

​

  • We developed a new practical clickjacking attack
    • The user is lured to unknowingly enable the a11y!

The list of permissions is not even shown!

10 of 61

Unleashing Mayhem

11 of 61

Clickjacking 101

Click here

12 of 61

The “obscured flag” security mechanism

​

  • The “obscured flag” is helpful to detect that�“another overlay was on top” of the button

13 of 61

The “obscured flag” security mechanism

​

  • The “obscured flag” is helpful to detect that�“another overlay was on top” of the button

​

  • Who says that you need to cover the “target” button?

14 of 61

Attack: Context Hiding

Capture?

15 of 61

Attack: Context Hiding

  • Design shortcoming: Apps do not have access to enough context information to take informed decisions

​

  • The “obscured flag” is conceptually broken

16 of 61

Attack: Context Hiding

  • Design shortcoming: Apps do not have access to enough context information to take informed decisions

​

  • The “obscured flag” is conceptually broken

​

  • Context hiding + Context-aware clickjacking ~> a11y
    • Need to hijack three clicks
    • No guessing is involved
    • The clicks do not need to be consecutive

17 of 61

Back to the “obscured flag”...

  • Not only it is not useful…

18 of 61

Back to the “obscured flag”...

  • Not only it is not useful…

​

  • ...but it can be abused to mount even worse attacks!

19 of 61

Attack: Invisible Grid Attack

  • This attack can record all “keystrokes”
    • It only relies on the “draw on top” permission

20 of 61

Attack: Invisible Grid Attack

  • This attack can record all “keystrokes”
    • It only relies on the “draw on top” permission

​

  • “Obscured flag” used as side-channel

21 of 61

Attack: Invisible Grid Attack

1

3

4

2

22 of 61

Attack: Invisible Grid Attack

1

2

3

4

Where did the user click?

23 of 61

Attack: Invisible Grid Attack

MotionEvent

1

2

3

4

1

2

3

4

Overlay #

MotionEvent

MotionEvent

MotionEvent

Not obscured

Not obscured

Not obscured

Not obscured

Where did the user click?

24 of 61

Attack: Invisible Grid Attack

MotionEvent

1

2

3

4

1

2

3

4

Overlay #

MotionEvent

MotionEvent

MotionEvent

Obscured

Not obscured

Not obscured

Not obscured

Where did the user click?

25 of 61

Attack: Invisible Grid Attack

MotionEvent

1

2

3

4

1

2

3

4

Overlay #

MotionEvent

MotionEvent

MotionEvent

Obscured

Not obscured

Not obscured

Obscured

Where did the user click?

26 of 61

Attack: Invisible Grid Attack

MotionEvent

1

2

3

4

1

2

3

4

Overlay #

MotionEvent

MotionEvent

MotionEvent

Obscured

Not obscured

Obscured

Obscured

Where did the user click?

27 of 61

Attack: Invisible Grid Attack

1

2

3

4

Security mechanism used as side-channel!

The attacker can use these patterns to infer where the user clicked!

28 of 61

Attack: Invisible Grid Attack

These overlays are drawn invisible during a real attack

29 of 61

Design Shortcomings

  • Violation of the principle of least privilege
    • Why can an app create invisible overlays?

​

  • Android’s “WindowManager” is extremely complex
    • Introduction of unexpected side-channels
    • UI security as an afterthought

30 of 61

Attack: a11y on steroids

  • Yet another design shortcoming:
    • By default, UI objects are all considered�non security-sensitive

​

​

31 of 61

Attack: a11y on steroids

1) Steal PIN

2) Inject PIN and unlock the phone!

Bonus point: phone unlock while keeping the screen is off!

32 of 61

Attack: Stealthy Phishing

<username>

<password>

<password>

<username>

Login

Login

JohnDoe

L33tP4ss

<username>

<password>

JohnDoe

L33tP4ss

Login

Filled�by a11y

Clicked by a11y

Welcome, John!

Great!

UI-in-the-middle

Attack

33 of 61

Attack: Silent God-mode App Installation

  • We show a video to the user...

34 of 61

Attack: Silent God-mode App Installation

  • We show a video to the user...

​

  • ...and, behind the scene, we do nasty things

35 of 61

Attack: Silent God-mode App Installation

  • We show a video to the user...

​

  • ...and, behind the scene, we do nasty things

​

  • The grand plan
    • Silent installation of super-malicious app
    • Enable all its permissions
    • Clean up steps

36 of 61

Are these attacks actually practical?

37 of 61

User Study

  • 20 human subjects

​

  • Attacks we tested
    • Clickjacking to enable a11y
    • Silent God-mode app installation
    • Stealthy phishing

38 of 61

Results

  • Clickjacking to enable a11y
    • None of the subject understood what happened

39 of 61

Results

  • Clickjacking to enable a11y
    • None of the subject understood what happened

​

  • Silent God-mode app installation
    • None of the subject understood what happened

40 of 61

Results

  • Clickjacking to enable a11y
    • None of the subject understood what happened

​

  • Silent God-mode app installation
    • None of the subject understood what happened

​

  • Stealthy phishing
    • 18 out of 20 did not detect any difference
    • The remaining two triggered a bug in our prototype, and they reported “graphical glitches” (but they did not understand they were attacked)

41 of 61

Overall Awareness

  • Do users know about these two permissions?

42 of 61

Overall Awareness

  • Do users know about these two permissions?

​

  • Results are worrisome
    • Only 2 out of 20 knew about the “draw on top” permission
    • Only 5 out of 20 knew about a11y
    • No subject knew about both!

43 of 61

Overall Awareness

  • Do users know about these two permissions?

​

  • Results are worrisome
    • Only 2 out of 20 knew about the “draw on top” permission
    • Only 5 out of 20 knew about a11y
    • No subject knew about both!

​

  • ...why should they look for them?

44 of 61

How can we fix this?

45 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)

46 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity (not fixed yet)

47 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity (not fixed yet)
    • A11y on steroids

48 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity (not fixed yet)
    • A11y on steroids ~> ???

49 of 61

Disclosure of “a11y on steroids” (August 22nd)

  • Bug marked as “Won’t fix, work as intended” (September 30th)

​

  • Bug marked as “High severity” (October 18th)

​

  • Downgraded to “Won’t fix” because “limiting those services would render the device unusable” (November 28th)

​

  • “We will update the documentation” (May 4th)

50 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity
    • A11y on steroids ~> ???

51 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity
    • A11y on steroids ~> ???
    • New clickjacking technique

52 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity
    • A11y on steroids ~> ???
    • New clickjacking technique

Few classes of vulnerabilities will generally not qualify for a reward:

  • Tap-jacking and UI-redressing attacks that involve tricking the user into tapping a UI element

Android Rewards�Qualifying Vulnerabilities

53 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity
    • A11y on steroids ~> ???
    • New clickjacking technique ~> :-(

54 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity
    • A11y on steroids ~> ???
    • New clickjacking technique ~> :-(

​

  • Shared the paper draft with Adrian Ludwig, head of Android security (December 19th)

55 of 61

Responsible Disclosure

  • “Simple bugs” through AOSP bug reports (August 22nd)
    • Invisible Grid Attack ~> Moderate severity
    • A11y on steroids ~> ???
    • New clickjacking technique ~> :-(

​

  • Shared the paper draft with Adrian Ludwig, head of Android security (December 19th)

All attacks are still working!�(Even on Android 7.1.2, with May’s updates)

56 of 61

Short-term Recommendations

  • “Draw on top” permission should not be automatically granted!

​

  • More thorough vetting process for apps requiring both “draw on top” and a11y
    • They are not many, manual vetting could be feasible

57 of 61

Securing Android UI

  • Introduce the concept of “Secure Apps & Widgets”
    • Defined through a flag that is propagated across the view tree

​

  • OS-enforced guarantee
    • No overlay will be shown on top of any secure app/widget

​

  • System popups
    • Inspired by web popups

58 of 61

Takeaways

  • “Cloak & Dagger” attacks
    • Stealthy, powerful, and practical UI attacks
    • New ways to abuse known “problematic” permissions

59 of 61

Takeaways

  • “Cloak & Dagger” attacks
    • Stealthy, powerful, and practical UI attacks
    • New ways to abuse known “problematic” permissions

​

  • UI security bugs matter
    • They are the low-hanging fruits for the attackers
    • “We don’t know how to fix it” != “We should not fix it”

60 of 61

Takeaways

  • “Cloak & Dagger” attacks
    • Stealthy, powerful, and practical UI attacks
    • New ways to abuse known “problematic” permissions

​

  • UI security bugs matter
    • They are the low-hanging fruits for the attackers
    • “We don’t know how to fix it” != “We should not fix it”

​

  • More info: cloak-and-dagger.org

Yanick Fratantonio

@reyammer

https://cs.ucsb.edu/~yanick

yanick@cs.ucsb.edu

61 of 61