Two reports out in the last week have raised alarms about the vulnerability of popular applications to man in the middle attacks and other snooping. Alas - this isn’t really a new problem...and it isn’t limited to mobile applications either!
The presentations by researchers at the annual Conference on Computer and Communications Security (CCS 2012),
(https://www.sigsac.org/ccs/CCS2012/techprogram.shtml) in Raleigh, North Carolina both call out dangerous vulnerabilities in the way that Secure Sockets Layer (SSL) is implemented in a wide range of sensitive applications, including software used for conducting mobile- and online payments.
In the first, researchers from Leibniz University in Hannover, Germany, and Philipps University of Marburg, in Marburg, Germany reported on the results of an extensive audit they did of the Google’s Play Marketplace using an automated tool: MalloDroid, that scans mobile applications for vulnerabilities in the way two common cryptographic protocols: SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are implemented. According to their paper, 1,074 of the 13,500 popular free applications tested on the Play marketplace fell into that category.
A deeper analysis of 100 of the potentially vulnerable mobile applications by the same team found that 40% of those could be successfully exploited in a man in the middle attack. The researchers captured user credentials for services run by American Express, Paypal, Twitter, Google, Microsoft and Wordpress from poorly secured mobile applications in their experiment.
A second study, by researchers at The University of Texas at Austin and Stanford University found that many popular applications and middleware frameworks that have implemented SSL or TLS (SSL’s successor) inadvertently break or disable certificate validation. 
The researchers analyzed SSL libraries used with a wide range of popular applications, such as AOL’s AIM instant message client, as well as popular online shopping cart applications, including those from Zen Cart, Ubercar, osCommerce and PrestaShop. They found that those applications, as well as web services middleware from Apache and others that they are integrated with don’t properly validate SSL certificates when they establish a secure connection. That means those applications might be vulnerable to man-in-the-middle attacks that can steal sensitive transaction data or login credentials. Even when the shopping cart applications were secure, the researchers discovered that supporting software to operate the shopping carts provided by payments vendors like Amazon and PayPal had flawed SSL and TLS implementations.
The researchers found evidence of the problem with a number of prominent applications, including a mobile banking application for Chase Bank that was available on the Android Marketplace. The vulnerability would have allowed an attacker to read or modify the victim’s Chase login credentials and get access to his or her accounts. A mobile app from the hosting firm Rackspace was found to be vulnerable, as was the Mozilla Marketplace application. SDKs - software development kits - from Amazon and Paypal were also found to have insecure SSL and TLS implementations.
So what’s going on?
Both papers point to similar problems with the way that SSL and TLS are implemented in common applications.
The researchers behind the MalloDroid tool analyzed the networking API (application program interface) calls that mobile applications makes looking for sloppy implementation of SSL and TLS. They found it. Of 1,887 unique SSL certificates they analyzed, 162 - or 8.6% - failed verification using Android's default verification strategies. Furthermore, 42 of the certificates were self-signed (a big red flag). Other apps used certificates that were expired, or contained links to web hosts whose certificates were expired. In addition, the researchers found 332 Android applications with links to 112 certificates that failed hostname verification, according to the report. All of these problems lead to certificates that can’t be trusted by the device or end user. They are indistinguishable from the certificate an attacker would present when launching a man in the middle attack (MITM). The device or end user therefore cannot detect a MITM attack, one of the key attacks SSL and TLS were designed to prevent.
The researchers from The University of Texas and Stanford reached similar conclusions. Many SSL libraries, including OpenSSL and JSSE’s SSLSocketFactory, aren’t set up by default to check that the name of a certificate presented by a server corresponds to the hostname to which the client is connecting. As a result, many applications fail to do hostname verification at all, including ubiquitous components like Apache’s HttpClient Version 3.* and Weberknecht in Java, and urllib, urllib2 and httplib in Python.
Shocking - but it shouldn’t be.
In fact, Veracode called out this very same problem two years ago in its list of the Top 10 Mobile Application Risks. There it is at #9: “Unsafe Sensitive Data Transmission,” where we noted that “SSL is one of the best ways to secure sensitive data in transit.” But that compromise of encrypted communications is possible if “the app does not fail on invalid certificates.”
Experts at Veracode and elsewhere have also frequently warned about the security dangers inherent in third party code, such as that offered from Paypal and others. Past State of Software Security Reports have found that up to 70 percent of so-called “internal” applications submitted to the company for analysis contained code from third party suppliers. That code, often, was the source of security vulnerabilities. 
Have things improved? Not really. One finding in Veracode’s upcoming State of Software Security Report (V5) is that cryptographic flaws are the most common flaws affecting mobile applications on the Android platform. Veracode found evidence of crypto problems of some kind in 64 percent of the Android apps they evaluated - ahead of even CRLF (carriage return line feed) Injection attacks.
The question is: what to do about it?
While its easy to consider the prospect of SSL implementations that don’t bother with hostname verification and blame developers for shoddy workmanship, the truth is that application developers aren’t security experts - let alone encryption experts. Still, many development tools and cryptographic APIs treat them as if they were: 
leaving important security features disabled by default (as in this case) or giving developers too much leeway in configuring SSL and TLS within their application.
In the wake of the most recent reports on weak SSL and TLS implementations, the security firm ISEC Partners has released tools to help developers assess whether their creations do proper certificate and hostname validation. That’s a start. But if companies are serious about snuffing out embarrassing security holes in applications - mobile and otherwise - they’ll start thinking about ways to make good security effortless for both developers and their customers.
The designers of crypto APIs need to make it much easier to implement SSL and TLS correctly and much more difficult to do it wrong. Development teams need to make SSL/TLS certificate validation a requirement and QA teams need to test for it. Automation and manual testers can certainly help.
