Vulnerability Analysis in Android Applications (2)
1. Introduction and Objectives
In this article, we will continue with the analysis of Android applications. The objectives and the laboratory setup remain the same as in the first part.
For more information about setting up the analysis laboratory, you can refer to the first part: “Vulnerability Analysis in Android Applications (1)“.
In the following sections, we will conduct a brief analysis of “InsecureBankV2“. As the name suggests, it is a banking app that has certain vulnerabilities that we need to identify.
As seen in its official repository, this application has a significant number of vulnerabilities. However, in this article, we will focus only on exploring a few of them as proof of concept.
Since we have covered static analysis in-depth with DIVA, here we will perform a more surface-level static analysis.
Later on, we will conduct a brief dynamic analysis of the application to understand its functionality and characteristics. This will allow us to do the same for future applications, particularly to observe behaviors, especially in applications that maintain connections with external sources.
2. Static Analysis of “InsecureBankV2”
In this section, we will study how to bypass the login system of the application. This will allow us to access other credentials and perform actions like bank transfers, among other things, all through the command line.
a) Acquiring Source Files
Just like in the previous article, the first thing we need to do is “decompile” and “disassemble” the .apk file to gain access to its source code. This can be done using command-line tools like “apktool” and others, but it can also be achieved more conveniently, automatically, and easily using the graphical application called “APKStudio.”
b) Bypassing the Application
Taking a quick look at the code in “AndroidManifest.xml,” we notice the following:
In this way, by using “adb shell,” we can see how we bypass the authentication screen by directly calling the “PostLogin” activity using the command:
“am start –n com.android.insecurebankv2/com.android.insecurebankv2.PostLogin”
We can observe that we effectively bypass the authentication screen and enter directly as authenticated.
Similarly, we can directly access the process of making a bank transfer by calling the “DoTransfer” activity from “adb shell” using the command:
“am start -n com.android.insecurebankv2/com.android.insecurebankv2.DoTransfer”
As we have seen in the previous article using DIVA, we can also make those same calls to activities and other resources using “drozer”.
Ej. “run app.activity.start –component com.android.insecurebankv2 com.android.insecurebankv2.PostLogin”.
c) Mitigation of the vulnerabilities found
There are a couple of ways to prevent these types of vulnerabilities:
- Firstly, the “android:exported” property should always be set to FALSE unless it is absolutely necessary.
- Secondly, if the application needs to be invoked from specific external applications, custom permissions can be added to the activity. This allows only those applications that request permission to invoke the activity to access the resources.
3. Dynamic Analysis of “InsecureBankV2”
Dynamic analysis involves studying the behavior of an application during its actual execution. When an application runs, it becomes a process within the system. To perform dynamic analysis, the application to be analyzed must be executed in a controlled environment. This allows for real-time monitoring, enabling the observation of the resources it accesses and the changes it makes to the system.
In this phase of the analysis, various tools are employed, such as “MobSF” and “Wireshark.”
To carry out a vulnerability analysis of the application and gather information about its files and permissions, we will use MobSF.
Mobile Security Framework (MobSF) can be downloaded from its official repository. It can be described as a framework primarily designed for analyzing vulnerabilities in mobile applications (Android / iOS / Windows). Its functionalities include malware analysis and security assessment. MobSF is capable of performing both static and dynamic analyses. It supports mobile application binaries along with compressed source code. It enables highly customized runtime security evaluations and interactive instrumented testing.
Through the use of “Wireshark,” we will study the application’s behavior in terms of its network communications. Wireshark allows us to analyze the network traffic generated by the application during its execution.
a) Install MobSF on our machine
The first thing we need to do is install the MobSF framework from its official repository.
In this particular case, we will install it on a Windows 10 machine that is oriented towards offensive security. This is “Windows Commando“.
The installation process is not too complicated, as you can see below.
Once the installation is complete, you can run MobSF by launching its “run.bat” script. This will start a web server on port 8000 of your machine, presenting you with a very intuitive interface.
We are now ready to use MobSF.3
b) Starting the application to analyze
To begin the exercise, we must first start the server that simulates the connection to the bank when we input the credentials. In the app preferences, we need to specify the host of the machine (192.168.1.107 in my case) and the server port (8888).
c) Analyzing the App with MobSF
After uploading the “apk” for analysis by MobSF, we have obtained the following information, which is relevant for static analysis. We can complement the information from the previous section with these results.
To perform dynamic analysis in a Windows environment, where we have installed MobSF, we first need to install an emulator. It is recommended to install Genymotion, which can be downloaded from its official website.
After its installation, you will notice that it requires VirtualBox to be installed on our machine. Pay attention to this, as currently, Genymotion Desktop 3.1 does not work correctly with the latest version of VirtualBox. Instead, you need to install version 6.0.24, as shown below.
Once VirtualBox in version 6.0.24 is installed, we can now start Genymotion without issues. It’s very user-friendly; let’s proceed to set up the emulator according to the specifications we provide.
Once the emulator is up and running, all we need to do is drag and drop the application we want to audit later with MobSF onto the emulator. This will automatically install the application on the emulator’s virtual device.
As we can see in the following image, after the application is installed on the emulator, it starts automatically.
At this point, we can proceed to the MobSF interface and perform the dynamic analysis.
For the execution of this analysis, MobSF provides us with various tools to interact with and observe the application’s behavior in real-time.
While conducting our penetration tests on the application, we can view the event log with “logcat,” which provides us with the option to stop it at the end of the page. This is very useful for identifying security vulnerabilities in the application’s code related to event logs. Developers often compile applications in “debug” mode, leaving certain sensitive information unprotected.
Finally, we can generate a detailed report of the entire analysis conducted.
d) Analyzing Network Traffic
Among the dynamic analysis options provided by MobSF, we can find the analysis of the traffic generated by the application under audit. As shown below, it gives us the ability to set up a combined environment with “OWASP-ZAP” or “BurpSuite” as a proxy to capture network packets and make requests to the app. We will complement this environment with “Wireshark” for the study of network traffic.
After studying the generated report, we can see that when the app establishes a connection to the server to check the login credentials, it also connects to a database.
There’s no need to delve deep into the source code to find “TrackUserContentProvider,” where we can observe that no login credentials are needed to access the database. Moreover, we obtain the name and table of the database in plaintext, where sensitive information is stored. This is a significant security flaw.
As we can see, upon entering our username and password, the request is sent to the server. After several checks, which are easily visible in the application’s source code, we receive the error message “Invalid Credentials!!!” as a response.
However, what happens if we examine the network flow? As we can see in the captured packets with “Wireshark,” the information sent to the server is in plain text, without encryption. This means that any attacker who performs a MITM (Man-in-the-Middle) attack to capture network traffic can obtain the login credentials for the banking app, with all the potential consequences that this entails. This is a serious security flaw.
e) Other analysis tools
We can find multiple tools for conducting dynamic analysis.
If we want to perform dynamic analysis in a “private” environment within our own secure setup, we can consider using “DroidBox” and “AndroidSwissKnife“. The latter is a great option, as it includes “DroidBox” along with many other interesting tools.
I won’t demonstrate how to develop a specific dynamic analysis environment, as that is not the goal of this exercise. However, I encourage you to explore and experiment with all these types of environments. Likewise, I encourage you to make changes to their source code (open source) and develop your own tools.
We can highlight the following “online” engines and tools for conducting analysis of this nature:
f) Analysis with VirusTotal
Below, we will see the automatic analysis conducted by the “VirusTotal” platform of the application in question. The results can be found at:
Furthermore, we can verify that the information obtained from the online analysis is cross-referenced with other “analysis engines,” providing almost identical results.
4. Conclusions
We have conducted a brief analysis of “InsecureBankV2”. The static analysis was carried out by studying the application’s source code. Subsequently, we performed dynamic analysis using MobSF and Genymotion to analyze the application’s behavior. We further examined the app’s network behavior by monitoring and capturing traffic. Through this, we discovered that the app doesn’t encrypt its communications, potentially exposing sensitive information in plaintext.
In OWASP’s “Mobile Top 10,” we can confirm that this application exhibits the following vulnerabilities:
1. Improper Platform Usage
2. Insecure Data Storage
3. Insecure Communication
5. Insufficient Cryptography
6. Insecure Authorization
7. Client Code Quality
8. Code Tampering
10. Extraneous Functionality
In conclusion, it is crucial to emphasize to developers the importance of implementing input character sanitization functions in the forms of applications, along with establishing secure network communications using protocols like SSL/TLS.
For pentesters, it’s essential to underscore the significance of maintaining a disciplined approach to using the “OWASP Mobile Checklist” in order to effectively perform thorough vulnerability analysis of mobile applications.
If you liked it, or found this article useful, you can treat us to a warm crypto-coffee 😉
BTC: bc1qexsdm4auh6gf7fvdteas8s0lyvvdhmf8m030z3
ETH: 0x87b3d25A9bc19F653aE597D4Cd256C8D49465da6
ZCASH: t1JtTthdmeB9pgqqQqokQRARuGzSXgypieZ
