Vulnerability Analysis in Android Applications (1)

1. Introduction and Objectives

According to “OWASP Mobile Security Testing,” the phases for conducting a pentest on a mobile application are as follows:

1. Reconnaissance: In this step, information about the application under analysis is gathered. This includes the type of app, manufacturer, previous versions, resources used, etc.
2. Static Analysis: Reverse engineering is performed on the binary itself, enabling the extraction of information regarding permissions, main activities, resources, configuration errors, entry points to the system, hard-coded information (API keys or credentials), etc.
3. Dynamic Analysis: Reverse engineering is performed on the running binary process, allowing real-time analysis of the application’s behavior. This includes observing files created/modified/accessed by the app, identifying unencrypted sensitive data, analyzing logs, capturing network traffic generated by the app, and conducting fuzzing to check for potential vulnerabilities such as Buffer Overflow (BoF), SQL Injection (SQLi), Cross-site Scripting (XSS), Local File Inclusion (LFI), Remote Code Execution (RCE), etc.

In this article, we will learn the basics and methodology of manual static analysis of Android applications. We will not use automated vulnerability detection tools for this purpose. Instead, we will demonstrate this process using a specific example.

2. Setting Up the Analysis Environment

The first step is to create and set up a secure and suitable analysis environment. The tools you’ll need to set up are as follows:

1. VirtualBox: You’ll need VirtualBox to create a virtual machine (VM) where you can analyze Android applications in a secure environment. Download VirtualBox from its official website and install it without any complications.
2. Androl4b: Among the various tools available for analyzing Android applications, you can find a comprehensive collection bundled within the “Androl4b” virtual machine. This VM is based on the Ubuntu operating system and is designed specifically for Android security features. It includes a collection of security tools for reverse engineering and analyzing Android malware applications. Some of the highlighted tools within this VM include “Mobile Security Framework” (MobSF), “APKStudio”, “ByteCodeViewer”, “Drozer”, “APKtool”, “AndroidStudio”, “ClassyShark”, “BurpSuite”, “MARA”, “Wireshark”, “FindBugs-IDEA”, “AndroBugs Framework”, and “Metasploit,” among others. It’s worth noting that this virtual machine works perfectly fine in VirtualBox but might encounter certain issues with VMware.

By setting up this environment, you’ll have access to a wide array of tools that can aid in the security analysis of Android applications. This VM offers everything from static analysis to network traffic monitoring, and it’s an efficient way to conduct comprehensive Android application security assessments.

Once “VirtualBox” is installed, you might encounter initial issues when trying to boot up “Androl4b,” especially if you’re working within a modern Windows environment.

After importing the “Androl4b” virtual machine, you might notice that the configuration only allows you to use 32-bit VMs. Upon further examination of the available machine types that “VirtualBox” allows you to create, you might realize that you’re only able to create and start 32-bit virtual machines.

This becomes problematic because if our host machine is 64-bit, the virtual machine won’t boot properly.

However, how do we address this challenging situation to proceed with our goals and analyze Android applications within a secure environment?

The answer to this significant question is quite straightforward: we need to follow some simple yet precise instructions in the correct order.

• First and foremost, assuming we are working in a Windows environment, we need to make sure that our machine is 64-bit by running the “dxdiag” tool (there are many other ways to determine this):

• Once we’re sure that our machine is 64-bit, we need to check if our processor supports virtualization. Generally, modern processors provide support for 64-bit and also support virtualization (especially Intel and AMD processors). To identify our processor and determine if it supports virtualization, we can find this information in the system specifications and then easily verify it on the official processor website.

• Assuming the previous steps have been successful and our system supports virtualization, let’s continue. Go to the BIOS of your machine and look under the security or configuration tab for an option called “VIRTUALIZATION” or something related to it (you might also see “AMD-v” for AMD processors or “VT-x” for Intel processors); enable this option and save the changes before exiting the BIOS. If you’ve located and enabled this option successfully, upon rebooting your machine and logging in, you’ll notice that after launching VirtualBox, it now allows you to create and import 64-bit virtual machines.

*NOTE: If you can’t find the virtualization option in your BIOS and you’ve confirmed that your system supports virtualization, then you should check if your BIOS is up to date. If it’s not, you’ll need to update it from the official website of your processor manufacturer.

• If you have followed all the previous steps correctly and still haven’t had success with the 64-bit options in VirtualBox, you should check if the “Hyper-V” service is running on your machine. To do this, go to the location where you can disable this service and check if it’s enabled. If it is enabled, you should disable it. You can find this option in “Turn Windows features on or off.”

If you can’t find it, then the work is already done. However, if you locate it (similar to what you see in the image), you should uncheck the box and ensure that the subfolders are also unchecked. Once you’ve made these changes, click OK, and Windows will apply the corresponding changes. You’ll then be taken to another window confirming that the changes have been completed successfully, and you’ll need to restart your machine. During the restart, you’ll notice that Windows treats this change as if it were an update. Once you log in and start VirtualBox, you should be able to see that it allows you to create or import 64-bit virtual machines.

Now it’s time to go to VirtualBox and, on the imported Androl4b virtual machine, change its configuration to Ubuntu 64-bit. Start it up and ensure that everything is working correctly.

Log in with the user credentials: “andro” and password: “andro” or “androlab”, and you’re all set to begin working.

We now have our lab ready to perform the analysis of the applications we will see next.

3. Static Analysis of the “DIVA” Lab

This laboratory called “Damn Insecure and Vulnerable App” (DIVA) is composed of a set of intentionally programmed Android applications to be vulnerable. Its purpose is to educate developers and security professionals about the most common vulnerabilities in applications, often resulting from poor or insecure coding practices.

a) Preparing the Emulator

First of all, we start the emulator from the terminal using the command “android avd” and the password “1234”:

In order to analyze this application, first, working within the Androl4b environment, we download the application from http://www.payatu.com/wp-content/uploads/2016/01/diva-beta.tar.gz, then we extract it and install it on the emulator.

Next, we run the Diva application from the emulator, and we can see its interface:

Now we are ready to start analyzing this exciting application. We’ll need to have the updated tools “dex2jar,” “JD-GUI,” “APKTOOL,” and “Drozer.” In addition to the Android utilities to work with the emulator (adb, sqlite3…), which are already included by default in Androl4b.

b) Getting the source files of the application

Download and install “dex2jar,” then extract the “.apk” file to analyze and obtain the unpacked source code of the application, as shown in the following image.

Once you have obtained the “.jar” file of the app, proceed to download and install “JD-GUI” from its official website “jd.benow.ca”. Then, open the “diva-beta-dex2jar.jar” file with “JD-GUI”. This will allow you to access the source code through the “.java” files that make up the app for analysis.

At this point, we need to use the “apktool” tool to obtain the “AndroidManifest.xml” file. This file will provide us with valuable information about the internal structure of the program.

Now that we have obtained all the files that make up “DIVA,” we can get to work and start analyzing it.

c) Analyzing “Insecure Logging”

Let’s start by analyzing the “Insecure Logging” app. The app prompts us to enter our credit card number, and our goal is to identify the insecurity it presents. In Android, information is generally logged in the “logcat,” and this is where we will find our entered data. Our next step is to search for programming errors in the various source codes obtained earlier to correct and patch the vulnerabilities found.

By using the “adb logcat” command, we can view all the logs generated within the Android emulator’s environment. Upon entering our data, we can observe that it’s transferred and recorded in plain text (without any encryption). This means that any attacker can access this data, leading to serious consequences.

It’s time to navigate to the code of the application that we have already opened with “JD-GUI.” If we go to the “LogActivity.class,” we can see the following code:

As we can see, the error lies in logging the transaction error along with the entered credit card number. If we remove that line of code, the error will be resolved.

d) Analyzing “Hardcoding Issues”

Next, we proceed to analyze the next app, “Hardcoding Issues – Part 1”. The objective is to identify the security flaws in the app in order to discover the “vendor key” and gain administrator privileges within the application. To achieve this, we will examine the previously obtained source code, working through it until we reach a point where we can intercept the vulnerability.

As we can observe, in the “access()” function, the user-input text is compared with the string “vendorsecretkey,” which is the correct password and grants us positive access.

e) Analyzing “Insecure Data Storage 1”

In this section, we’re going to analyze the app “Insecure Data Storage 1.” The objective is to find, through the study of the source code, where the credentials are stored in the system and how they are stored (encrypted, plaintext, etc.).

Let’s go to the application and enter our username and password. When we press “SAVE,” we see a message confirming that the credentials have been saved successfully. Later, if we go to the source code of the app in “InsecureDataStorage1Activity.java,” we can observe that the “saveCredentials()” function saves the credentials in the “DefaultSharedPreferences.”

Physically on the device, the path for “DefaultSharedPreferences” can be found at “/data/data/jakhar.aseem.diva/shared_prefs.” So, let’s navigate through the device using “adb shell,” and when we reach that directory, we find the file “jakhar.aseem.diva_preferences.xml.” When we open this file, we see our data stored in plaintext.

As we can see, this is a critical security vulnerability related to the storage of credentials, resulting from a programming oversight in the code. Such vulnerabilities are more common than we might think and can lead to serious security breaches.

f) Analyzing “Insecure Data Storage 2”

Now let’s analyze the “Insecure Data Storage 2” app. The objective here is exactly the same as in “Insecure Data Storage 1.”

Without further ado, let’s get to work. We enter the username and password, and then we examine the application’s source code to locate where the entered credentials are stored and how they are stored.

With a quick glance, we can see that the credentials are stored in a database. If we navigate to the “jakhar.aseem.diva” directory (where the application is installed on the device), we can find the “databases” folder, which is the directory for the application’s databases.

We see that there are several databases. We open them one by one using “sqlite3” and navigate until we find our previously entered credentials in plain text:

As we can see, with just a basic understanding of the system architecture and databases, we have been able to exploit the data storage system.

g) Analyzing “Insecure Data Storage 3”

Next, let’s proceed to analyze the next app, “Insecure Data Storage 3.” The goal once again is to determine where the entered credentials are stored and how to obtain them.

As we can observe in the source code analysis, a temporary file is created with the name “uinfo+ID number” in the default directory.

We verify that when we press the SAVE button and receive confirmation that the credentials have been successfully stored, a temporary file named “uinfo+identifier” has been created in the package directory “jakhar.aseem.diva.” This file contains our credentials in plain text.

h) Analyzing “Insecure Data Storage 4”

Next, with the same operational objectives, we’re going to analyze the app “Insecure Data Storage 4.”

Studying the source code, we can see that the credentials are saved in external storage, in a file named “.uinfo.txt.” Without further ado, let’s proceed to verify that this file is where it’s supposed to be, and whether it exists and contains our credentials.

Here we observe the location of the “.uinfo.txt” file and its plain text content.

Podemos ver que la seguridad brilla por su ausencia en estos cuatro últimos casos expuestos, y lamentablemente no se trata de casos aislados ya que estas fallas de seguridad han sido descubiertas en numerosas aplicaciones android.

i) Analyzing “Input Validation Issues 1”

Indeed, these cases highlight significant security vulnerabilities in the analyzed Android applications. Unfortunately, such security flaws are not isolated incidents and have been discovered in numerous Android applications. It’s essential for developers to follow secure coding practices and ensure that sensitive data is properly protected, stored, and transmitted to prevent these types of vulnerabilities.

The scenario you described involves exploiting a classic “SQL Injection” vulnerability. By entering the input ” 1′ or ‘1’=’1′– ” in the search field, you effectively manipulate the SQL query to retrieve all stored credentials. This vulnerability occurs due to inadequate input validation and insufficiently sanitized user inputs, which can allow malicious SQL code to be executed inappropriately. This is a critical security issue that developers need to address by implementing proper input validation, parameterized queries, and other security measures to prevent such attacks.

This security flaw is resolved by implementing a simple input sanitization function for the characters entered in the search field.

j) Analyzing “Input Validation Issues 2”

Now we are going to analyze the app “Input Validation Issues 2” with the aim of finding vulnerabilities. Let’s go to the source code to see what we can discover.

We can see that there is no data sanitization of the input, so it will execute any path we put in the app’s field as if it were a browser. This way, we can view the contents of files stored on the device, as well as connect to websites and FTP servers, among other things.

To verify that we can indeed read sensitive information from the device without any issues, let’s input the path of a file “file:///mnt/sdcard/.uinfo.txt” that contains sensitive information. We will see how it displays the content of the file on the screen.

As we can see, this is a very serious security flaw that can be fixed by adding a simple input sanitization function to the source code. This function should only allow the execution of addresses that start with “http” or “https”.

k) Analyzing “Access Control Issues 1”

Next, we’re going to analyze the app “Access Control Issues 1.” The goal is to access the application’s credentials from outside the application, bypassing the access controls. Without further ado, let’s dive into the source code and analyze it.

We can see that when the “VIEW API CREDENTIALS” button is pressed, it triggers the “intent” “jakhar.aseem.diva.action.VIEW_CREDS.” Therefore, if we call it using “adb shell am start -a” and start the “intent,” we can observe that there is indeed no access control filter, and we can directly access the “API CREDENTIALS.”

We execute the command line and see that it displays the API CREDENTIALS on the screen.

l) Analyzing “Input Validation Issues 2” con Drozer

Now we move on to analyze the app “Access Control Issues 2.” The goal is to access the credentials directly, bypassing the security filters of entering a correct PIN number.

In the image above, we can observe how the code makes a call to “jakhar.aseem.diva.action.VIEW_CREDS2”, checking the entered PIN number to return either the credentials or an error message.

Continuing to explore the application’s source code, we can see in “jakhar.aseem.diva.APICreds2Activity” how it checks the entered PIN number. If the result is “true,” it returns an error message. However, if the result is “false,” it displays the credentials on the screen that we want to obtain.

Next, we’re going to need to use “drozer,” a tool that allows us to execute commands with the parameters and values we consider appropriate. It enables us to “inject code.”

To download and install “drozer” on our machine, as well as to download “agent.apk” and install it on the emulator, you can obtain them from the following website: https://labs.mwrinfosecurity.com/tools/drozer

On our “androl4b” machine, “drozer” is installed by default, but we need to download the “agent.apk” file from the aforementioned website to install it on the emulator and be able to use “drozer.”

Now we run “drozer” on the emulator and connect to it from the virtual machine using the command “drozer console connect.” This way, we obtain the drozer shell, ready to input commands and inject the code that allows us to bypass the security filters of the PIN number and obtain the credentials.

We need to perform a code injection in such a way that the “pin” check gives us a “false” value, allowing us to obtain the credentials. This can be done by executing the command “run app.activity.start –component jakhar.aseem.diva jakhar.aseem.diva.APICreds2Activity –extra boolean check_pin false” in the “drozer” console. Once the command is executed, as shown in the image, we receive the credentials on the emulator screen.

m) Analyzing “Input Validation Issues 3” con Drozer

Now we move on to analyze the app “Access Control Issues 3.” The objective is to access the credentials directly by bypassing the security filters without entering a correct PIN number.

What we need to obtain are the following credentials that are obtained after entering the correct PIN number:

Without further ado, let’s dive straight into analyzing the source code. In it, we can observe the error message “Please Enter a valid pin,” and at the end of the code, we see what interests us the most: it accesses the “AccessControl3NotesActivity.class.”

Let’s study the source code of “AccessControl3NotesActivity.class,” and in it, we can observe how, upon obtaining a valid PIN number, the application accesses and displays the credentials on the screen, through the call to “getContentResolver().query(NotesProvider.CONTENT_URI,)”.

(Here we can see the call)

If we go to the source of NotesProvider and look for the value of “CONTENT_URI,” we can see that its value is “content://jakhar.aseem.diva.provider.notesprovider/notes.” We can also see from here the database to which the query must be made, once the “pin” number has been correct after validation.

In possession of all this knowledge, we can now make our query to the database through “drozer” to obtain the results without needing to enter any correct “pin,” thereby bypassing the security filters.

In the same way, we can make the query through “adb shell,” as shown in the image, obtaining the same results.

Once we have finished with the analysis of the “Access Control Issues” apps, we move on to the analysis of the last application of interest in this laboratory.

n) Analyzing “Hardcoding Issues 2”

In the “HardCoding Issues part 2” app, the goal is to find out through the source code where the password is and what it is, in order to gain access.

Examining the source code of this application, we can see that a call is made to “Divajni()”, specifically to the “access” function.

Knowing this, we go directly to view the source code of “Divajni,” which we find in the code panel on the left. Here we can find the access() function that was called in the previous code, and at the end of the code, we can see that it invokes the library “divajni.so.” Now, this is our goal: to find it and access the content of the “divajni.so” library where our access key is located.

In the “resources” of the application, we can find the “lib” folder where the application’s libraries are located, and among them, we find “libdivajni.so”:

Once we have located the “libdivajni.so” file, we proceed to perform a screen dump of the “.rodata” section with “objdump”. As a brief explanation, the “.rodata” section is a data section where constant values are stored, and initialized data is placed. It’s worth noting that the data in the “rodata” section is never modified.

To perform a dump of this section, we use the command as shown on the screen, “objdump –s –j .rodata libdivajni.so,” or we can also obtain the same results through the command “readelf –x .rodata libdivajni.so.” In this way, we can observe that we have obtained a string of characters: “olsdfgad;lh..dot”. By entering this string of characters in the password field, we can see that it is indeed the correct password, and we gain access correctly.

4. Conclusions

At this point, we conclude the analysis performed on the Apps of this DIVA laboratory. We have conducted a static analysis of the laboratory apps, studying the source code step by step, and exploiting numerous vulnerabilities to obtain the expected results.

According to the “Mobile_Top_10” from OWASP, we have exploited the following vulnerabilities:

1. Improper Platform Usage

2. Insecure Data Storage

4. Insecure Authentication

5. Insufficient Cryptography

6. Insecure Authorization

7. Client Code Quality

9. Reverse Engineering

To verify the vulnerabilities exploited throughout the analysis of all the Apps studied in the DIVA laboratory, we can make use of the “OWASP Mobile Checklist.”

In the next article (part 2), we will see how to conduct a dynamic analysis of an Android application that simulates a banking App. We will explore how to study the network traffic by observing the incoming and outgoing connections it makes, as well as its various authentication methodologies, among other things.

If you liked it, or found this article useful, you can treat us to a warm crypto-coffee 😉

BTC: bc1qexsdm4auh6gf7fvdteas8s0lyvvdhmf8m030z3

ETH: 0x87b3d25A9bc19F653aE597D4Cd256C8D49465da6

ZCASH: t1JtTthdmeB9pgqqQqokQRARuGzSXgypieZ