Why Eve & Mallory Love Android An Analysis of Android SSL (In)Security Android Apps Android is the most used Smartphone OS in the world with 48% market share Over 400,000 apps in the Google Play Market Android apps have been installed over 10 billion times Apps process a lot of privacy-related user data and have valid reasons to transmit it over the internet Problem Apps are not forced to use SSL Apps are allowed to customize SSL so many Android apps use SSL incorrectly and are vulnerable to MITM attacks User has no idea when Android uses SSL Users are misinformed about the security of the connection or misinterpret warning signs Able to inject virus code into an antivirus app to disable virus detection and detect arbitrary apps as a virus. Able to capture credentials from American Express, Paypal, various bank accounts, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, etc Secure Sockets Layer (SSL) Used to establish a secure connection between a client and server. Client receives a X.509 certificate containing the server’s public key that is signed by a certificate authority. Client should validate certificate but this is not yet required by the SSL and X.509 standards. SSL Validation Checks Does the subject (CN) of the certificate match the client’s desired destination? Is it a trusted Certificate Authority (CA)? Is the signature correct? Has the certificate expired? Has the certificate been revoked? Check Certificate Revocation Lists (CRLs)? Use Online Certificate Status Protocol (OCSP)? SSL Misuses in Android Trusting all certificates Disregards the signer of the certificate and the subject Allowing all hostnames Does not check if certificate was issued for a given address Trusting many Certificate Authorities Attacks on CAs in 2011 makes trusting 134 root authorities questionable Mixed-Mode / No SSL Can mix secure with insecure connections or use no SSL Man-in-the-Middle Attacks MITMA: an attacker can intercept messages between conversation partners Passive (eavesdropping) vs. active (tampering) Mixed-Mode/No SSL allows for passive MITMA by eavesdropping on non-protected communication or allowing for SSL stripping SSL stripping avoids SSL by replacing https:// with http:// Can occur if a browsing session begins using HTTP and switches to HTTPS via a link or a redirect. Evaluating Android SSL Usage Built MalloDroid to perform static code analysis on 13,500 free apps from Google’s Play Market Permissions Request INTERNET and other privacy related permissions Network API calls HTTP transport and Non-HTTP (direct socket connections) HTTP vs. HTTPS HTTP only, mixed-mode (HTTP and HTTPS), or HTTPS only HTTPS available Able to establish a secure connection to the HTTP urls? Deployed certificates Evaluates SSL certificates of hosts referenced in apps SSL Validation Android SSL Usage HTTP vs. HTTPS 74% could have used HTTPS instead of HTTP 46% mixed-mode, 43% HTTP only, 0.8% HTTPS only Deployed SSL Certificates 17.3% bypass effective SSL verification by accepting all certificates or all hostnames for a from a trusted CA Many apps include HTTPS URLs for hosts that have certificates that are either expired, self-signed, have mismatching CNs (site’s common name) or are signed by non-default-trusted CAs. MITMA: Trusting All Certificates 51% use the INTERNET permission in addition to permissions to access privacy related information Trusting all certificates Attack: MITMA proxy with self-signed certificate Over half of the banking apps tested leaked login credentials, affecting an install base of 100,000 – half a million users Windows Live Messenger service app with 10-50 million users leaks login credentials for email, messaging, or SkyDrive cloud storage MITMA: Trusting All Hostnames Attack: Cert for an unrelated domain signed by startSSL Apps, including one used by 82% of Fortune 500 companies, leaked credentials for sensitive data Antivirus app updated virus signatures via broken SSL Install base of 500,000 – 1 million users Trusted that connection was secure and did no further validation Able to send empty signature database that was accepted without informing the user Able to create a virus signature for the antivirus which caused it to recognize itself as a virus and delete itself Overcoming MITMA SSL stripping Used to go to secure login page from insecure landing page Apps with 1.5 million - 6 million installs leak login credentials for Yahoo, Facebook, and Google Overcome by forcing HTTPS Lazy SSL Poor SSL validation Overcome with SSL pinning A custom list of trusted CAs or a custom list of specific certificates Feedback to Users Apps don’t always display visual feedback about whether the communication is secure. Email clients did login and registration in SSL, but sending and receiving mail defaulted to HTTP without alerting the user. Apps indicate that the connection is secure but are vulnerable MITMA when they fail to establish an SSL connection or do SSL validation Replay attack when the logins are encrypted but not fresh Apps that did prevent MITMA failed and gave confusing error messages Countermeasures: OS Solutions Enforced certificate checking Disallow custom SSL handling by forcing users to use standard Android API implementation HTTPS everywhere Integrated into communication APIs to prevent SSL stripping Improved permissions and policies Separate permissions for SSL and PLAIN so apps can specify Policies like GSM_ONLY, NO_OPEN_WIFI, TRUSTED_NETWORKS to prevent MITMA Visual security feedback Properly inform users about connection type and security status. MalloDroid installation protection Integrated into app installers to warn user of unsafe apps Countermeasures: Other Solutions App Market Solutions MalloDroid could be integrated into app market Automatically checks apps Could prevent apps from entering market or display the warnings in the app description Standalone Solution: The MalloDroid App and Service Easily deployed Allows user to perform checks on apps before install Conclusion Google apps handle a lot of personal information for a lot of different people Users wrongly assume, or are incorrectly informed, that they are transmitting your securely when apps are not required to use SSL Apps are vulnerable to MITMA by failing to correctly validate the SSL certificates or by mixing HTTP with HTTPS Instead of allowing for SSL customization, proper certificate validation should be enforced, HTTPS should be used everywhere, and permissions and policies should be separated so that apps can better protect users’ data. Users should be better informed about how secure the connection is.