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.
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.
Hybrid Frameworks (Apache Cordova, Sencha Touch, …)
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.
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 😉
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 😉