Android Pentesting – Dynamic Analysis

In the previous article, we went through the different ways of performing the Static Analysis via the APK. Although there are many aspects and other ways, but that was a beginner-friendly post. In this article, we will focus on the dynamic analysis of the application.

Dynamic Analysis

The dynamic analysis of the application refers to the analysis when the application is running. There are many aspects of dynamic analysis. But we will go through some common aspects and how attackers approach the target applications.

Challenges

While performing the dynamic analysis, the foremost objective is to intercept the application’s communication with the server. Also, since many people do not have a separate device, they use emulators for testing. Considering these factors, there are some challenges that analysts face.

Root Detection

Many applications have protection against the root detection since rooted devices pose many threats to the application. These threats include but are not limited to memory access, data access, configuration modification, etc. Also, many emulators are rooted by default. Having the root check in place, the application will not run on rooted device.

SSL Pinning

SSL Pinning, in simpler terms, is an additional security mechanism that ensures the application only accepts the communication from the trusted server only. This will restrict the security professionals and/or attackers to intercept the application’s traffic in BurpSuite.

Bypass

To bypass these checks, there are 2 famous tools as follows:

1. Frida
2. Objection

We will go through frida in detail as objection is built on frida and has some pre-compiled modules. However, for frida, we need the scripts to hook into the application for bypassing specific control(s).

Frida

Frida lets you inject snippets of JavaScript or your own library into native apps on Windows, macOS, GNU/Linux, iOS, watchOS, tvOS, Android, FreeBSD, and QNX. Frida’s core is written in C and injects QuickJS into the target processes, where your JS gets executed with full access to memory, hooking functions and even calling native functions inside the process. You can read more in detail from the official website.

Setting up environment for Frida

There are many scripts available for bypassing the security checks in place. But before running the scripts, we need to setup the device or emulator for frida. First, we need to push the frida server executable to the emulator after extracting it. However, you can download the specific server according to your needs. You can use the following adb command to push the server to emulator.

adb push frida-server /data/local/tmp/frida-server
chmod +x frida-server
./frida-server

The above commands will push the frida server to the emulator, make it executable, and then run it. However, sometimes you might get the error Permission Denied while pushing the server as follows:

For this, you need to run adb as root and execute the command adb root.

Finally, you can push the frida server as below:

Having the server in place, you can bypass the root detection and ssl pinning using the bypass script via the following command.

frida -U -f <APP_ID> -l bypass_script.js --no-pause

Where APP_ID is the package name that you can find in the AndroidManifest.xml file. This will inject the script and bypass the controls according to the script. You can use the following frida script to bypass both root detection and ssl pinning:

Note: Make sure to change the extension to js

After injecting the script, the application will open automatically (even on rooted device) and you will be able to intercept the traffic in BurpSuite. Finally, you can test the application normally as you would test a web application by intercepting the requests and playing around them.

Diving into files

Many times, some applications after installation and some after running create files and folders within the application’s folder in the file system. You can access the application’s folder via adb shell and navigating to the path.

adb shell
su
cd /data/data/<APP_ID>

Commands Explanation

1. adb shell will give you the shell access to the emulator or the device
2. su command will elevate your privileges (if not privileged) to root (if the device is rooted)
3. cd command will change the directory to the specified path
   1. The default location of installed application’s folders is in /data/data/APP_ID. Where the APP_ID is the package name of the application

You can navigate through the files in the folder recursively and see if you find anything interesting. Many applications create sqlite3 databases to store sensitive data. This data may be related to application’s authentication with the server as admin and it could be goldmine for the attacker. Following is a screenshot from the android’s native settings application’s folder.

Deeplinks

A deeplink is a URL that points to the specific activity, intent, or page within the application. Using the deeplink, we can open the specific activity of the application rather than going through whole process starting from the home screen. Sometimes, the developers do not check for the login session at each activity. They assume that the user will go through the intended flow from the home screen. It is important to note that deep links are intended to enhance user experience and functionality. However, when it comes to exploitation, the context often shifts to security concerns.

If some activity showing sensitive data has no protection, the attacker can open the activity directly to disclose the information. Similarly, if the application has some features for higher privileges but no option for normal user in the app, the attacker can get access to those features via deep links. There are many other scenarios through which attackers can exploit the deep links. You can use the following adb commands to launch a deep link directly.

adb shell am start -a android.intent.action.VIEW -d "DEEP_LINK" APP_ID

You can find a list of deeplinks in the AndroidManifest.xml file and search for <intent-filter> elements within <activity> elements, as they often define the deep link handling.

Conclusion

There are many aspects of dynamic testing among which we have covered a few. However, we will be going through the exploitation of common vulnerabilities in detail in the coming articles.