2014 Network and Distributed System Security (NDSS) Symposium
Screenmilker: How to Milk Your Android
Screen for Secrets
Chia-Chi Lin1, Hongyang Li1, Xiaoyong Zhou2, XiaoFeng
Wang2
1University
of Illinois at Urbana-Champaign
2Indiana University at Bloomington
左昌國
2014/01/07 Seminar @ ADLab, CSIE, NCU
2
Outline
• Introduction
• Programmatic Screenshot on Android
• Design and Implementation
• Evaluation
• Mitigation
• Conclusions
3
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.
4
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.andr
oid.screenshotitfullnoroot
5
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.
6
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.
7
Programmatic Screenshot on Android
8
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.”
Screenshots
Internet
Local socket
ADB installs a
native executable
Native Executable
Device
App
9
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
10
Programmatic Screenshot on Android
11
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.
12
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
13
Design and Implementation
• The architecture overview
14
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
15
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
16
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
17
Design and Implementation - Runtime
Situation Detection
18
Design and Implementation – Real-time
Data Extraction
• Real-time keystroke analysis
19
Design and Implementation – Real-time
Data Extraction
20
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
21
Design and Implementation – Real-time
Data Extraction
• Real-time contact collection
22
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
23
Evaluation - Effectiveness
The capture ratio of Screenmilker to log a single keystroke.
24
Evaluation - Effectiveness
• Password extraction
• Running Screenmilker to extract 40 passwords from each target
app during multiple rounds
• Other apps are running as background noise.
25
Evaluation - Effectiveness
• Contact collection
• ??
26
Evaluation - Stealthiness
• Response time
• API TextWatcher
• Recording the time interval
27
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)
28
Evaluation - Stealthiness
• Memory usages
29
Evaluation - Stealthiness
• Power usages
30
Mitigation
• Mediating the communication between the ADB proxy and
its unprivileged app client
• SEAndroid
• iptables
• Interface suggestions
• LOW_RATE_SCREENSHOT
• HIGH_RATE_SCREENSHOT
31
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.