Attackers can slip malicious code into many Android apps via open Wi

A vulnerability affecting older versions of Google's Android operating system may make it possible for attackers to execute malicious code on end-user smartphones that use a wide variety of apps, researchers said.

The weakness resides in a widely used programming interface known as WebView, which allows developers to embed Web-based content into apps used for banking, entertainment, and other purposes. Many apps available on the official Google Play market don't properly secure the connection between the WebView component on a phone and the Web content being downloaded, researchers from UK-based MWR Labs recently warned. That makes it possible for attackers who are on the same open Wi-Fi network as a vulnerable user to hijack the connection and inject malicious code that can be executed by the phone.

"The lowest impact attack would be downloading contents of the SD card and the exploited application's data directory," the researchers wrote in an advisory published earlier this week. "However, depending on the device that was exploited this could extend to obtaining root privileges, retrieving other sensitive user data from the device or causing the user monetary loss."

Researchers from several other security firms said they are also aware of the weakness, which can affect apps that run on Android versions 4.1 and earlier and don't make proper use of the secure sockets layer (SSL) encryption protocol. Elad Shapira, a researcher with antivirus provider AVG recently demonstrated how an app that has already been given permission to access SMS capabilities (a common setting with many legitimate apps) could be hijacked by malicious JavaScript code that sends expensive text messages to premium services.

Google representatives declined to comment for this story.

Cross-device attacks

Einar Otto Stangvik, a security consultant with Indev.no, said he has identified Android banking apps used in Norway that are also open to remote-code attacks that make users more susceptible to phishing attacks. He theorized that attackers might exploit the weakness by planting malware on a target's PC that hijacks a smartphone when both devices are connected to the same network.

"I am confident that we'll soon see many more cross-device attacks, where a compromised computer starts targeting cell phones on the internal network," he wrote in an e-mail to Ars. "That is what makes the JavaScript interface leak scary, along with the amount of poor uses of SSL, or worse still: no SSL at all."

The vulnerability stems from JavaScript-based programming interfaces exposed in many Android apps. The interfaces are the code equivalent of a highly restricted bridge that links sensitive parts of Android's Dalvik virtual machine to the Web. If the interface isn't fully contained inside an SSL connection, it's possible for hackers to mimic the legitimate website and, in effect, gain unauthorized access to the bridge. From there, an attacker can inject malicious JavaScript into the app. MWR Labs researchers reverse engineered the 100 most popular apps on Google Play and found 62 of them that are "potentially vulnerable" to the exploit. Potentially vulnerable apps as defined by the researchers were those apps that were developed using libraries or programming interfaces known to expose unprotected JavaScript commands to a variety of third-party ad networks under many but not all circumstances.

The reports of the weak apps come almost a year after two academic reports uncovered wide-ranging deficiencies in the cryptographic protections in smartphone software. One found that Android apps used by as many as 185 million people contained holes that leaked log-in credentials and other sensitive data even though they were supposed to be protected by SSL. The other revealed a variety of apps running on Android and PCs that were fooled by fraudulent SSL certificates. It's possible similar defects could fail to protect code exposed in WebView objects even when developers think they're properly contained inside an SSL channel.

The good news

While the vulnerability is potentially serious, there are several limitations that minimize the damage attackers can do when exploiting vulnerable apps. Chief among them is the fact that Android's permissions and sandboxing mechanisms prevent most Android apps from installing other apps without explicit permission from the end user. That will probably prevent the technique from being used to install malicious apps in most cases. As a backup, the "Verify Apps" setting available in all versions of Android could also be updated to stop malicious installations should attackers find a way to bypass the permissions and sandbox protections.

What's more, Tim Wyatt, director of security engineering at smartphone security provider Lookout, said some researchers may be exaggerating the threat of attackers obtaining root privileges unless they can exploit a second, unknown vulnerability in Android's permissions and sandbox protections.

Another mitigating factor: beginning with version 4.2 of Android, Google added new security enhancements that among other things introduced something called the @JavascriptInterface annotation. The function makes it easier for a developer to restrict the methods that can be called on a scriptable object. Unfortunately, it requires the developer to take explicit action to do so. If the developer fails to heed that advice, the app will remain vulnerable.

Still, while the weakness can largely be prevented in Android 4.2, users are protected only if developers of each app follow best practices. Additionally, the vast majority of users remain locked into carrier contracts that prevent them from upgrading. That means it's up to app developers to follow best practices such as limiting the functionality exposed in JavaScript and securing communications channels for any WebView-exposing scriptable objects using SSL or its sister protocol, known as transport layer security (TLS). And as the MWR Labs researchers discovered, many widely used apps can't be trusted to practice those common-sense guidelines.

"Exploiting this would require getting access to an exposed JavaScript object, and so in most cases, that would require hijacking content delivered by a server," Tim Wyatt of Lookout told Ars. "It is therefore pretty critical that developers using JavaScript callbacks secure the delivery channels properly (e.g. using TLS with a proper certificate chain to prevent man-in-the-middle attacks)."