OVERVIEW SELECTED SECURITY EXTENSIONS AND TOOLS InApp Ad Library Malware AdRisk [Grace et al., WISec 2012] AdDroid [Pearce et al., AsiaCCS 2012] AdSplit [Dietz et al., USENIX Sec. 2012] Privilege EscalaIon (ApplicaIonLevel) Confused Deputy • IPC Inspec5on [Felt et al., USENIX Sec. 2012] • QUIRE [Dietz et al., USENIX Sec. 2012] • XManDroid [Bugiel et al., NDSS 2012] • SORBET [Fragkaki et al., TR 2012] Colluding Apps • XManDroid [Bugiel et al., NDSS 2012] Privilege EscalaIon (MulILevel) SE Android [Smalley and Craig, NDSS 2013] ASF [Backes et al., ACSAC 2014] Malware DetecIon Kirin [Enck et al., ACM CCS 2009] Apex [Naumann et al., AsiaCCS 2010] Paranoid [Portokalidis et al., ACSAC 2010] Airmid [Nadji et al., ACSAC 2011] DroidScope [Yan et al., USENIX Sec. 2012] FlaskDroid [Bugiel et al., USENIX Sec. 2013] Android Security Lab - WS 2014/15 1 ASM [Heuser et al., USENIX Sec. 2014]
91
Embed
Extensions SSL Usability [33,35]€¦ · Rethinking SSL Development in an Appified World Sascha1Fahl1 Marian&Harbach& HenningPerl Markus&Köcer& Mahew&Smith& Seite 5 Manual1App1Tes5ng1Results1!
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
OVERVIEW SELECTED SECURITY EXTENSIONS AND TOOLS
In-‐App Ad Library Malware
AdRisk [Grace et al., WISec
2012]
AdDroid [Pearce et al., AsiaCCS
2012]
AdSplit [Dietz et al., USENIX
Sec. 2012]
Privilege EscalaIon (ApplicaIon-‐Level)
Confused Deputy • IPC Inspec5on
[Felt et al., USENIX Sec. 2012]
• QUIRE [Dietz et al., USENIX Sec. 2012]
• XManDroid [Bugiel et al., NDSS 2012]
• SORBET [Fragkaki et al., TR 2012]
Colluding Apps • XManDroid
[Bugiel et al., NDSS 2012]
Privilege EscalaIon
(MulI-‐Level)
SE Android [Smalley and Craig,
NDSS 2013]
ASF [Backes et al., ACSAC
2014]
Malware DetecIon
Kirin [Enck et al., ACM CCS
2009]
Apex [Naumann et al., AsiaCCS 2010]
Paranoid [Portokalidis et al.,
ACSAC 2010]
Airmid [Nadji et al., ACSAC
2011]
DroidScope [Yan et al., USENIX
Sec. 2012]
FlaskDroid [Bugiel et al., USENIX
Sec. 2013]
Android Security Lab - WS 2014/15 1
ASM [Heuser et al., USENIX
Sec. 2014]
OVERVIEW SELECTED SECURITY EXTENSIONS AND TOOLS
DetecIng and PrevenIng Private Data Leakage
TaintDroid [Enck et al., USENIX OSDI
2010]
TISSA [Zhou et al., TRUST 2011]
AppFence [Hornyack et al., ACM CCS
2011]
ApplicaIon Hardening and Context-‐Based
Policies
System extension • SAINT
[Ongtang et al., ACSAC 2009]
• CRePE [ConI et al., ISC 2010]
Inlined Reference Monitor • Aurasium
[Xu et al., USENIX Sec. 2012]
• AppGuard [Backes et al., DPM 2013]
• Dr Android and Mr. Hide [Jeon et al., SPSM 2012]
DRM Policies and Domain IsolaIon
Porscha [Ongtang et al., ACSAC
2010]
TrustDroid [Bugiel et al., ACM SPSM
2011]
Security Aspects of App Stores
DroidRanger [Zhou et al., NDSS 2012]
DroidMOSS [Zhou et al., CODASPY
2012]
Meteor [Barrera et al., IEEE MoST
2012]
MOSES [Russello et al., SACMAT
2012]
Android Security Lab - WS 2014/15 2
3 Android Security Lab - WS 2014/15
Android Security Extensions
SSL Usability [33,35]
Rethinking SSL Development in an Appified World
Sascha Fahl Marian Harbach
Henning Perl Markus Köcer Machew Smith
Seite 5
Manual App Tes5ng Results
§ cherry-‐picked 100 Apps § 21 Apps trust all cerIficates § 20 Apps accept all hostnames
Sascha Fahl, 16.10.2012
What we found:
Seite 6
Talking to Developers
§ Finding broken SSL in Apps is good… …knowing what the root causes are is even better
§ We contacted 80 developers of broken apps
§ informed them § offered further assistance § asked them for an interview
§ 15 developers agreed
Rethinking SSL Development in an Appified World
Seite 7
Common: Blaming Developers
“It’s all the developers’ fault!”
Rethinking SSL Development in an Appified World
Seite 8
It’s Time to Rethink how we code SSL
Rethinking SSL Development in an Appified World
Seite 9
Developers’ Wishlist
§ Self-Signed Certificates – Development
§ Self-Signed Certificates – Production
§ Less SSL Coding
§ Certificate Pinning / Trusted Roots
§ Easy-to-use Warning Message
Rethinking SSL Development in an Appified World
Seite 10
Getting out of the Dilemma
Current Situation: § Developers have the freedom to customize certificate
validation § Developers mostly are not security experts § Developers find the current situation too inflexible Future Situation: § Protect the user! § Make the common use cases easy § Adapt certificate handling to the developers’ needs Solution: Improve usability of certificate handling for developers!
Rethinking SSL Development in an Appified World
Seite 11
Patching Android OS
CA
Validation
CA
Pinning
Certificate
Pinning
DevelopmentM
ode
Logging
Validation
Strategies
Standard X — — — — —Our approach X X X X X P
Table 1: A comparison between the status quo andour approach concerning validation features.X = supported out of the box;� = custom code required;P = pluggable.
org.apache.http.conn.ssl
SSLSocketFactorystart
Force hostnameverification
android.net.ssl
TrustManagerClient(in app)
Force certificate validation;Configurable by the users
Turn on/o↵ SSLPinning,Accept all certificateson developer devices
Human Com-puter Interface
Warn the user if con-nection is insecure
Existing architectureOur modifications
uses
uses
configures
decisions
warn
ifSSLvalid
ationfails
removed
Figure 1: This figure illustrates the process of creat-ing an SSL protected network connection. The greyboxes comment on our contributions.
To this end, we provide the TrustManagerClient and Trust-
ManagerService that replace the capabilities of Android’sdefault TrustManager (cf. Figure 1). We only modify meth-
ods which are private and final, thus binary compatibility isgiven and we do not break modularity. More information onthe compatibility of our approach can be found in Section 6.2and Appendix B. Both the client and service part of our SSLvalidation implementation prevent Android apps from us-ing broken certificate validation. Upon creation of a socket,the newly developed TrustManagerClient automatically re-quests SSL certificate validation from the service counter-part. App developers cannot circumvent secure validationanymore, since customized TrustManager implementationsare prevented by our modification. The TrustManagerSer-
vice enforces SSL certificate validation against the trustedroot CAs and can drop the connection or present the userwith a warning message in case validation fails (more on thisin Section 5.2.4).To mandate secure hostname verification, we patched all
stock hostname verifiers to enforce browser compatible host-name verification. We also added hostname verification tothe central SSLSocketFactory (cf. Figure 1). Hostname ver-ification is conventionally delegated to the application layer:With HTTPS for example, the hostname for verification isextracted from the requested URL. In contrast, Android’sSSLSocketConnection implementation does not check thehostname, even though it may have been provided in themethod call. Our patch improves this behavior by verifyinghostnames with the parameters provided during connectionestablishment for any SSL connection.This strict enforcement could cause developer issues in
some usage scenarios described by our study participants,so several configuration options are described in the follow-ing in order to adapt our solution to di↵erent situations.Additionally, we discuss potential pathological cases in theappendix (see App. B.1).
5.2.2 Self-Signed CertificatesTo allow developers to use self-signed certificates for test-
ing purposes, we add a new option (cf. Figure 2) to theDeveloper settings, allowing app developers to turn o↵ SSLcertificate validation for specific apps installed on their de-vice without needing to modify the code of their app. Thisoption is monitored by the TrustManagerService and skipscertificate validation for this app only. These settings onlya↵ect the specific app on the developer device, not the appsdeployed onto users’ devices or other apps on the developer’sdevice. Thus, even if developers forget to turn on certificatevalidation again, this has no e↵ect on apps on user devices.This feature e↵ectively protects users from forgetful devel-opers and solves many of the problems we discovered duringcode analysis and interviews.We only allow this option on devices that have developer
settings enabled. Thus, app developers have a simple way towork with self-signed certificates during development whilepreventing careless users from turning o↵ SSL certificate val-idation for their apps.4 Nonetheless, we show a warningmessage using strong wording that advises against abuse(cf. Fig. 2(b)) when this option is toggled.
4While it is conceivable that users annoyed by warning mes-sages could find information online on how to activate de-veloper options and then turn o↵ certificate validation for aspecific app, we believe this risk is fairly low compared tothe huge benefit this option brings. Additionally, we recom-mend limiting this option to devices that are registered withGoogle developer accounts to prevent normal users from
Rethinking SSL Development in an Appified World
Seite 12
Self-Signed Certificates – Development
Rethinking SSL Development in an Appified World
enable developer options disable SSL validation for this app only
Conclusion ✔ Eve and Mallory no longer love Android ✔ Backwards compatible – no broken apps, except ✘ apps that implemented pinning (19 in 13500 tested Android
apps) ✔ updating them to the new pinning sytem is very easy
✔ New features for Android ✔ Easy to use self-signed certs for development ✔ Easy to use pinning / custom CAs ✔ Central and easy to use warning messages ✔ Central place to plug in new validation strategies – such as
Download the Code and have a go: http://android-ssl.org
16 Android Security Lab - WS 2014/15
Android Security Extensions
Taint tracking [36,37]
17 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones
OSDI’10
William Enck, Peter Gilbert, Byung-Gon Chun, Landon P. Cox, Jaeyeon Jung, Patrick McDaniel, and Anmol N. Sheth
1
18 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Monitoring Smartphone Behavior
• There are tens of thousands of smartphone apps that provide both fun and valuable utility.
• General challenge: balance fun and utility with privacy
• Step 1: “look inside” of applications to watch how they use privacy sensitive data
‣ location‣ phone identifiers‣ microphone‣ camera‣ address book
3
19 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Challenges
• Goal: Monitor app behavior to determine when privacy sensitive information leaves the phone
• Challenges ...
‣ Smartphones are resource constrained
‣ Third-party applications are entrusted with several types of privacy sensitive information
‣ Context-based privacy information is dynamic and can be difficult to identify even when sent in the clear
‣ Applications can share information
4
20 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Dynamic Taint Analysis
• Dynamic taint analysis is a technique that tracks information dependencies from an origin
• Conceptual idea:
‣ Taint source
‣ Taint propagation
‣ Taint sink
• Limitations: performance and granularity is a trade-off5
c = taint_source()...a = b + c...network_send(a)
21 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
TaintDroid• TaintDroid is a system-wide integration of taint
tracking into the Android platform
‣ Variable tracking throughout Dalvik VM environment‣ Patches state after native method invocation‣ Extends tracking between applications and to storage
• TaintDroid is a firmware modification, not an app6
Network Interface
Native System Libraries
Virtual Machine
Virtual Machine
Application Code Application CodeMsg
Secondary Storage
Message-level tracking
Variable-leveltracking
Method-leveltracking
File-leveltracking
22 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
VM Variable-level Tracking
• We modified the Dalvik VM interpreter to store and propagate taint tags (a taint bit-vector) on variables.
• Local variables and args: taint tags stored adjacent to variables on the internal execution stack.
‣ 64-bit variables span 32-bit storage
• Class fields: similar to locals, but inside static and instance field heap objects
• Arrays: one taint tag per array to minimize overhead
7
out1 taint tag
(unused)
VM goop
v0 == local0
v0 taint tag
v1 == local1
v1 taint tag
v2 == in0
Low Addresses (0x00000000)
High Addresses (0xffffffff)
out0
VM goop
v0 == local0
v0 taint tag
v1 == in0
frame pointer (previous)
frame pointer (current)
Interpreted Targets
arg0
Native Targets
stack pointer (top)
out1
out0 taint tag
out0
v1 taint tag
v2 == in1
v2 taint tag
arg1
return taint
arg0 taint tag
arg1 taint tag
v4 taint tag
variable variable taint tag
23 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Native Methods
• Applications execute native methods through the Java Native Interface (JNI)
• TaintDroid uses a combination of heuristics and method profiles to patch VM tracking state
‣ Applications are restricted to only invoking native methods in system-provided libraries
9
Network Interface
Native System Libraries
Virtual Machine
Virtual Machine
Application Code Application CodeMsg
Secondary Storage
Message-level tracking
Variable-leveltracking
Method-leveltracking
File-leveltracking
24 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
IPC and File Propagation
• TaintDroid uses message level tracking for IPC
‣ Applications marshall and unmarshall individual data items
• Persistent storage tracked at the file level
‣ Single taint tag stored in the file system XATTR
10
Network Interface
Native System Libraries
Virtual Machine
Virtual Machine
Application Code Application CodeMsg
Secondary Storage
Message-level tracking
Variable-leveltracking
Method-leveltracking
File-leveltracking
25 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Performance
• Memory overhead: 4.4%
• IPC overhead: 27%
• Macro-benchmark:‣ App load: 3% (2ms)
‣ Address book: (< 20 ms)5.5% create, 18% read
‣ Phone call: 10% (10ms)
‣ Take picture: 29% (0.5s)
11
0
200
400
600
800
1000
1200
1400
1600
1800
2000
sieve loop logic string float method total
Android
TaintDroid
CaffeineMark 3.0 benchmark(higher is better)
14% overhead
CaffeineMark score roughly corresponds to the number of Java instructions per second.
26 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Taint Adaptors
• Taint sources and sinks must be carefully integrated into the existing architectural framework.
29 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Findings - Phone Identifiers
• 7 applications sent device (IMEI) and 2 apps sent phone info (Ph. #, IMSI*, ICC-ID) to a remote server without informing the user.‣ One app’s EULA indicated the IMEI was sent‣ Another app sent the hash of the IMEI
• Frequency was app-specific, e.g., one app sent phone information every time the phone booted.• Appeared to be sent to app developers ...
15
“There have been cases in the past on other mobile platforms where well-intentioned developers are simply over-zealous in their data gathering, without having malicious intent.” -- Lookout
30 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Limitations
• Approach limitations:
‣ TaintDroid only tracks data flows (i.e., explicit flows).
• Taint source limitations:
‣ IMSI contains country (MCC) and network (MNC) codes
‣ File databases must be all one type
16
31 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Summary
• TaintDroid provides efficient, system-wide, dynamic taint tracking and analysis for Android
• We found 20 of the 30 studied applications to share information in a way that was not expected.
• Source code will be available soon: appanalysis.org
• Future investigations:
‣ Provide direct feedback to users‣ Potential for realtime enforcement‣ Integration with expert rating systems
17
32 Android Security Lab - WS 2014/15 Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Ü Choose the control that caused least-‐severe side effects for each app: 33 apps (66%) had no side effects or ads absent Ü We used profiling to choose; determining in advance is challenging
Ü These apps had four kinds of funcIonality that directly conflict with our configuraIon (sensiIve data should never leave the device): Ü LocaIon broadcast (locaIon) Ü Geographic search (locaIon) Ü Find friends (contacts) Ü Cross-‐applicaIon gaming profiles (device ID)
Ü Some applicaIons force the user to choose between funcIonality and privacy Ü ProtecIng sensiIve data will always cause side effects for these applicaIons
Ü Remaining apps: AppFence can prevent misappropriaIon without side effects Ü Choosing the least-‐disrupIve privacy control in advance is sIll an open problem
Ü Each control was less disrupIve for certain sensiIve data types
ASM: A Programmable Interface for Extending Android Security
Stephan Heuser,
Ahmad-Reza Sadeghi
Intel Collaborative Research Institute for
Secure Computing at TU Darmstadt,
Germany
Adwait Nadkarni,
William Enck
NC State University, USA
Android Security Framework: Extensible multi-layered access control on Android
53 Android Security Lab - WS 2014/15
M. Backes, S. Bugiel, S. Gerling, and P. von Styp-‐Rekowsky
To appear at 30th Annual Computer Security ApplicaIons Conference (ACSAC’14)
54 Android Security Lab - WS 2014/15
Android Security Extensions (selected)
ASM - Android Security Modules 2
Security extensions focus on specific use cases and/or security and privacy models
Context-based Apps
CRePE, ConXSense
Privacy TaintDroid, AppFence, MockDroid
Type Enforcement
SEAndroid, FlaskDroid
Fine-Grained
Permissions APEX, CRePE
Permission Constraints
Kirin
App Communication Saint, XManDroid,
TrustDroid, Aquifer
IPC Provenance QUIRE,
IPC Inspection
Mock Data
MockDroid, TISSA, AppFence
55 Android Security Lab - WS 2014/15
System Apps
Android Security Extensions
ASM - Android Security Modules 3
Access control (hooks) are embedded in sensitive components
Linux DAC, SELinux/SEAndroid
3rd Party App
System ContentProviders
(e.g. contacts)
Activity Manager Service
3rd Party App
Framework Libraries Package Manager Service
Applications
Linux Kernel
Android OS Access Control
Access Control
Access Control (Inlined Reference
Monitor)
56 Android Security Lab - WS 2014/15
Research Question
ASM - Android Security Modules 4
Is it possible to provide a programmable and generic security architecture on top of which many of these solutions can be
instantiated?
57 Android Security Lab - WS 2014/15
Observations
ASM - Android Security Modules 5
Diverse Goals, but use similar security hooks and mechanisms System Android
ICC Package Manager
Sensors / Phone
Info
Fake Data
System Content
Providers
File Access
Network Access
3rd Party Hooks
MockDroid � 9 9 9 9 9
XManDroid 9 9 9 9 9
TrustDroid 9 9 9 9 9
FlaskDroid 9 9 9 9 9 9 9 9
CRePE 9 9
Quire 9 9
TaintDroid 9 9 9 9
Kirin 9
IPC Inspection 9 9
AppFence 9 9 9 9 9 9 9
Aquifer 9 9 9
APEX 9 9 9
Saint 9 9 9
SEAndroid 9 9 9 9
TISSA 9 9 9
58 Android Security Lab - WS 2014/15
Android OS
Linux Kernel
High-level Idea of ASM
ASM - Android Security Modules 6
� A modular access control architecture supporting multiple stakeholders � Deploy Android Security Modules (ASMs) as apps
Enterprise
User
Platform Provider
Access Control
Access Control
Android
3rd Party App
ASM Enterprise
ASM User
ASM Provider
59 Android Security Lab - WS 2014/15
System ContentProviders
(e.g. contacts)
System Services (e.g. ActivityManager)
ASM Framework
ASM - Android Security Modules 9
1. Register Callback Service
2. Query Hooks
ASM User
ASM Provider
ASM Enterprise
Hook
Hook
Applications
Linux Kernel
Android OS
ASM Bridge Reference Monitor
3rd Party App WhatsApp
ASM LSM SELinux LSM
60 Android Security Lab - WS 2014/15
Hook Invocation
ASM - Android Security Modules 10
Applications
Linux Kernel
ASM User
ASM Provider
ASM Enterprise
System ContentProviders
(e.g. contacts)
System Services (e.g. ActivityManager)
Query Callback
Protection Event (query contacts)
Hook
Hook
ASM Bridge
3rd Party App WhatsApp
ASM LSM SELinux LSM
Android OS
61 Android Security Lab - WS 2014/15
System ContentProviders
(e.g. contacts)
Support for 3rd-Party Hooks
ASM - Android Security Modules 11
ASM User
ASM Provider
ASM Enterprise
Register 3rd-party Hook
ASM aware 3rd Party App
Hook
Hook
Applications
Linux Kernel
Android OS
ASM Bridge
ASM LSM SELinux LSM
62 Android Security Lab - WS 2014/15
ConXSense
ConXSense Context Aware Access Control
ASM - Android Security Modules 17
• Goal: Context-aware access control
• Context-aware access control enforcing policies by user context profiling
• Includes access control on sensors (e.g., GPS and camera), sensitive information (e.g., contacts) and apps
• ASM based implementation:
ConXSense ASM
Context Profiler
User Interface
ASM Callback Service Location Info
BT Sensing
User Input
WiFi Sensing System
ContentProviders
ActivityManager Service
CameraService
LocationManager Service
Ho
ok
Ho
ok
Ho
ok
Ho
ok
ConXSense [ASIACCS 2014]
ASF DESIGN
63 Android Security Lab - WS 2014/15
ASF API AND USE-‐CASES
§ Security API - 136 funcIons for enforcement hooks in all major system services and apps - Hooks support edit automata policies (i.e., modificaIon of return values
instead of only deny/allow decision) § Use-‐cases: PorIng previous research prototypes as modules on ASF
- FlaskDroid/SE Android (type enforcement at middleware and kernel level) - TrustDroid (domain isolaIon private vs work) - CRePE (Context-‐aware access control) - AppOps and IntentFirewall (dormant Android features by Google)
- AppGuard (IRM) - XManDroid (Chinese wall policies) - Saint (Developer policies) - Data shadowing
§ In general minimal overhead of porIng those use-‐cases to our system