Phoney SSL Connection: Bad Coding Practice Could Lead to Information Leak


The Trustlook security team has recently discovered a number of apps that use the “TrustAllCerts” method in the SSL connection, which renders the secure connections built in these apps meaningless. An attacker could use a self-signed certificate to establish a connection with the victim, and become the Man-in-the-Middle for all the network traffic between the victim and the HTTPS server (In a real-world attack, this can happen on a ARP Spoofing attack, or on a compromised router). Afterwards, the attacker could intercept or even forge the network traffic (e.g. Username and Password submitted via form) sent in a SSL connection.

The root cause for this vulnerability is because some developers reloaded the checkClientTrusted() and checkServerTrusted() methods upon the SSL connection and made them return without actually checking. It is convenient under some certain scenarios (e.g. debugging), but after reloaded these methods, the app would completely neglect the validity of the certificate. According to our scanning result on Google Play, a large number of apps and SDKs have reloaded those methods, and some of them will leak sensitive information.

Untitled drawing

Take the Skout Android app as an example, which is a popular social app with 10M-50M installs:

Screen Shot 2014-06-11 at 10.18.40 PM
Screen Shot 2014-06-11 at 10.19.27 PM

The code that disables the certificate check(click to enlarge):

Screen Shot 2014-06-11 at 10.40.38 PM

We wrote a Proof-of-Concept tool, which could used self-signed certificate to establish a Man-in-the-Middle connection and sniff Skout’s network traffic. As you can see, the plaintext username and password could be intercepted: