AllSafe (Intentionally Vulnerable Android Application)- Part 2

Hey fella!

This is a continuation of the previous blog on Allsafe, a vulnerable Android application.

In this, we will be getting to know some amazing attacks on Android applications which includes,

1. Root Detection bypass
2. Deep Link Exploitation
3. Vulnerable Webview
4. Certificate Pinning bypass

Root Detection bypass:

So before bypassing this security measure, we need to understand what is root detection in Android and how it is implemented.

Root Access allows users of smartphones, tablets, and other devices running the Android mobile operating system to attain privileged control (known as root access). “Rooting” is the process by which one gains access to an operating system’s administrative commands and functions.

Root Detection is the code snippet and logic used in an Android application to detect whether the application is installed on a rooted device.

The different logic used in root detection are:

1. Check for Test-Keys:
2. Check for “su” binary
3. Check for “busybox” binary
4. Check for specific packages

In the Allsafe application, the root detection is implemented as shown below:

The if condition uses a return value of an isRooted method in RootBeer class to make the decision.

The RootBeer class looks like:

So to solve this challenge, we can use Frida to override the isRooted method and return false to bypass the root detection.

The Frida script can be obtained from the Internet or this link.

Deep Link Exploitation:

Imagine you are browsing a website and you come across a link or a button that says “Click here to view a specific product.” You click on it, and instead of opening a new web page, it takes you directly to the product details page within the app. That’s a deep link!

Deep links are special links that can take you to a specific location or content within a mobile app instead of just opening a website or the app’s main screen.

Deep links allow users to open specific content inside a mobile application.

In Android, there are 3 valid deep link formats:

1. Scheme URLs (aka Custom Scheme URLs or URL Schemes)
2. App Links (aka Android App Links)
3. Intent URLs (aka Intent Scheme URLs)

I won’t be explaining in detail about the types but instead, provide you with a resource that I found super useful to understand deep links.

Exploiting Deep Links in Android - Part 1

So this challenge can be solved by splitting them into 2 tasks:

1. Identify the scheme or the deep link URL that the application is registered with.
2. Understand the code snippet and the requirements to solve the task.

To solve this task, we will use an HTML file in the Android Device to present an URL and open the application.

Identify the scheme or the deep link URL:

The scheme or deep link URL that the app is registered with or that opens the content in the Allsafe application can be found in the AndroidManifest.xml file.

The application accepts 2 schemes namely,

allsafe://

https://

Understand the code:

So if the URL matches the deep link scheme of the application, then it checks if the GET parameter key equals to key variable in the strings.xml file (R.string.key).

The URLs that can solve this challenge are:

allsafe://infosecadeventures/congrats?key=ebfb7ff0-b2f6–41c8-bef3–4fba17be410c

https://<any random string>?key=ebfb7ff0-b2f6–41c8-bef3–4fba17be410c

This is because the allsafe:// scheme did not include any * for the host or path parameter, hence it has to be followed as such, but for https:// only the scheme was mentioned and no host or path is mandatory for opening the deep link in Allsafe.

Vulnerable Webview:

WebViews are used in Android applications to load content and HTML pages within the application. Due to this functionality, the implementation of WebView must be secure in order not to introduce the application to great risk.

But Webview by default is not vulnerable to attacks but the settings being set for a Webview without proper sanitization, makes it prone to attacks like Cross-Site Scripting and Local Resource Access.

The code snippet:

The setting setJavaScriptEnabled(true) allows the execution of JavaScript in the application and there isn’t any sanitization implemented before executing the text which results in XSS.

The setting setAllowFileAccess(true) enables the access of local files using the file:// scheme. The Webview can be used to access all the files in the filesystem of the device.

Certificate Pinning or SSL-Pinning bypass:

Certificate pinning is a security mechanism used to enhance the trust and security of SSL/TLS connections. It is designed to protect against Man-in-the-Middle (MitM) attacks, where an attacker intercepts the communication between a client and a server by presenting a fraudulent SSL/TLS certificate.

This security mechanism protects the application from communicating with any other server that does not has valid security keys.

This even protects the application from proxying its request through Interception proxies like Burp.

When using Certificate pinning the client verifies the server’s certificate against a specific set of public key or fingerprint values, rather than relying solely on the default set of trusted CAs. This mechanism ensures that the client only accepts a specific certificate or set of certificates associated with a particular domain.

There are two types of certificate pinning:

1. Static Pinning: In this approach, the client stores a specific set of public key or fingerprint values of the server’s certificate. During the SSL/TLS handshake, the client checks if the presented certificate matches the stored values. If there is a mismatch, the connection is terminated, indicating a potential security issue.
2. Dynamic Pinning: This approach involves receiving the acceptable certificate information from a trusted source at runtime. The client contacts an online service or an out-of-band channel to obtain the correct pinning information. This method allows for more flexibility and easier certificate updates without requiring software updates on the client side.

If you are someone like me who prefers video check out this explanation on SSL-Pinning.

The challenge here is to Bypass the Certificate Pinning using Frida and intercept the traffic.

Simply use the Frida Script from the below URL and set up the proxy in your Android device to intercept the traffic.

To proxy the request from your Android application to Burp:

1. Download the CA Certificate from Burp and change its extension to .crt.
2. Navigate to Settings->Security->Encryption&Credentials-> Install A Certificate -> CA Certificate.
3. Now select the downloaded Burp certificate.
4. Now set up your Android device to proxy through 127.0.0.1:8080 (Burp Listener IP and Port).

Once this is done, run the SSL-Pinning bypass Frida Script and intercept the traffic from Allsafe Application.

That’s it for this blog and I hope this was an amazing ride for you on Android Attacks!