IBM X-Force Finds Apache Cordova Vulnerability That Might Expose Nearly 5.8% of Android Apps

The IBM Security X-Force Research team has uncovered a serious vulnerability that affects many Android applications built on the Apache Cordova (previously PhoneGap) platform. According to AppBrain, this affects 5.8 percent of Android apps. While 5.8 percent might sound like a low percentage, some widely-used Android applications are built on Cordova. In fact, researchers found that out of the 248 applications tested containing the keyword “bank,” 25 apps were built using Cordova — roughly 10 percent. This means an attacker could steal users’ banking credentials and perform transactions, such as withdrawing or transferring funds from their bank account to another account.

Those millions of users who use Android Cordova-based apps are at risk of having sensitive information, such as their login credentials, exfiltrated or stolen from these applications, allowing attackers to impersonate them, access their accounts and even make purchases on their behalf. With IBM’s Cyber Security Intelligence Index finding that 95 percent of successful attacks or security incidents were caused by human error, hackers continue to aggressively seek out such vulnerabilities to exploit.

Before announcing this vulnerability, IBM Security’s team adhered to its responsible disclosure policy and privately reported security vulnerabilities to the Cordova team. The result is that patches are available in the latest Cordova version 3.5.1.

The IBM team’s analysis shows it is extremely easy for an attacker to exploit this vulnerability. Under certain circumstances, it can also be remotely exploited to steal sensitive information, such as cookies associated with the Cordova-based application, by naïve mobile browsing to a malicious website (better known as a drive-by exploitation).

The Apache Cordova vulnerabilities enable Cross-Application Scripting, i.e., the execution of a malicious JavaScript (JS) code in the context of Cordova-based apps. In addition, due to other vulnerabilities that we have detected within Cordova, such code can exfiltrate information back to the attacker.

We strongly recommend that all developers upgrade to the latest Cordova version (3.5.1) and use the mitigation detailed in our white paper.

Since IBM Worklight uses Apache Cordova, it is affected as well. We at IBM are committed to the security of our clients; thus, fixes to address this security exposure in Worklight have been published to Fix Central for our 5.0.6.x, 6.0.0.x, 6.1.0.x and 6.2.0.x releases.

Watch the recorded Demo: Interactive Application Security Testing on Mobile Attacks

A typical attack will be as follows:

Consider Bob, a user of the fictitious bank Altoro Mutual, which is known for its low security standards. Bob has Altoro’s app installed on his Android device and has recently used this app to access his Altoro bank account. Mallory, the attacker, who is eager to get some money from Bob, has managed to lure Bob to browse her malicious website through a well-crafted phishing email. Alternately, Mallory could have exploited an existing XSS vulnerability in a popular website in order to run malicious JavaScript code in Bob’s browser. This malicious JavaScript can then exploit the Cordova vulnerabilities to steal Bob’s Altoro Mutual login credentials and other sensitive information found in Altoro’s app. From this point forward, Mallory can impersonate Bob at Altoro Mutual by using the stolen credentials and performing transactions, such as funds withdrawals, from his Altoro bank account.

Below is a video by David Kaplan (@DepletionMode) of my team, remotely exploiting the Altoro Mutual application that I developed for the purpose of this demonstration:

https://www.youtube.com/watch?v=_V0hPTYa6cg

Vulnerability Matrix

Technical Details

Android Application Security Basics

Android applications are executed in a sandbox environment. The sandbox ensures data confidentiality and integrity, as no app can access sensitive information held by another without proper privileges. For example, Android’s stock browser application holds sensitive information such as cookies, cache and history, which shouldn’t be accessed by third-party apps.

The sandbox relies on several techniques, including per-package Linux user-ID assignments. Thus, resources such as files owned by one app cannot be accessed by default by another app.

While sandboxing is great for security, it may diminish interoperability; apps would like to talk to each other. Going back to the browser example, the browser would want to invoke the Google Play App when the user browsed to the Google Play website.

In order to support this kind of interoperability, Android provides high-level inter-app communication mechanisms. The communication is usually done using special messages called Intents, which hold both the payload and the target application component. Intents can be sent explicitly, where the target application component is specified, or implicitly, where the target is left unspecified and is derived by Android according to other Intent parameters such as its URI scheme, action and category.

The Inter-App Communication Attack Surface

Application components that open the gate to incoming Intents increase their attack surface. Such components can be attacked locally by malware, as shown by the next diagram:

More severely, under certain circumstances, they can be attacked remotely as well by a simple click to a malicious website that serves the exploit code:

The Embedded Browser (WebView) and Cross-Application Scripting (XAS)

The WebView object, provided by the Android Framework, allows developers to embed a browser within their own apps. This functionality is great for developing portable apps and is the basis of Apache Cordova.

The loaded Web page of the WebView object is controlled by the WebView.loadUrl API. For example, in order to open the IBM website, the developer can write the following code:

String url = "http://www.google.com";
WebView webView = ...
webView.loadUrl(url);


But what are the implications of an attacker’s controlled URL? Consider the following code:
String url = getIntent().getStringExtra("url");
WebView webView = ...
webView.loadUrl(url);


If attackers’ controlled data propagates to this Intent ‘url’ extra parameter, then this code becomes vulnerable to Cross-Application Scripting. Why? Because the attacker can control the ‘url’ extra parameter to load the WebView object with a malicious JS code.

Prevention of XAS Exploitation

Just like Buffer Overflow vulnerabilities, there are some things the execution environment (in this case, the WebView object) can do in order to reduce the probability and impact of successful exploitation.

First, JavaScript is off by default and must be explicitly enabled by calling WebSettings.setJavaScriptEnabled(true). Without JavaScript, there is nothing much the attacker can do except maybe conduct a phishing attack.

Second, code running in the WebView object is subject to the renowned Same-Origin Policy, where code belonging to some domain can only access the DOM of that specific domain. This greatly reduces the appeal of ‘javascript’ URI scheme payloads and is only interesting if the attacker can force a change of the WebView’s URL after it has already been preloaded with some other URL (in 2011, we disclosed CVE-2011-2357, a XAS vulnerablity in the Android browser that abuses this behavior) or if there are some JavaScript-to-native-code bridges.

The attacker is left with another option: abusing the file URI scheme. In the past (Android 4.0 and below), JavaScript code loaded with file URI had universal access to any origin, including local files. This is clearly bad since it allows a trivial theft of sensitive files related to the vulnerable app. Google had realized this threat and provided a third mechanism in Jelly Bean (Android 4.1) and above to prevent exploitation: a pair of APIs that restrict the functionality of JS code loaded from file URIs (WebSettings.setAllowUniversalAccessFromFileURLs and WebSettings.setAllowFileAccessFromFileURLs). Both settings are disabled by default and prevent access to any origin and access to other files, respectively.

The Cordova XAS Vulnerabilities

Attackers can influence the URL of Cordova’s WebView in two different ways.

Let’s take a look at the first issue:

public void loadUrl(String url) {
 if (url.equals("about:blank") || url.startsWith("javascript:")) {
  this.loadUrlNow(url);
 } else {
  String initUrl = this.getProperty("url", null);
  // If first page of app, then set URL to load to be the one passed in
  if (initUrl == null) {
   this.loadUrlIntoView(url);
 }
  // Otherwise use the URL specified in the activity's extras bundle
  else {
  this.loadUrlIntoView(initUrl);
  }
 }
}


First, the CordovaWebView.loadUrl(String url) and CordovaWebView.loadUrl(String url, int time) consume the Intent’s ‘url’ extra parameter instead of the ‘url’ argument. The first method does that only if the argument’s URI scheme is not JavaScript and the URI is not ‘about:blank’. Therefore, if the ‘url’ extra parameter can be influenced by the attacker (which is often the case), the WebView’s URL can be controlled.

The second issue relates to the ‘errorurl’ Intent extra parameter and is very similar despite the fact that it is used only if there is an error when loading the original URL (such as connectivity issues). More about the second issue can be found in our white paper.

From a Theoretical Vulnerability to a Feasible Exploit

Exploiting XAS vulnerabilities is harder if the prevention mechanisms mentioned above are enabled.

Unfortunately, due to the nature of Cordova-based apps, this is not the case. Let’s take a look at the following code, which is in charge of the WebView’s setup (CordovaWebView.setup):

private void setup() {
 ...
 WebSettings settings = this.getSettings();
 settings.setJavaScriptEnabled(true);
 ...
 if (android.os.Build.VERSION.SDK_INT > android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH_MR1) {
  Level16Apis.enableUniversalAccess(settings);
 }

 @TargetApi(16)
 private static class Level16Apis {
  static void enableUniversalAccess(WebSettings settings) {
   settings.setAllowUniversalAccessFromFileURLs(true);
  }
}

JavaScript must obviously be enabled because Cordova is all about portable apps that can access native facilities using JavaScript bridges. In addition, in order to allow local files to communicate with the outside world, universal access from file URIs is allowed.

The fact that JavaScript is enabled and universal access is allowed creates an opportunity for exploitation both remotely (drive-by) and locally by malware. In this post, we will only demonstrates the remote attack; the local one can be found in the advisory.

Remotely Exploiting Cordova

Under certain circumstances (again, for full details, see our white paper), Cordova vulnerabilities can be exploited remotely by a simple click on a naïve website. From this point forward, the exploitation is fully automatic.

The goal of the attacker is to steal some sensitive files associated with the vulnerable Cordova-based apps.

In this attack, we abuse the file:// URI scheme and the fact that JavaScript and universal access from file URIs are allowed in Cordova.

The attack’s outline is as follows (full details can be found in the advisory):

1. Naïve Browse The victim browses to a malicious website.
2. Drive-By Download: The malicious website automatically causes the victim’s browser to download an HTML file to the victim’s SD card. The idea is to trick the browser to think the HTML file is not viewable. In some browsers, this can be done by including a Content-Type header with some binary meta-type.
3. Vulnerability Exploitation: The malicious website also causes the vulnerable Cordova-based app to load the downloaded file in its WebView object. This is done by using the Intent URI scheme, which causes the browser to generate an Intent object. This Intent triggers one of the Cordova vulnerabilities by referring to the downloaded attacker’s HTML file using a file URI scheme (e.g., file:///sdcard/Downloads/exploit.html). It also targets the vulnerable application.
4. Data Exfiltration: The loaded attacker’s JavaScript code will have read access to any file under the Cordova-based app since it is run in the context of Cordova and universal access from file URIs is allowed by Cordova. The data can be sent to the attacker using other vulnerabilities described in our advisory.

The following figure illustrates the attack:

General Countermeasures Against XAS Vulnerabilities

For the vast majority of apps, avoiding Cross-Application Scripting issues is rather easy. Unless you truly know what you’re doing, never allow user data to fully control the URL of the WebView object.

In addition, exported activities that have no legitimate reason to be as such should be nonexported in the Android Manifest file.

Moreover, unless needed, do not enable JavaScript and/or allow universal/file access from file URIs.

Disclosure Timeline:

• August 4, 2014: Public Disclosure
• August 4, 2014: Vulnerabilities patched by Apache Cordova
• June 26, 2014: Vulnerabilities confirmed by Apache Cordova
• June 23 2014: Vulnerabilities disclosed to Apache Cordova

IBM Mobile Analyzer: The Cross-Application Scripting vulnerability discussed in this article was detected with IBM AppScan Mobile Analyzer technology. To demo Mobile Analyzer for yourself, sign up here for a free trial.