Thursday, October 9, 2014

How to patch CVE-2014-3500: quick fix of the latest Cordova vulnerability

A lot of mobile application publishers got this email from Google recently:

This is a notification that you have multiple apps, listed below, built on a version of Apache Cordova that contains security vulnerabilities. This includes a high severity cross-application scripting (XAS) vulnerability. Under certain circumstances, vulnerable apps could be remotely exploited to steal sensitive information, such as user login credentials. 
….
Please note, applications with vulnerabilities that expose users to risk of compromise may be considered “dangerous products” and subject to removal from Google Play.

Sure, after such a note from Big G, programmers, which use Apache Cordova (aka PhoneGap), are in a desperate need of upgrade to Cordova 3.5.1 or higher. For some, it might be a problem, as requires a lot of retesting.

Is there other way to mitigate or eliminate the problem? Let’s take a closer look on the issue. 

The vulnerabilities in Cordova, which moved Google to act, were discovered by IBM team and published in Jule, 2014: http://www.slideshare.net/ibmsecurity/remote-exploitation-of-the-cordova-framework

The paper describes 3 vulnerabilities, and the CVE identifiers are:
CVE-2014-3500: Cross-Application Scripting via Android Intents
CVE-2014-3501: Cordova whitelist bypass for non-HTTP URLs
CVE-2014-3502: Data Leak to Other Applications via Android Intent URIs

While all the vulnerabilities are dangerous and entertaining for every hackers or security analyst, it is CVE-2014-3500, which needs to be taken care of ASAP.

Here is the description of the problem:

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 a website, the developer can write the following code:

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

When the application is first loaded, it calls the Cordova WebView activity’s loadUrl() function which looks as follows:


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

One can see that initUrl is populated from a call to getProperty("url", null) which consists of the following code:

public String getProperty (String name, String defaultValue) {
Bundle bundle = this.cordova. getActivity().getIntent().getExtras();
Bundle bundle = this.cordova.getActivity().getIntent().getExtras();
if (bundle == null) {
    return defaultValue ;
}            
Object p = bundle.get(name);
If (p == null ) {
    return defaultValue ;
}
return p.toString();
}

Just meditate here a little. As the url parameter is taken from getIntent().getExtras(), it can be provided externally. This presents a vulnerability which can be exploited whereby a malicious caller could launch the Activity with an Intent bundle that includes a url provided by the caller. The provided URL will then be loaded by Cordova and rendered in the WebView!

To fix it, find every exported Activity, that call WebView.loadUrl() API.

Locate the place where the Activity is instantiated and clean ‘url’ and ‘errorUrl’, provided by a caller. I skipped the part on errorUrl, but you can find it in the IBM paper, they are very similar.

You should add the following lines just before the first call of super.loadUrl():
super.setStringProperty("url", null); 
super.setStringProperty("errorUrl",null); 

=======================================================
Now you application is not vulnerable to CVE-2014-3500, and you won time to update to the latest Cordova version.

Monday, September 15, 2014

Capture and monitor http(s) traffic from Android device through Fiddler using Wi-Fi and ProxyDroid

Developing your own application or making a security assessment of 3rd party application – it is very important to know, what traffic flows from an Android application? There are several ways to do it. We may use different proxies, we may utilize a real device or an emulator, and we might intercept air traffic or direct it through USB cable.

It is often that we need to intercept and analyze traffic from a real device and want to use Wi-Fi for that.
Here is how we may do that using Fiddler.


For this method to work you need a rooted Android device and an infrastructure which allows you to perform socket connections from your phone to your PC – Wi-Fi connection and an ordinary laptop with Wi-Fi module with would do just fine.

2. FIDDLER

Download the free version of Fiddler from Telerik. When running it the first time, make sure you allow Fiddler to accept network connections from the intra- or internet, depending on your infrastructure setup.

Configure Fiddler for incoming connections by going to Tools - Fiddler options... - Connections.. Set the following properties:


  • Fiddler listens on port: 8888 or any other port not in use at your computer
  • Allow remote computers to connect: on


Hit OK and restart Fiddler. 

2. PROXY DROID

Download Proxy Droid to your Android phone. Run it and configure it to point at your Fiddler instance by entering the IP of your computer and its port (8888 by default). Note that you must use the local IP address (often starting with 192.168.* or 10.*).




To test if your PC is reachable from your phone, you may simply ping it using ADB, given that it is connected with USB and have developer mode enabled. Example:
adb shell ping 192.168.1.6
(You need to have enabled reply to ICMP pings in your firewall for this to work. Fiddler may still work even if you get no ping replies)

You can also ping your phone from your PC. Acquire its IP address through this command:
adb shell netcfg

Usually the device eth0 will have the IP address you need.

3. TESTING

Simply start your favorite Android browser and navigate to a random web page. You should get the page presented normally in the browser, and see the HTTP requests line up in Fiddler. All apps will use this proxy now – not only the web browser. 

Fiddler with HTTP traffic log from the device

Whether you’re using this for policing other apps, or for debugging your own applications or 3rd party APIs, this is a technique that should be in every Android developer’s toolbox.


4. TROUBLESHOOTING

And what if the traffic from the targeted Android Applicaion is SSL encrypted?
It might be a very serious problem, if it uses its own SSL infrastructure (i.e. SSL pinning).

However, it might also be an issue with Android HttpsUrlConnection pipeline implementation - and Fiddler, happily, may fix it!
See a recipe in my previous post: How to decrypt SSL traffic from an Android app

Wednesday, September 3, 2014

How to decrypt SSL traffic from an Android app using Fiddler

There are plenty of tutorials on how you can intercept HTTP(s) traffic from Android using Fiddler.
Try this one: http://docs.telerik.com/fiddler/configure-fiddler/tasks/configureforandroid 

 However, it will fail when you try to intercept and decrypt Android SSL traffic coming from an application, and not from a browser.

 It might be that the application uses a certificate pinning – and you are probably cannot decipher this connection. Lost cause!
But more probably, the reason is a bug in the HttpsUrlConnection pipeline implementation.

 To solve the issue, please proceed with the following steps:

1 In Fiddler click "Rules->Customize Rules";
2 Find function OnBeforeResponse in the script
3 Add following code to the function body:
if (oSession.oRequest["User-Agent"].indexOf("Dalvik") > -1 && oSession.HTTPMethodIs("CONNECT")) { oSession.oResponse.headers["Connection"] = "Keep-Alive"; }
4 Save the file and restart Fiddler.