Presentation Material
Abstract
Mobile SSL Failures Failure to validate Certificate Authorities - Approximately 40 well-known apps Failure to validate Certificate Hostnames - Approximately 40 well-known apps Failure to encrypt at all - Tens of millions passwords and credit cards Recent FTC settlement related to this topic Review of why physical security isn’t assured with mobile - Smudge attacks
- No screen lock
- Screen lock bypass - Creating invisible MitM attacks
- Creating persistent MitM attacks SSL Session caching exploit A fool-proof defensive coding approach We will discuss how prevalent SSL certificate validation failures are in very popular applications. We will show how some popular applications failed to encrypt traffic at all resulting in the leakage of tens of millions of users’ data. We will cover recent U.S. Government penalties that companies who fail to protect data may be subject to. We will discuss a new attack, that is particular applicable to mobile and especially on the Android platform, which potentially allows for a persistent MitM attack that is undetectable on the device itself. Lastly, we will cover how organizations can implement a fool-proof method to protect themselves against this mistake.
AI Generated Summary
The presentation examined systemic failures in TLS/SSL implementation within popular mobile applications for Android and iOS. The core issue identified was the improper validation of server certificates, primarily manifesting in two ways: completely disabling certificate authority validation or failing to verify that the certificate’s hostname matches the intended server.
Through testing using a transparent proxy (Burp Suite) and custom certificates, the researchers found that approximately 10% of top-tier Android applications and a smaller number of iOS apps were vulnerable to undetectable man-in-the-middle attacks. Affected categories included major retailers, airlines, financial services (payment processing and banking), two-factor authentication apps, VPN clients, and enterprise software. The vulnerability allowed attackers on public Wi-Fi or rogue access points to intercept and decrypt sensitive data, including login credentials, session tokens, and payment information, without any user warning.
A key technical finding was that many applications accepted certificates issued by any trusted certificate authority for any domain, or accepted self-signed certificates without validation. Testing involved either installing a proxy’s CA certificate on the device or, for hostname validation flaws, obtaining a valid certificate for a different domain from a public CA like StartSSL and configuring the proxy to present it.
The practical implication is a critical breakdown in mobile application security development life cycles. Developers often disable validation for testing convenience and fail to re-enable it, or misunderstand API usage. The talk emphasized that proper TLS validation is non-negotiable and must be rigorously tested. Organizations should incorporate these specific TLS validation checks into mobile application security assessments, as the presence of a lock icon or claims of encryption do not guarantee protection against interception. The widespread nature of the flaws across high-profile apps indicates a pervasive industry-wide oversight.