Droidcon2013 apefs and information flow-analysis for privacy-dauwe_uni_siegen

Julia Dauwe, Simon Meurer & Roland Wismüller
University of Siegen
APEFS and Information-flow Analysis for
Privacy in Android
Droidcon 2013 - Berlin
Operating Systems and Distributed Systems
julia.dauwe@uni-siegen.de

APEFS and Information-flow Analysis for Privacy in Android 2
Background
► Google Play
► Centralized software platform
► About 800,000 apps in
different categories
► Search for Apps → Find it
→ get Information about
Permissions
► What does Permission mean?
► Apps run in sandboxes
► Declare permissions to use
advanced features
► User must accept all presented
permissions to install app

Hypothesis
► Permissions are only “irrelevant facts”
for the user to accept when finally found
“the right” App
► Why do we think so?
► 2 Live Wallpapers requesting
many/all permissions
► 6,660 downloads
in 6 months
► No complains about the requested
permissions
► Own statistics

Statistics
► Statistics created with Apptistic
(Project at University of Siegen)
► Apptistic analyzed ca. 250.000 Apps from Google Play
► Example 1:
► Filter:
► Requested Permissions: Network & personal Data
► Free / Name: “Wallpaper”
► Example 2:
► Requested Permissions: Network & personal Data
► Paid / Category “Games and Entertainment“

Statistics
► Example 1
► 1255 free Android Wallpapers using Network access and personal
Data Permissions, 48 “phone calls”

Statistics
► By the way ...

Statistics
► Example 2
► 884 paid game Apps using Network Access
and personal Data permissions
► 69 are in Top 100 Paid

Reasons
► Granularity of permissions
► User / developer don't understand meaning of permissions
(e.g. “System tools” or “Storage” permissions)
► No color-coded labels to fast classify possible
dangerousness or similar help
► Usage flow: 1. Searching → 2. Finding → 3. Security

Idea: APEFS
► Android PErmission Filter System
► New usage flow:
► Security → Searching → Finding
► Security defined by predefined filter
► Apps that not fit the security level are filtered out
► Strengthens the permissions
► Permissions are no longer another item to accept
► Using infrastructure given by Google
► Basic idea: Parsing websites for permissions

APEFS – App
► Let the user define his own security level
► Filter out Apps requesting Permission Groups:
► Charged Services
► Location, Personal Information
► Internet & Network
► SMS & MMS, Phone Calls
► System Tools, SD-Card & Phone-Storage, Hardware
► Miscellaneous
► Chart Search
► Apps and Games / Top Free, Top Paid, Top New Free ...
► Advanced App Search
► Search for a specific App
► Check installed Apps on the device for permissions

APEFS – Overview
WebsiteWebsite
► APEFS uses Playstore Website Data
for Permission Information
► App-Installation by Google Play App
► Open Google Play on
specific app via Intent:
new Intent(Intent.ACTION_VIEW)
.setData(Uri.parse("market://details?
id=com.test"));
► User is linked to the regular page
► Download / Installation
► Description & Screenshots
► Comments ...

APEFS – App – Search
WebsiteWebsite 2. Result page (24 Apps)
3. Parse for
package ids
1. Request
Charts / Search
4. Request detail pages
based on id
5. Detail pages
6. Parse for
permissions
7. filter results

APEFS – HTML-Parsing
► 1. Parsing App overview page (24 Apps)
► 2. Parsing detail pages of each app

APEFS – HTML-Parsing
► Parsing using a library (e.g. JSOUP)
► Less error-prone
► computationally intensive
► Parsing with regular expressions
► Error-prone
► 452ms (per detailpage) faster than using JSOUP!
String htmlString = fetchHtml(url);
Pattern exp = Pattern.compile("<div classs*=s*
"doc-permission-description">(.*?)</div>);
Matcher m = exp.matcher(htmlString);
while(m.find()){
String permissionName = m.group(1);
/**processing permissions */
}

APEFS – App
► App Search & Installation

APEFS – Lessons Learned
► More than 20.000 downloads in less than 3 months
► Different Feedback
► acceptance as a good helper tool
► User starting to question requested permissions
► But also:
► Misunderstanding of the idea – APEFS is no anti virus
tool (not yet)
► Using feedback for future work
► e.g. adding a blacklist or if applicable collaboration with
detector tool

App analysis
► Filter apps by permissions: ü
► Filter apps by “what they actually do”: current research
► Motivation:
► App requesting private data and network permissions
► Suspicion: app sends private data to the internet
► APEFS: decision only based on permissions
► Information-flow Analysis
► Try to define sensitive data (secrets) and detect leaks
► Proof if a secret is possibly passed to a leak

Information-flow analysis
► Special type of data flow analysis
► Determine possible flows from defined sources to output
channels
APPAPP
ID
Contacts
Mails
...
Internet
SMS
Bluetooth
...

Information-flow Analysis
► Using Soot: a Java Optimization Framework
► Supports interprocedural data-flow analysis with
pointer analysis
► SPARK & PADDLE
► Works on
► Java-bytecode directly
► it's own internal representations jimple, dimple ..
► Jimple: typed 3-adress-representation
► Soot & Android
► .apk-files can be decompiled to jimple
► using dexpler (now integrated in Soot)

Control flow graph
► 1. Use Soot to build a Call Graph with all called methods of
the program
► (Current Work: no libraries or system calls)
► 2. Create a Control flow Graph
for each method
// Building CFG
UnitGraph graph = new
ExceptionalUnitGraph(body);
// do for every code block (statement)
inside this graph...
for (Unit statement : graph) { … }

► 3. Define & create different Sets to accomplish a transfer
function for
► each code block B and Variable v
► Gen(B) – B possible saves critical information in v
► Kill(B) – B definitely DON'T saves
critical information in v
► Copy(B) – B possible saves critical information from
another variable x to v
► Leak(B) – B possible leaks v
► each method M of a Program P and Variables v
► Gen(M) – it exists a Path inside this Method on
which sensitive information is saved in v
► Kill(M), Copy(M), Leak(M) - ...

► 4. Define transfer function for critical and leak set
► Forward flow Analysis to find critical data
► Backward flow Analysis to find leaks
5. Create intersection of critical_in and leak_out
→ If not empty: Some data is leaked!

Points-to Sets
► Points-to Sets (PTS) used as an addition to first analysis
► Try to find pointer targets to check for critical data
► We define a PTS for a variable v as:
► PTS(v) = a set of all objects, v could possible point to
► Therefore we need new definitions of sets and transfer
functions including PTS
► Points-to Analysis in Soot with the help of SPARK and
Paddle
static void setSparkPointsToAnalysis()
soot.PointsToAnalysis pta = Scene.v().getPointsToAnalysis();
PointsToSet pts1 = pta.reachingObjects(local);
Problem: Analysis using Points-to Analysis takes much
more time...

Information-flow Analysis - Problems
► Problem of static analysis:
► Very conservative
► May result in many false positives
► Detects leak of information, but there is none
► Idea: runtime assertions
► Developer can check after compiling where flows are
detected
► Can use assertions to tell there is no flow
► Assertion checked at run-time
► If not fulfilled → App terminated

Runtime Assertions - Example
String s = “Test”;
if (x > 0) {
s = getSecret();
}
if (y < 0) {
leak(s);
}
Secret will be leaked, if x > 0 and y < 0!
Analysis Result: Secret is leaked!
APEFS.assert(!(x > 0 && y < 0));
Secret cannot be leaked
Analysis Result: No secret leaked!

Connection of Analysis to APEFS
► Extend security level
► Sensitive data and permissible flows
► Problem: Analysis only possible on .apk-Package
► Two ways to realize:
► Create own market
► Easy to access packages
► Problem of acceptance
► Apps specify flows in accessible metadata
► Published through self-defined permissions
► Problem: no guarantee for correct metadata
► Digital signature or analysis on device

Conclusion and future work
► APEFS:
► Filter Android apps by permissions / security level
► Based on Google's infrastructure
► New usage flow: Security → Searching → Finding
► Limitation: Filter only by permissions
► Information flow analysis
► Determine flows of information to possible leaks
► Including points-to analysis
► Reduce false positives with e.g. runtime assertions
► Try to speed up analysis

Droidcon2013 apefs and information flow-analysis for privacy-dauwe_uni_siegen

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (8)

Semelhante a Droidcon2013 apefs and information flow-analysis for privacy-dauwe_uni_siegen

Semelhante a Droidcon2013 apefs and information flow-analysis for privacy-dauwe_uni_siegen (20)

Mais de Droidcon Berlin

Mais de Droidcon Berlin (20)

Último

Último (20)

Droidcon2013 apefs and information flow-analysis for privacy-dauwe_uni_siegen