In July 2014, David Kaplan and I found a series of vulnerabilities (CVE-2014-3500/1/2) in the Apache Cordova framework for mobile apps that enabled a remote drive-by exploitation attack. Adhering to our responsible disclosure policy, we reported the issues to the Apache team, which released a patch soon after. We then publicly disclosed the issues.

Apache Cordova, previously known as PhoneGap, is a platform that lets developers make use of HTML5 as a single cross-platform development technology. According to AppBrain, Cordova is used in just under 6 percent of all Android applications. It also shows prevalence in app store categories that could be of interest to attackers, such as business, medical and finance, where more than 12 percent of all applications in every category are based on Cordova.

During the recent IBM InterConnect event in Las Vegas, I presented our findings with fully working exploits we developed. The following is a short overview of Cordova that revisits these discoveries and the way in which we found them. Although we presented in a previous blog post WHAT we found, we have never before revealed HOW we found it.

Watch the Demo: Interactive Application Security Testing on Mobile Attacks

The What: CVE-2014-3500

Among the issues we found was a very severe one, CVE-2014-3500, a cross-application scripting vulnerability that allowed for a malicious JavaScript execution in the context of a vulnerable Cordova-based app.

Due to the severity of this issue, Google sent out a message at the beginning of October to all application developers using a vulnerable version of Cordova. The company asked them to update to a non-vulnerable version as soon as possible or risk sanctions against their applications on Google Play.

The vulnerability was due to the fact that the attacker could control the URL of Android’s embedded browser (WebView), the core of every Cordova-based app, using an Intent containing a malicious extra parameter. The following is the vulnerable piece of code:

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);
}

The getProperty method consumes an extra parameter from the input intent named as its first input parameter — “url,” in this case.

So, how did we find the issues?

The How: IBM Application Security on Cloud

In the past few years, we have researched and developed a powerful runtime analysis tool that can detect and pinpoint this type of vulnerability. Our tool, IBM Application Security on Cloud, gets an Android application package file as its input, finds various parameters that can be controlled by the attack and attempts to discover potential security issues that can arise due to these weaknesses.

In the Cordova case, for example, IBM Application Security on Cloud detected that the attacker can control the “url” Intent extra parameter in order to manipulate the URL of the embedded browser. Using this tool, we found several other interesting issues, which were responsibly disclosed to the relevant vendors. Some of them were blogged about, including the Android fragment injection vulnerability in the Android framework and a couple of vulnerabilities in Firefox for Android.

To learn more, take a look at my recent presentation from IBM InterConnect 2015.

Image Source: iStock