Android webview security loadDataWithBaseURL

A quick lesson in web views in Android. Normally they are a big risky area, be it adding JavaScript interfaces (http://labs.mwrinfosecurity.com/blog/2012/04/30/building-android-javajavascript-bridges/), or just generally enabling javascript and opening yourself up to webkit exploits (which given how little the OEMs update their firmware, is not hard to do).

So another interesting bit to concern yourself with is found on the following page's code:
http://www.androidsnippets.com/webview-with-custom-html-and-local-images

The code is as follows:

/**
 * This code loads a custom HTML from a string which references a local image
 * - for this to work, simply place the image in the directory /assets/
 */
 
public void loadHTML() {
    final String mimeType = "text/html";
    final String encoding = "utf-8";
    final String html = "

Header
Custom HTML



";
    
    WebView wv = (WebView) findViewById(R.id.wv1);
    wv.loadDataWithBaseURL("fake://not/needed", html, mimeType, encoding, "");

The problem is with the loadDataWithBaseURL's first argument. This defines how relative links on the page should be dealt with. Normally setting it to null or "" is enough, although this obviously produces invalid links. A better way is to use "file://android_asset". The problem with "fake:" is that if any other app registers for this custom url scheme, they will receive the link and start one of their activities.

Not a bad issue, unless the url has sensitive data in it right? Well as a malware writer, this is could still be useful. Imagine if this screen is part of the Facebook app and has a relative link on it, or has JavaScript that changes the window.location to a relative page. All the malware needs to do is dress the pop up screen in nice Facebook attire and ask the user to re-enter their creds. It doesn't even require the malware app to request any permissions from the user.

To fix it, just set the baseurl to null, or include a custom webview client (setWebViewClient)

Hacking Android dynamic Broadcast Receivers

An interesting point was raised this week when the subject of attacking IPC endpoints in Android applications was being discussed.
Attacking Endpoints is a method by which a malicious application on an Android device can communicate with, and misuse functions of other applications installed on the device. This can lead to anything from information disclosure to code execution.

To find these end points it's normally a matter of checking the application's manifest file (which can be recovered from the apk)

adb shell "pm list packages"
adb shell "pm path com.example.apptotest"
adb pull /data/app/com.example.apptotest-1.apk
aapt d xmltree com.example.apptotest-1.apk AndroidManifest.xml

This process (which can be sped up with mercury), gives you a whole list of text which allows you to identify which of these end points are exported either on purpose or otherwise, and which have permissions.

This gives us a list of things to look at in code, but I believe we are missing a step here. This assumes that these are the only end points we can talk to. Obviously some require permissions that we as a malicious app might have ourselves by just asking the user for it, but for this instance the malware will have zero permissions.

It is possible to register a broadcast receiver dynamically, typically by doing the following:
registerReceiver(BroadcastReceiver myreceiver, new IntentFilter("android.some.THING"))

This is fine, and often required to listen out for an event on a device. There are 2 things that can go badly wrong here though. First if the broadcast filter is listening for an intent that isn't a restricted broadcast then the malicious app can start sending them without needing any permissions. Secondly if the receiver goes on to use the extras sent with the broadcast, or to start running other functions, then the malware has a whole new entry point to your application. Of course it would require the malware to send the broadcast at the right moment, but hell just have it send the broadcast every second and run all the time.

To protect your broadcast, you need to register permissions when you declare it (details here), secondly don't trust the data that is being sent with it. It's passing through a trust zone to arrive in your app, so validate it! Details on Android permissions can be found here.