Apache Cordova Vulnerability Discovered: 10% of Android Banking Apps Potentially Vulnerable
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).
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.
A typical attack will be as follows:
|CVE Identifier||Description||Severity||Affected Versions||Mitigation|
|CVE-2014-3500||Cordova Cross-Application Scripting via Android Intents||High||3.5.0 and below||Upgrade to 3.5.1|
|CVE-2014-3501||Cordova white list bypass for non-HTTP URLs||Medium||All released Cordova Android versions||Use CSP (see white paper)|
|CVE-2014-3502||Cordova apps can potentially leak data to other apps via URL loading||Medium||All released Cordova Android versions||Upgrade to 3.5.1 and install plug-in provided by Cordova|
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.
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:
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):
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.
The attack’s outline is as follows (full details can be found in the advisory):
- Naïve Browse The victim browses to a malicious website.
- 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.
- 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.
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.
- 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.