RCE in Android applications through third-party services

Most recently, MWR posted an interesting post " WebView addJavascriptInterface Remote Code Execution " on its blog. The entry concerns the security of mobile applications. I do not want to completely retell the study of our English colleagues - we advise you to contact the original source. But in short, when using a third-party library in your Android mobile application, you can easily catch the RCE (remote code execution) attack. Arbitrary code execution in an Android application is possible due to the reflection of a Java object that is inserted into a WebView.

So, in order for this vector to work:

1) First, the code must be compiled using the SDK older than version 17.
2) Secondly, the application must be allowed to execute JavaScript code. That is, the setJavaScriptEnabled () method must be present with the true parameter - it is disabled by default.
3) Third, the addJavascriptInterface () function should be used.
4) Fourth, when receiving data from the server, HTTPS should be absent or incorrectly used.

It seems to be a lot of conditions, but, as our practice shows, all this is very common, especially in some third-party frameworks.
Since the beginning of the year, in our presentations and research on the security of mobile banking, it has been said that the development of such critical applications should be guided by the principle of using only the necessary libraries. After all, nobody integrates interaction with news, social networks and other services into the RBS systems, you should avoid this in mobile banking.
')


In Russian mobile banking applications for Android, we have seen interaction with a large number of third-party services, which increases the risk of the application being compromised if used incorrectly. Very often there is an interaction with the news server of the bank, and very often this interaction goes via HTTP. All this greatly expands the attack surface (banking surface) on the banking application.

Attack:

1) We produce MitM.
2) Injecting malicious JavaScript code into traffic that calls the getClass () method of the Java object. For example:

JavaObject.getClass().forname(“java.lang.Runtime”).getMethod(“getRuntime”, , null).invoke(null,null).exec([“/system/bin/sh”,”rm”,”-rf”,”*”]) 

You can imagine the attack option without MitM: for example, by hacking the site and inserting your JavaScript code or through the stored XSS on the site. In general, this development is also possible.

Meanwhile, Joshua J. Drake , one of the most active contributors to Metasploit, has already written the add_js_interface_mitm module specifically for this case. The module is not yet available and is in beta testing. The picture shows a successful attack on Fruit Ninja using the vulnerable MoPub.

Possible consequences for the user:

1) Complete compromise of the data of the vulnerable application. If the device is not ruled, then our code will be executed within the sandbox of the vulnerable Android application, that is, do everything that this application can do.
2) Complete compromise of the mobile device (all data on the phone). If the device is rooted or has a vulnerable version of Android, then our code can conduct an LPE (Local Privilege Escalation) attack and already work as root. We do everything we want on the device.

Fix:

1) Refuse to call Java object from JavaScript, if it is not necessary.
2) Use the SDK under version 17 — you need to add the @JavaScriptInterface annotation, since all methods of the Java object, starting with version 17, are not available by default.
3) Instead of addJavaScriptInterface, use another way to invoke Java methods by creating your own URI scheme and using the method shouldOverrideUrlLoading . In doing so, validate incoming data and encode outgoing data to prevent injection.

Backdoor:

Also, all this can be successfully used to circumvent the pre-moderation of applications on Google Play. In general, it's nice to leave backdoor in your application =)