The team also found a set of 20 apps that allowed all host names -- that is, accepted certificated regardless of the subject name, such as permitting an app seeking to connect to paypal.com to accept a certificate for an entirely different domain. The apps leaked information like credentials for different services, emails, text messages, contact data, bitcoin-miner API keys, and premium content, as well as access to online meetings.
Among these apps was an antivirus software with an install base as high as 1 million that updated its signatures via a broken SSL connection. "Since it seems that the connection is considered secure, no further validation of the signature files is executed by the app. Thus, we were able to feed our own signature file to the antivirus engine," according to the researchers.
The team also found apps that were vulnerable to SSL stripping. One culprit is the use of Android's webkit.WebView, which lets apps start browsing sessions with HTTP before switching over to HTTPS; the team found webkit.WebView in 11,038 apps. "Two noteworthy examples vulnerable to this attack are a social networking app and an online services client app. "The two apps start the connection with a HTTP landing page, and we could rewrite the HTTPS redirects to HTTP and thus catch the login credentials for Facebook, Yahoo, and Google."
Compounding the problem: Android's default browsers -- as well as available alternatives -- don't provide HTTPS-Everywhere-like features out of the box.
Finally, the researchers found plenty of instances of "lazy SSL use." Developers can customize the way their wares implement SSL validation, aka SSL pinning. For example, a developer could limit an app to connect to select certificate authorities (such as paypal.com and its sister sites), rather than letting it connect to any and all sites.
To assess the effects of lazy SSL usage, the team picked 20 high-profile apps that had not been prone to previous MITM attacks. The researchers then installed their own root CA certificate on the test phone and set up an SSL MITM proxy that automatically created CA-signed certificates. They ran MITM attacks against the apps and found that only two of the 20 made use of SSL pinning and were thus safe from attacks. "All other apps trust all root CA signatures, as long as they are part of Android's trust anchors, and thus were vulnerable to the executed attack," according to the report.
While part of the responsibility of making apps secure lies with developers, the researchers proposed several changes to Android that would further reduce these types of vulnerabilities. Among them:
- Disallowing custom SSL handling completely and forcing developers to use the standard library implementations provided by Android's APIs
- Integrating an Android-version of HTTPS-Everywhere into communication APIs
- Introducing a more fine-grained policy model with separate permissions for INTERNET_SSL and INTERNET_PLAIN
- Introducing policies like GSM_ONLY, NO_OPEN_ WIFI, or TRUSTED_NETWORK
- Adding to Android a form of visual security feedback to help users determine whether or not apps are communicating via a secure channel
- Integrating MalloDroid into app installers to perform static code analysis at install time
This story, "Legit Android apps rendered unsafe by poor programming, SSL misuse," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.