Menu

xda

At the end of September I gave a presentation at xda:devcon14 which gave an overview of attack surfaces in Android and security issues in web-based applications. I have put my slides online on slideshare, and a lot of people were asking questions, so I decided to post a write-up.

Attack Surfaces

A big part of the presentation covers attack surfaces in Android, what are they?

Attack surfaces are pieces of code which are executable by everyone who has access to a system. They are called the open flanks of a system and allow input or code execution, not necessarily from a malicious user. A hacker will usually search in these places as these are the most interesting to manipulate.

In order to decide which attack surfaces an attacker will try to attack some properties of the surface are considered, as mentioned in the slides. These properties determine what the gain is for an attacker once he successfully compromises the surface entirely or just the code behind the surface. The general rule here to follow, is that an attacker will try to gain as much privileges as possible with the least amount of investment of resources and time.

I will not cover all the attack surfaces but only the one that is interesting for web-based applications. This is called the remote attack surface, more specific the WebView component. This is a class which offers functionality to render web content using the webkit render engine. This is a broad attack surface as a lot of web technologies and protocols need to be supported. These all represent an attack surface on their own, with their own vulnerabilities and security models which can be in conflict with the Android security model. Which is the case when we consider hybrid frameworks.

To be on the same page, I define a web-based Android application as an application who uses the Webview class to render web content.

JavaScript-Java Bridges, burn them

Security issues arise when you use a JavaScript-Java bridge in your web-based application. Android allows in the Webview class to call Java native code from Javascript, you can register the native code that can be called by using addJavaScriptInterface(). The security issues become apparent when you don’t know which content you are loading.

What happens with JavaScript being loaded in an iFrame? Or more general with JavaScript coming from a third party source?

Basically there is nothing stopping them from calling your Java native code associated with the JavaScript bridge. Android uses a permissions model to allow apps to do certain actions. Third-party JavaScript can call the same public methods associated with the JS bridge. This is because the Same-Origin-Policy is not applied to the bridge. It is in conflict with at one side native code running in a permissions security model and on the other side web content, which is bound to the SOP. These two security models do not interleave perfectly and thus allows attackers to use functionality the user never granted permissions for.

Hybrid Frameworks (Apache Cordova, Sencha Touch, …)

Hybrid frameworks are frameworks who let you develop a web application using HTML5, CSS and JavaScript for example. They allow you to pack your application to run cross-platform. Benefits of this approach is the fact you only need to develop your application once and you can pack it for the different platforms. This saves you time and money if you need to pay the developers.

When packing your application for Android, the following happens. Your web application is nothing more than web-content running in a Webview class. These frameworks come default with a Java-JS bridge which are publicly available. The same problems arise as mentioned here above with simple Webview applications. There are however solutions to these problems.

Domain Whitelisting

Just implement your own origin policy! You decide which third parties you trust. For hybrid frameworks it is fairly easy, just use the domain whitelisting functionality. The funny part here, is the fact that default this is implemented as allow every domain. Yeah, you’re welcome.

In applications using a Webview-component the solution is to just intercept pageloads and resource loading requests and implement whitelist logic to deny loading if you don’t trust the origin. The slides give you the two interesting methods which you need to override in the Webview class: shouldOverrideUrlLoading() and shouldInterceptRequest()

When a third-party ad-network is used the same vulnerabilities are present as ad-networks can inject third-party content. Recent study of MWRLabs discovered the following numbers:

A script was then crafted to automatically download Android applications, decompile them and identify if an ad network was in use, and if so determine if it is vulnerable. Out of the 1,000 top applications 570 were found to be vulnerable.

This means that over 50% of the Top 1000 web-based Android applications are vulnerable. Makes you think, if security is a key aspect and concern, stay away from web-based applications. It is very tricky to get it right, and in the end native coding is more fun 😉

H4

PS: Those who want to see the talk, it was filmed, but is not yet online. Keep an eye on this blog or my twitter feed 😉