Intro to
Intent redirections…and how to exploit them

So we’ve covered a safe Intent redirect, and a completely insecure Intent redirect. Now lets talk about a semi-safe, but sometimes still exploitable, Intent redirect.

Lets say an attacker Intent object looks like this:

Intent yayintentyay = new Intent();
intent.setData(Uri.parse("theBestSchemeEver://yaymaliciousyay.com");
intent.putExtra("os_cmd", "reboot")

Then the target application reads the incoming attacker Intent object, and tries to do a “safe redirect”, but forgets to only allow the redirect if the attacker’s URI matches “https”:

class aWebView extend Activity {
    ...
    private void loadWebView(Intent yayintentyay) {
        // get the host name and scheme
        String yayhostnameyay = yayintentyay.getData().toString();
        String yayschemeyay = yayintentyay.getScheme();

        // check if host name and scheme are valid
        // if so, load URL
        if (yayhostnameyay.equals("notmalicious.com") && yayschemeyay.equals("https")) {
            webView.loadUrl(yayhostnameyay);

        // check if scheme is `http` or `https`
        // if so, send it to app that can handle the scheme
        // typically, this is a browser app
        } else {
            Intent safeIntent = new Intent();
            safeIntent.setData(yayintentyay.getData());
            startActivity(safeIntent);
        }
}

In this case, the attacker’s data URI is sent to whatever application can handle the scheme theBestSchemeEver. This can be useful in cases where you need to use the target application as a proxy to reach another application. Sort of like pivoting in an internal network from one host to another!

We actually cover this kind of Intent direction in one of our courses, Advanced Android Hacking. In this course, this type of Intent redirection was used *TWICE* in a Pwn2Own entry! More information about this course is here: https://www.mobilehackinglab.com/course/advanced-android-hacking

There’s another semi-safe Intent redirection that I’ve also personally used in a bug bounty submission before. In that app, the target application’s code did do Intent.parseUri(String, int) against my Uri string. But then the target application would attempt to apply some sanitization to the Intent object.

First, lets look at the attacker code:

Intent yayintentyay = new Intent();
yayintentyay.setData(Uri.parse("intent:#Intent;component=com.application.yay/.unexportedActivity;S.stringExtra=yaystringyay;end"));

Now lets look at the example code:

class aWebView extend Activity {
    ...
    private void loadWebView(Intent yayintentyay) {
        // get the host name and scheme
        String yayhostnameyay = yayintentyay.getData().toString();
        String yayschemeyay = yayintentyay.getScheme();

        // check if host name and scheme are valid
        // if so, load URL
        if (yayhostnameyay.equals("notmalicious.com") && yayschemeyay.equals("https")) {
            webView.loadUrl(yayhostnameyay);

        // convert the attacker Uri into an Intent object and add a BROWSABLE category
        } else {
            Intent newIntent = Intent.parseUri(yayuriyay, 1);
            intent.addCategory("android.intent.category.BROWSABLE");
            startActivity(intent);
        }
}

The problem with this code is that without sanitizing out the Component value, while adding a Category value. Under the right circumstance, the Category value doesn’t actually matter, if the attacker can control the target Component!