THREATS,
VULNERABILITIES IN
ANDROID OS
BY
DNYANADA PRAMOD ARJUNWADKAR
AJINKYA THORVE
Guided by,
Prof. Shambhu Upadhyay
WHY ANDROID OS?
•Open Source, Distributed Environment
•Unofficial App Developers
•No Filtering of Apps on App Store
•Installation of apps from Unknown Sources
•Presence of Third party App Stores
•Irrelevant Permissions for Apps
•OS Updates, Security Patches Distribution Delay
Android Threats
Source: http://androidvulnerabilities.org/
Risks Involved
•User Privacy Violations
•Call Logs
•Email ids
•Contacts
•Browsing History
•Photos
•Loss of Control of Device
•Consumption of Resources
EXISTING SECURITY MODEL
•Permissions
•SSL Implementations
•Sand Boxing
•File Storage
•Intents and Binders
•Signatures
•File Access
Types of System Permissions
Normal: A lower-risk permission, minimal risk to other applications or the system or the user,
automatically granted.
Dangerous: A higher-risk permission, access to private user data or control over the device,
displayed to the user and require confirmation before proceeding.
Signature: If the certificates match, the system automatically grants the permission without
notifying the user or asking for the user's explicit approval.
Source: http-//www.panozzaj.com/images/trello_permissions
http://www.smartphone.nl/wp-content/uploads/2015/05/App-machtigingen.jpg
Attacks
•Permissions
•Repackaging Apps
•Denial of Service Attacks
•Colluding
•Web View
•Man-in-The-Middle
•Malwares and Adware
•Certificates
An Example of Repackaging Attack
Source: Repackaging Attack on Android Banking Applications, Wireless Pers. Commun. (2013)
73:1421–1437
Malware in Android
Source: G DATA Mobile Malware Report Q4/2015
Malware in Android (contd.)
•Current situation: Experts identify a new Android malware strain every 11 seconds[1]
•Andr/PJApps-C
•Andr/BBridge-A
•Andr/BatteryD-A
•Andr/Generic-S
•Andr/DrSheep-A[2]
SSL Implementation in Android
SSL: JSSE
TrustManager
HostnameVerifier
Methods for Detecting Vulnerabilities
◦ Static Analysis: Decompiled apps using dex2jar and analyzed the code.
◦ Dynamic Analysis: Simulated three MiTM scenarios
S1: An advanced adversary that has its certificate installed on the user’s device.
S2: An SSL implementation accepting all certificates.
S3: An implementation not performing hostname verification correctly.
SSL Handshake
Results for Static Analysis
•93 of the 100 apps include SSL code.
•46 of the 93 SSL-enabled apps define a TrustManager that actually accepts all certificates.
•48 of the 93 apps include HostnameVerifier that accepts all hostnames.
•
41 of those 48 define a verifier that always returns true, while the other 7 define a hostname
verifier that returns true without any check.
Results for Dynamic Analysis
•Starting with S1 (an attacker having its certificate installed on the user’s device): 91 apps
establish login connections and give access to secure pages, leaking sensitive information.
•In scenario S2 (an attacker presenting an invalid certificate): 23 of the apps complete the
connection, with 9 of them leaking sensitive information.
•In scenario S3 (an attacker presenting a certificate with wrong credentials): 29 of the apps
establish a connection, with 11 of them revealing sensitive information.
•A total of 20 apps are vulnerable in all three scenarios, with 9 of them revealing sensitive
information.
Results for Dynamic Analysis (contd.)
•Only 9 of the 100 apps do not establish connections in any of the three attack scenarios
considered.
•Only 3 apps present the user with an error message indicating that the connection was refused
due to an SSL certificate error.
•Other apps keep loading indefinitely, crash, display a message trying to redirect the user to a
web browser, display a blank screen or some generic message.
Summary
•Apps with correct implementation of SSL pinning are not vulnerable to MiTM attacks
•Apps with a vulnerable TrustManager establish connections in the presence of an attack
•Apps using AllowAllHostnameVerifier or with a vulnerable HostnameVerifier also establish
connections.
•Apps are vulnerable to powerful adversaries with a certificate on the user’s device.
Proposed Solutions
•Should not rely on the user to fix problems, as users have often no idea as to what warnings
actually mean or what is the right course of action.
•Rather than using a TrustManager that accepts all certificates, developers should enable SSL
pinning.
•Use of self-signed root certificates. Developers should create a keystore with self-signed root
certificate to sign any number of end-entity certificates to be employed on servers. The keystore is
then used to create a TrustManager.
•The analysis of private information leakage and SSL vulnerabilities should be part of the vetting
process performed by app markets.
•Design meaningful mechanisms for visual feedback.
Reference
[1] G DATA Mobile Malware Report Threat Report Q4/2015
[2] http://securitywatch.pcmag.com/android/299152-top-five-android-malware-types
[3] Lucky Onwuzurike, Emiliano De Cristofaro, “Danger is My Middle Name: Experimenting with SSL
Vulnerabilities in Android Apps”, WiSec '15 Proceedings of the 8th ACM Conference on Security & Privacy
in Wireless and Mobile Networks, 2015