Overview
In this blog post, we’ll be taking a deep dive into the OWASP (Open Web Application Security Project) Mobile Top 10 – a crucial list of the most pressing security risks facing mobile applications today. By understanding these vulnerabilities, we can better prioritize our security efforts and ensure our mobile apps are fortified against potential attacks.
To bring these security risks to life, we’ll be utilizing the AndroGoat and AllSafe – two intentionally vulnerable Android applications designed for security testing and education. This will allow us to explore real-world examples of these threats in action.
Specifically in this part, we’ll be examining two critical vulnerabilities from the OWASP Mobile Top 10:
- Improper Credential Usage: We’ll examine how mobile apps can mishandle user credentials, leading to potential unauthorized access and data breaches.
- Insecure Authentication/Authorization: We’ll investigate how flaws in a mobile app’s authentication and authorization mechanisms can allow attackers to circumvent security controls and gain illicit access.
Several techniques demonstrated in this blog require a rooted android device. I recommend using an emulator such as LDPlayer for windows or Genymotion for Linux for this purpose. With that out of the way, let’s dive in and explore these OWASP Mobile Top 10 vulnerabilities in detail.
Improper Credential Usage
Credentials are the keys that grant access to your app’s protected resources or services. They can include usernames, passwords, API keys, digital certificates, or any other form of authentication or authorization data. Improper credential usage happens when these sensitive credentials are not properly secured, leaving them vulnerable to exploitation.
For example, an app that hard codes an API key in its source code is committing improper credential usage. If an attacker can de-compile the app, they can easily find and misuse that key. Similarly, if an app stores user passwords in plaintext or transmits them over an insecure connection, it’s putting those credentials at risk of being intercepted and compromised.
Testing for Improper Credential Usage
Scenario 1: Credentials Hard coded in Source code
Let us look at how we can test an app for Improper Credential Usage. We will be using the Androgoat application for this. Load up the apk in your favourite emulator and navigate to Hardcode Issue challenge.
The challenge is to find a promo code that will get us the product for free. We can use a static analysis tool like MobSF to analyse the apk and list out all plausible hard coded secrets. This would be the preferred way if we didn’t know what we were looking for. Since we know that we are looking for a promo code, the best way is to decompile the apk and look at the source code for the corresponding activity ourselves.
We can use jadx-gui to decompile the apk. Navigate to the HardCodeActivityClass and we see the responsible code.
Let us try the code,
Scenario 2: Insecure Storage of Credentials
Another scenario is storing passwords client side in SQLite databases or preference files. We will explore this as part of Insecure Data Storage vulnerability.
Insecure Authentication/Authorization
One of the most critical vulnerabilities highlighted in the OWASP Mobile Top 10 is the issue of insecure authentication and authorization mechanisms. These security controls are the gatekeepers of your mobile application, responsible for verifying user identities and granting appropriate levels of access. Understanding the pitfalls of authentication and authorization is crucial, as these are often the first line of defense against unauthorized access. By identifying and addressing these vulnerabilities, we can ensure that our mobile apps have robust security controls in place to protect user data and maintain the integrity of our applications. So, let’s dive in and uncover the security weaknesses that can undermine even the most well-intentioned authentication and authorization mechanisms.
Testing for Insecure Authentication
Scenario 1: Weak Password Brute force
We can use frida dynamic instrumentation to bruteforce weak PINs. To demonstrate this, I am using the allsafe app’s PIN bypass challenge.
To brute force the 4 digit PIN, we can easily try all numbers between 0001 and 9999. Let us look at the de-compiled source code to understand which function is responsible for PIN check. We can see the PIN encoded in base64 and could use it. But the aim of this exercise is to demonstrate the use of frida‘s dynamic instrumentation methods to brute force the PIN. This would be applicable even if the PIN was not stored in the client side.
Once we have the class identifier, we can create our own instance of the class and call the checkPin function with all possible values. Here is the frida script doing just that.
// Code for pinbypass.js
Java.perform(function () {
try {
// Load the PinBypass class
var pinbypass = Java.use("infosecadventures.allsafe.challenges.PinBypass");
// Create an instance of the class
var classInstance = pinbypass.$new();
for (var i = 9999; i >= 0; i--) {
// Pad the pin with zeroes
const paddedPin = i.toString().padStart(4, "0");
if (classInstance.checkPin(paddedPin)) {
console.log("PIN found: ", paddedPin);
break;
}
}
} catch (error) {
console.error("An error occurred in pinbypass:", error);
}
});
Invoke the script using the following command after launching the app.
// use frida-ps -Ua to find the pid frida -U <pid> -l pinbypass.js
Scenario 2: Insecure Logging
It is possible that developers may leave debug statements in the production build and insecurely log credentials to the console. Any app on the system with READ_LOG permission can read your apps logs. Let us look at this vulnerability with the example of Insecure Logging challenge in Allsafe apk.
We will use the logcat utility to view the app generated logs. There is an option to filter logs based on the process id as follows:
adb logcat --pid=<pid>
Let us type in our secret to the input box and press enter.
Monitoring the log, we get the following:
Testing for Insecure Authorization
Testing for Authorization vulnerabilities in android apps is quit similar to web application testing. I won’t go through practical examples here. Some common scenarios are:
Scenario 1: IDOR — Insecure Direct Object Reference
IDOR vulnerability happens when the application backend only checks whether the user is authenticated and doesn’t check if a user is supposed to access a specific resource. An example is a normal user being able to access the admin functionalities. Testing for this includes intercepting the API resources using a proxy and modifying the parameters and endpoints.
Scenario 2: Anonymous API execution
An app making a request to a backend API without any credentials or access token under the assumption that users won’t be able to make the same without the frontend app. Monitor of API request without any authentication headers.
Scenario 3: User roles editable
This happens when the backend trusts user input blindly. Try modifying user roles in API requests.