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:

Risks Involved User Privacy Violations Call Logs 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-//

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] [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