Screenmilker: How to Milk Your Android Screen for SecretsChia-Chi Lin1, Hongyang Li1, Xiaoyong Zhou2, XiaoFeng Wang2

1University of Illinois at Urbana-Champaign2Indiana University at Bloomington

2014 Network and Distributed System Security (NDSS) Symposium

左昌國2014/01/07 Seminar @ ADLab, CSIE, NCU

Outline• Introduction• Programmatic Screenshot on Android• Design and Implementation• Evaluation• Mitigation• Conclusions

2

Introduction• Demanded functions in Android

• Wireless tethering• System backup• New font adding• Screenshot

• Android Debug Bridge (ADB) (link)• A tool to communicate emulators or Android devices with

development machine• A service can be invoked in emulators or Android devices with

privileges.• Apps can communicate with this service process to acquire the

resources the Android APIs do not provide.• This is legitimate.

3

Introduction• Screenshot (no-root)

• Signature-level permission• Hardware mechanism (4.0+)

• Power + Volume-Down• ADB

• https://play.google.com/store/apps/details?id=com.edwardkim.android.screenshotitfullnoroot

4

Introduction• This paper implements a malicious app, Screenmilker,

that collects user secrets through ADB channel.• INTERNET permission only• Demo http://www.youtube.com/watch?v=5I04HvvLx-g

• Contributions• Understanding of the security risks of the ADB workaround and the

local-socket channel• New techniques for targeted, stealthy and real-time collection of

sensitive information from screenshots• The evaluation is effective.

5

Programmatic Screenshot on Android• No programmable interface for screenshot

• Root, or• Leveraging an native executable as a proxy to access ADB’s

capabilities

• Permissions• Normal level (e.g., setting an alarm)• Dangerous level (e.g., opening network sockets)• Signature level (e.g., accessing the frame buffer)

• ADB has a set of unique capabilities (signature-level) specified under the Android permission system.

6

Programmatic Screenshot on Android

7

Programmatic Screenshot on Android• The ADB workaround

• Run a customized Android native executable through ADB. (with desired permissions)

• Establish a communication channel between the executable and a 3rd-party app to access “protected resources with the permissions.”

8

ADB installs a native executable

Native Executable App

Screenshots

Device

Local socket

Internet

Programmatic Screenshot on Android• The problem is…

• No protection on the local socket channel• Any app can request service from the ADB proxy at any time

without any restriction.• If you know the protocol

• A malicious app could utilize the existing ADB proxy to perform malicious activities.• Required INTERNET permission only

• Generality of the problem• Sync and backup apps• USB tethering apps

9

Programmatic Screenshot on Android

10

Design and Implementation• Some challenges

• The screenshot file size is too big.• Data usage• Storage usage

The malicious app can not take screenshot all the day.The right chance to take a screenshot is important.

11

Design and Implementation• Adversary model

• The adversary can disguise Screenmilker into another genuine app to trick users to install it.

• The malicious app only needs the INTERNET permission.• The target device has one no-root screenshot apps installed.• The device owner pays attention to mobile-data usage and utilizes

other tools to discover the problematic behaviors of the apps on the phone

12

Design and Implementation• The architecture overview

13

Design and Implementation - Runtime Situation Detection• Runtime Situation Detection

• Detecting the screenshot proxy• Monitoring target apps• Detecting display states

• Detecting the screenshot proxy• API PackageManager• Linux command PS• Checking the TCP ports

14

Design and Implementation - Runtime Situation Detection• Monitoring target apps

• Running PS periodically• Process ID (PID)

• Accessing /proc/PID/stat for memory and CPU usage• Inferring the app’s current state

• Monitoring on the default soft keyboard app (com.google.android.inputmethod.latin)• Accessing /proc/PID/stat every 100ms to detect the change of the

app’s CPU usage.• Whenever the accumulated user CPU time increases, the app is at the

state receiving the user’s typing inputs.• Starting to take shots

15

Design and Implementation - Runtime Situation Detection• Detecting display states

• The foreground issue• API getRotation• Periodically grabbing screenshots (while the target app is running)

• Extracting part of the image to search a set of fingerprints for target app’s activities of interest

• Building a hash table to map the CRC32 value of the title bar region of an app’s UI

16

Design and Implementation - Runtime Situation Detection

17

Design and Implementation – Real-time Data Extraction• Real-time keystroke analysis

18

Design and Implementation – Real-time Data Extraction

19

Design and Implementation – Real-time Data Extraction• Discussion

• A user may press keys in a rate higher than the rage of picture taking• Dictionary• Multiple rounds

• Backspace (or moving the cursor)• Multiple rounds

• Different soft keyboard• Increasing the hash table

20

Design and Implementation – Real-time Data Extraction• Real-time contact collection

21

Evaluation - Effectiveness• App monitoring

• Ten 10-minute typing sessions• Probing /proc/PID/stat every 100ms• Using the API TextWatcher to compare with the recorded log

• Display detecting• Five banking apps

• American Express US, Citi Mobile, Chase Mobile, Paypal, and Wells Fargo Mobile

• Hash fingerprinting on the login title bars• Keystroke logging

• Capture ratio• The ratio of keystrokes that Screenmilker was able to get when a user

was typing 100 keys

22

Evaluation - Effectiveness

23

The capture ratio of Screenmilker to log a single keystroke.

Evaluation - Effectiveness• Password extraction

• Running Screenmilker to extract 40 passwords from each target app during multiple rounds

• Other apps are running as background noise.

24

Evaluation - Effectiveness• Contact collection

• ??

25

Evaluation - Stealthiness• Response time

• API TextWatcher• Recording the time interval

26

Evaluation - Stealthiness• Resource consumption

• The execution times for individual malware components• Each component was invoked 10,000 times (once every 100ms)• Less than 1ms for every measure (1% CPU overhead)

27

Evaluation - Stealthiness• Memory usages

28

Evaluation - Stealthiness• Power usages

29

Mitigation• Mediating the communication between the ADB proxy and

its unprivileged app client• SEAndroid• iptables

• Interface suggestions• LOW_RATE_SCREENSHOT• HIGH_RATE_SCREENSHOT

30

Conclusions• Android lacks access control on the local network socket

channel• The ADB could be exploited by an adversary to gain unauthorized

signature-level permissions• This paper designed and implemented Screenmilker to

demonstrate that through lightweight detection and extraction, a malicious app can effectively and stealthily gather confidential information.

31