Skip to content

Deep Dive into Activities

An activity is something that interacts with the user on the screen. They come in a variety of shapes and sizes, including floating windows, Multi-Window Mode, and windows embedded within windows. Every app must have at least one activity called MainActivity, which will run immediately after the app is launched.

Activities can be vulnerable to Authentication/Authorization vulnerabilities depending on their function. Aside from that, there are Deeplink and WebView activities that are most likely exploitable. We'll go through what they are and how to exploit them in detail. Take a quick look at the activity lifecycle before moving on.

Stages of Activity Life-cycle

  • Initialized: Activity instance is created and its properties initialized.

  • Created: Activity is now completely initialized and ready to configure its UI.

  • Started: Activity is visible to the user.

  • Resumed: Activity is visible to the user and has focus. In this state, the user is likely interacting with the activity.

  • Destroyed: Activity is destroyed and the OS can reclaim its memory.

In a security perspective life-cycle callbacks are much important let's have look:

Activity Life-cycle Source:Android.com

life-cycle callbacks

  • onCreate(): This will execute when the activity is created. All userfacing work such as views, list are all done at this time.

  • onStart(): It Invoked when user actually able to see the activity, as well as when activity is restart this will called.

  • onResume(): It will start when user start interacting with users. also it will called when activity is resume.

  • onPause(): When we sent any app in the recent but not exit from it at this time the activity goes in pause. when it comes on front screen onResume is being called.

  • onStop(): It Invoked when user is not able see the activity.

  • onDestroy(): This is final call of lifecycle before destroying or killing activity.

  • OnRestart(): This being called after activity has been stopped and prior to its starting stage.

Declaration of Activity:

<manifest ... >

<application ... >

   <activity android:name=".ExampleActivity" />

    ...

</application>

 ...

</manifest>

How To Approach:

How To approach activity.

White lines indicate prerequisites, Red lines indicate Deeplink Vulnerabilities, and green lines indicate that the vulnerability can be exploited using WebView, and if we exploit deeplink via WebView, the same vulnerabilities may be exploitable.

For Example. If we want to look for XSS, thus we'll need either a web view or a deep link that may be exploited in a webview. Other requirements include setJavascriptEnabled(true) with exported activity and missing permissions. or If I have an exported activity with missing permissions, we must look for any of these functions, and if we find loadData(), we will store our malicious script in a single string and pass it to loadData(), which returns Rendering HTML or loading arbitrary sites, or XSS if we have a javascript enabled function.

Deep links allow us to trigger an intent via URL, embedded in a website. This allows the app to start and pass in data.

How to identify ?

We can look for scheme tag with Browsable Category in AndroidManifest.xml File.

Example:

     <intent-filter>

        <action android:name="android.intent.action.VIEW"/>

        <category android:name="android.intent.category.BROWSABLE"/>

        <data android:scheme="http"

                android:host="example.com"

                android:path="/webview"

      </intent-filter>

This is best example of deep link.

Structure of deep link structure is

<scheme>://<host>:<port>[<path>|<pathPrefix>|<pathPattern>]

So accordingly our deep link will be http://example.com/webview and this will help us to trigger webview of the app which we'll cover later but for now let's understand how to exploit deep link.

Loading Arbitrary Sites:

For demo purpose we need insecureshop apk

Decompile Apk ( Don't know how ? checkout Reversing APK )

AndroidManifest.xml >

<intent-filter>

        <action android:name="android.intent.action.VIEW"/>

        <category android:name="android.intent.category.BROWSABLE"/>

        <category android:name="android.intent.category.DEFAULT"/>

        <data android:host="insecureshop" android:host="com.insecureshop"        </intent-filter>

As previously explained our deep link will be insecureshop://com.insecureshop because we got only this much information from AndroidManifest file first test that can we trigger app with this or not. Save following code in exploit.html

<html>

<body><a href="insecureshop://com.insecureshop">Start Attack</a>

</body>

<html>

Host the file locally by pushing exploit in the device

or Remote server

As you can see, we may activate the app via a deep link contained in a web-page. But wait, that's not a flaw, it's a feature!

Let's check the class of the activity if we find something might exploitable.

WebViewActivity.class

If we look into code then we have two paths /web and /webview where input string will execute according to condition is being satisfy.

so our exploit will be 

<html>

<body><a href="insecureshop://com.insecureshop/web?url=http://bing.com">Start Attack</a>

</body>

<html>

Loading Arbitary sites.

This is one of the example that how we can load any arbitrary websites to victims app.  also this may vary app to app depends on path, functions and conditions that activity class been specified.

Stealing Sensitive Information:

Another attack vector for exploiting deeplinks could be stealing sensitive information from victim app.

Consider while playing with burpsuite, looking into hardcoded data or by any other method we found one endpoint which maybe api/v2/apikey="", api/v2/userinfo="", /sessionID="".  and while you are authenticated you got some info in your app.

Now we design our payload according to same "insecureshop://com.insecureshop/web?sessionID=" now as victim click on that in his app the webview will render with the information that directory actually present and we got that info on our server.

This is how we can steal sensitive information from victims app.

Cross Site Request Forgery:

In CSRF we basically trick user to do some unwanted actions the best example of CSRF is https://hackerone.com/reports/583987 In perscope app researcher able to force victim to follow.

In our case that might be " Insecureshop://com.insecureshop/follow".

Insufficient URL Validation:

Most of time the app is not properly validate the URL such as it ignore backslash, forward slash, IDN Homographic characters etc. that leads to different kind of attacks such as Open Redirection, Injecting malicious script or disclosing internal information.

Consider "Insecureshop://com.insecureshop/" this is expected URL to app. but what if "Insecureshop://com.insecureshop/?url=bing.com/\\alert()" and it ignored first url and execute our payload or with this domain it also executed our payload that will become big attack vector for us.

Let's have look into Webview:

WebViews are effectively web browsers embedded into Android Apps. WebViews content can be pulled from remote sites or can be files included in the app. WebViews are vulnerable to the same vulnerabilities affecting any web browsers. However there are some configurations that can be useful to limit the attack surface. Types: WebChromeClient & WebViewClient.

In webviewclient is only render the html no javascript can execute in webviewclient whereas WebChromeClient has enabled javascript so xss payloads possible possible to execute.

Sample Code to identify webview

<WebView

android:id="@+id/webview"

android:layout_width="match_parent"

android:layout_height="match_parent"

/>

AndroidManifest.xml

Uri uri = getIntent().getData();

if(uri != null)`&#x20;

{

webView.loadUrl(uri);

}

WebviewActivity.class

Sensitive Information Disclosure

In Web browser we actually get UI or shell where user can able to search something input is given by user. but Accessing Native apps in browser is not possible. whereas In webview accessing native apps are possible with the help of Javascript interface webview because it provides javascript bridge and Native bridge.

Now incase if you found addjavascriptinterface() that might vulnerable for runtime code execution  check https://labs.f-secure.com/advisories/webview-addjavascriptinterface-remote-code-execution/

Framework such as cordova framework which is used to build mobile apps, they might vulnerable for accessing internal information such as contact list with the help of navigator.contacts.

other than this we have setAllowConentAccess() function which invoke content provider can allow to pass URI with content:// scheme so if there is any content provider handling any sensitive information then we might able to retrieve that information.

Rendering HTML & Cross Site Scripting:

In case if we found a webviewactivity exported without any permissions we will firstly look for loadURL(), loadData() and Javascriptenabled() functions we look for either loading random HTML code or Cross Site Scripting(bit different than web cause here we don't have access to Cookies)

Following code is the example if we found loadData function so firstly we gonna store our html in one string and then it pass to function.

String data = "<html><body><h1>LoadData Function Test</h1></body></html>";

mywebview.loadData(data, "text/html", "UTF-8");

If we have loadURL() function then we can directly pass URL to activity and load arbitrary websites.

Arbitrary File Access:

Following functions allow to pass file:// scheme and allow local files via webview.

setAllowUniversalAccessFromFileURLs()

setAllowFileAccessFromFileURLs()

setAllowFileAccess()

Authentication & Authorization Vulnerabilities

This section is with rare scenarios .

1.Suppose we have 3 activities login, 2FA & Dashboard activity.

If Dashboard Activity is exported and permissions are missing then after login we may directly able to start activity now if there is no proper configuration we can able to bypass 2FA.

2. Now Another case while looking into source code we may found activity of function which is only accessible by admin and not by normal users so if that activity is exported and with no mandatory permission we can able to start that activity access that functionality. In this way we can bypass Authorization.

Privilege Escalation:

Sometimes  one activity is protected but it can start with another activity which is exported.  https://hackerone.com/reports/200427 In this report researcher did same thing start protected webview activity with exported activity.

This kind of vulnerabilities are rare and may vary app to app.

References