TRIGGERSCOPE
TOWARDS DETECTING LOGIC BOMBS IN ANDROID
APPLICATIONS
Yanick Fratantonio, Antonio Bianchi, William Robertson,
Engin Kirda, Christopher Kruegel, Giovanni Vigna
Presented by Aaron Zhong
Background
■ Android is the most popular mobile platform
–
(78% of all smartphones sold Q1 2015)
–
Most widely attacked mobile platform
■ App store providers invest significant resources to keep their platform clean
–
Automated program analysis (ie. Google Bouncer)
–
Manual app review
–
Some malice very difficult to capture => Logic bombs
Logic bomb
“Malicious application logic that is executed, or triggered, only under certain (often
narrow) circumstances “
■ Malicious application logic: Modifies output which violates user’s expectations
■ Example
–
A navigation application meant to assist a
solider by determining shortest route to a
given location
–
After a hard-coded date, the application
provides the longer route
Detecting Logic Bombs with Traditional Methods
■ Manual audit
–
Costly in terms of time and labor
–
No guarantees logic bombs identified – especially if source code is not available
■ Dynamic Analysis
–
Code may not be executed (i.e. Hardcoded date in the future)
■ Static Analysis
–
No unusual permissions or unwanted API calls
–
Network-related API calls perfectly legitimate for a navigation app
”The key challenge is related to the fact that automatically detecting malicious application
logic is very hard without taking into account the specific purpose and “normal” functionality
of an application”
Key Observation
“An aspect that is necessary for the
implementation of a logic bomb is that the
malicious behavior is triggered only under very
specific circumstances.”
Trigger Analysis
“Detect logic bombs by precisely analyzing and characterizing the checks
that guard a given behavior”
■ Predicate (Checks)
–
–
Represents a condition in a program, such as an if statement
A predicate is considered suspicious if it is satisfied only under very specific conditions
■ Functionality (Behavior)
–
–
–
Set of basic blocks in a program
A functionality is considered sensitive if it performs directly or indirectly a sensitive operation
Sensitive operation: Generally, Android APIs protected by a permission combined with
operations that involve the filesystem (Definition of sensitivity can be changed)
■ Trigger: A suspicious predicate that controls the execution of a sensitive functionality
TriggerScope: Phase 1
1. Android APK unpacked to Dalvik bytecode and produce a sCFG (super control flow
graph)
2. Symbolic Execution
–
Reconstruct semantics (annotate sCFG with info about it’s type, value, operations its
influenced by and simple block predicates)
–
Produces expression tree for checks
3. Block Predicate Extraction
–
Annotates sCFG with block predicates using expression tree produced from symbolic
execution
After
Afterblock
symbolic
predicate
execution
extraction
b1
p
b2
b3
b4
Predicate p: now.after(target)
P involves symbolic time
values therefore b2 and b3
have a dependency on a
time-based input
TriggerScope: Phase 2
1. Path Predicate Recovery and Minimization
–
Recovers full intra-procedural path predicates, minimizes them to remove redundant terms
and thus false dependencies
2. Predicate Classification
–
From all the predicates recovered, Identify the suspicious predicates by looking at
comparators (=, <, > etc) and operands
3. Control-Dependency Analysis
–
Checks whether the suspicious predicates guard any sensitive operations
After Path Predicate
Recovery and Minimization
b1
p
b2
b3
b4
Predicate p: now.after(target)
P involves symbolic time
values therefore b2 and b3
have a dependency on a
time-based input
Evaluation
■ Benign Applications
–
9582 applications from Google Play Store
–
All known to use time, location or SMS-related APIs (Sensitive operations)
■ Malicious Applications
–
14 applications from several sources
–
Mostly made for research, intentionally made to be stealthy
Results
Predicate classification Control dependency analysis
■ 35 benign applications marked as suspicious
–
Manually inspected these 35 applications
–
All 35 found to be have suspicious triggers but appeared to be legitimate
–
0.38% false positives
■
20 random applications not marked as suspicious analyzed for false negatives
–
All found to not have any suspicious checks
–
0% false negatives
■ Excellent trade off between false positives and false negatives compared to
existing analysis tools
Performance
■ Timeout set to one hour
–
Approximately 97% successfully analyzed
–
~3% timed out (>250 applications)
–
90% successfully analyzed under 13 minutes
Critiques: Strengths
■ TriggerScope
– Good tool to use in conjunction with existing tools and manual audit
–
For applications marked as suspicious, TriggerScope returns precise information about
location and type of trigger to make manual audit easier
■ Evaluation
– Fewer false positives and false negatives compared with other tools
■ Trigger Analysis
– Novelty: Checking predicates
Critiques: Weaknesses
■
–
–
–
–
Evaluation
Small sample size for applications known to be malicious (14)
>250 applications unsuccessfully analyzed (timeout)
Conservative definition of sensitivity (Only considers time, location and SMS related APIs)
Small sample size to check for false negatives
■ Avoiding Trigger Analysis
– Checks could be obfuscated to appear non-hardcoded
– Malicious application can move suspicious triggers to a web server
Questions?