Catching Mobile Encryption Flaws

More than 80-percent of mobile devices contain encryption flaws and applications written in PHP, ColdFusion and Classic ASP are most likely to have serious flaws according to a report by Veracode. These flaws in mobile apps present a grave risk for those who use them on untrusted wireless networks.

 

I believe that a common source of this problem is that developers add logic to specifically disable certain SSL features (namely certificate validation) so that the app can be tested internally without spending money on certificates issued by trusted authorities. This is fine, unless the code to bypass certificate checks is not removed before releasing the app for distribution.

 

SSL implementation failures can also extend beyond exposed information by allowing network level adversaries to inject malicious content into vulnerable applications. This can be a powerful infection vector as JavaScript running within an app may not always be bound to the same restrictions as it would within a browser due to variations on how the same origin policy is applied.

SSL is, for the most part, secure, but one slight programming error, as with Apple’s SSL/TLS snafu, can make this security an illusion. In Apple’s case, a duplicated line of code altered the program flow such that the signature within a ServerKeyExchange was never validated, but most SSL failures are much easier to understand and exploit. The more typical scenario occurs when a developer fails to validate that a certificate is from a trusted authority thereby allowing traditional SSL man-in-the-middle attacks.

With a web browser, it is generally quite easy to recognize when a third party is tampering with a secure connection. This is due to warning pages presented by browsers when something is fishy with the SSL certificate, such as a certificate that has not been signed by a trusted authority. On mobile applications however, a warning is not always displayed and many times, the device does not recognize when something is amiss.

Over several years of working with SSL implementations on smartphones and other embedded devices, I have found a variety of techniques for identifying vulnerable systems. One such technique I use for Android involves extracting code and looking for what I refer to as the naive trust manager implementation.  I described this technique at DEF CON 22 along with how I used it to find flaws in the Uber car service, a telephony app using GMail credentials, and even the app for interfacing with my car's smart features much like Samy Kamkar's OnStar hack at DEF CON 23.  

While this technique is very effective at finding holes and can be applied in an automated process, there is no substitute for real-world testing. For some devices the only way to perform a real-world test is to actually physically connect the device through a hostile network when it comes to smartphone testing, VPN technology is an ideal solution.

 

Setting up a VPN endpoint is relatively easy and configuration guides exist for connecting Android, iOS, or various other mobile devices.  A few ip tables rules on the VPN router then make it possible to direct encrypted traffic to an interception tool like Moxie Marlinspike's ssl sniff utility. 

 

With a web browser, it is generally quite easy to recognize when a third party is tampering with a secure connection. This is due to warning pages (known in the industry as browser interstitials) presented by browsers when something is fishy with the SSL certificate, such as a certificate that has not been signed by a trusted authority or when deprecated cryptography standards are used. 

On mobile applications however, a warning is generally not displayed. Instead, the application will either report a lack of connectivity or simply accept the tampered connection and proceed to transmit data. I discovered that apps already running on my phone could be subverted to gain access to my Google account, payment card details, location data, and even my car.

 

Here are some tips to test for mobile encryption flaws:

- Install a Linux distribution of your choice.

(*) I am using Ubuntu 12.04 hosted on Digital Ocean’s $5/month VPS

- Configure the server as a VPN gateway.

(*) PPTP is easy to setup as documented by both Ubuntu & Digital Ocean.

- Install Moxie’s Sslsniff is easy to build from source or install from a repo. (i.e apt-get install sslsniff)

- Per the instructions for sslsniff, enable an ip tables rule to redirect SSL traffic

(*) ip tables -t nat -A PREROUTING -p tcp –destination-port 443 -j REDIRECT –to-ports 4443

- Run sslsniff as described in the README – running in authoritative mode is a good starting point

(*) sslsniff -a -s 4443 -w /tmp/sslsniff.log -c /usr/share/sslsniff/certs/wildcard

- Connect the Android device to the VPN using the credentials configured in step 2

(*) Typically Settings->Wireless & Networks->More->VPN and touch the ‘+’ at the top right.

- Monitor the sslsniff output specified with the ‘-w’ flag

(*) tail –f /tmp/sslsniff.log

 

From here, you can test that your setup by opening the browser on your Android device and going to https://www.tripwire.com/ and verifying that a certificate error is presented. The sslsniff log should reflect a failed connection attempt similar to the following:

1395677268 DEBUG sslsniff : SSL Accept Failed!

1395677268 DEBUG sslsniff : Got exception: Error with SSL connection…

 

The test environment is now ready. When running an app that is vulnerable to SSL MITM, you will see complete requests and responses logged by sslsniff. Should you find an app that exposes sensitive information, report the issue to the app developer so it can be addressed.