Legit Android apps rendered unsafe by poor programming, SSL misuse

Security-conscious Android users who diligently download malware-free applications from reputable marketplaces are still susceptible to data theft thanks in part to lazy, careless, or otherwise poor programming practices. We’re not just talking about suspect, bottom-dwelling apps of the Google Play Market, either: Around 8 percent of the store’s 13,500 most-popular free apps — representing more than 185 million installs worldwide — contain SSL/TLS code that’s potentially vulnerable to MITM (man in the middle) attacks through which cyber thieves can swipe user’s log-in information, credit card numbers, documents, and other sensitive information.

A team of Germany researchers conducted a recent study (PDF) called “Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security .” As the title implies, the team discovered various forms of SSL/TLS misuse among a host of popular Android apps. Developers commonly embrace SSL or TLS to protect data during communication on the Android platform, according to the researchers; unfortunately, developers don’t always implement SSL correctly for its intended usage and threat environment.

For the study, the team analyzed 13,500 popular Android apps using MalloDroid, an extension of the Androguard reverse engineering framework. MalloDroid is capable of detecting potential vulnerabilities for MITM attacks, such as checking which types of permissions an app requires, how an app uses networking API calls, and how it treats HTTP and HTTPS. The tool also downloads and evaluates SSL certificates and assesses validation.

Of the 13,500 scanned apps, the team found 1,074 that were potentially vulnerable. The researchers went on to manually audit 100 of those apps, and they were able to successfully launch MITM attacks against 41 of them to gather a variety of sensitive information.

For instance, developers may choose for their apps to trust all certificates, regardless of who signed them or for what subject they were issued. They also may choose to allow all hostnames, meaning the application forgoes checking whether a certificate was issued for the device’s address. Further, developers have the luxury of choosing to mix secure and insecure connections in the same application — or to not use SSL at all, according to the researchers.

“This is not directly an SSL issue, but it is relevant to mention that there are no outward signs and no possibility for a common app user to check whether a secure connection is being used,” according to the report. “This opens the door for attacks such as SSL stripping [i.e. replacing https with insecure http].”

These misuses or nonuses of SSL and TLS open the door to the aforementioned MITM attacks, both passive — where the attacker can only eavesdrop on communication — and active, where the attackers can tamper with the communication.

Specifically, researchers found that 21 of their 100 selected apps were set to trust all certificates. By giving their MITM attack proxy a self-signed certificate for the attack, the researchers were able to swipe such information as log-in credentials, webcam access, and banking data.

They noted one particular generic online banking app with as many as a half million users that uses separate classes for each bank containing different trust implementation. Twenty-four of the 43 banks supported were not protected from the team’s attack. (The team didn’t specify the name of the app, presumably to prevent widespread exploitation of the vulnerability.) The team also found a browser with an install base between 500,000 and 1 million users that mishandles SSL and trusts all certificates, thereby leaking any data the user enters.

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.