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
Attacks •Permissions •Repackaging Apps •Denial of Service Attacks
•Colluding •Web View •Man-in-The-Middle •Malwares and Adware •Certificates
Malware in Android •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.
Steps Involved •SSL Handshake
•SSL MiTM Attacks •SSL Implementation in Android •SSL Pinning
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
