1 / 22

Why Eve & Mallory Love Android

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

tia
Télécharger la présentation

Why Eve & Mallory Love Android

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Why Eve & Mallory Love Android An Analysis of Android SSL (In)Security

  2. 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

  3. 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

  4. Able to inject virus code into an antivirus app to disable virus detection and detect arbitrary apps as a virus.

  5. Able to capture credentials from American Express, Paypal, various bank accounts, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, etc

  6. 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.

  7. 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)?

  8. 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

  9. 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.

  10. 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

  11. 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.

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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.

More Related