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 Android APK unpacked to Dalvik bytecode and produce a sCFG (super control flow graph) 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 Block Predicate Extraction Annotates sCFG with block predicates using expression tree produced from symbolic execution sCFG – super control-flow graph (inter-procedural CFG superimposed on the intra-procedural CFGs for each method)

After block predicate extraction After symbolic execution 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 Path Predicate Recovery and Minimization Recovers full intra-procedural path predicates, minimizes them to remove redundant terms and thus false dependencies Predicate Classification From all the predicates recovered, Identify the suspicious predicates by looking at comparators (=, <, > etc) and operands 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 Malicious 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 35 benign applications marked as suspicious 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 Legitimate example: Reminder application – remind you to get milk when you are at the supermarket

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?