Hey there, I’m Sviatoslav, I’m a QA lead at EVO, and I’ve been working as a QA engineer for more than eight years. I’ve been searching for insecurities in applications for more than four years, teaching security testing, and doing independent security audits and quality assurance. I also write a blog on security testing for beginners and a Telegram channel.
This article will be useful to both QA engineers and developers as the latter have more responsibility for application security on their hands. Some issues, including simple human errors, maybe avoided from start, when the mobile app is being developed. I’ll cover instruments that can help discover the basic weaknesses of any project.
Extra knowledge is never excessive. The more you know, the bigger your professional value is, and the more responsibilities and recognition you can have at your job.
Intro
I once wrote an article where I shared that I started my career as a manual QA engineer and then got interested in web insecurities analysis. How did it happen?
Usually, when you are doing the same job for a long time, it gets boring. So I decided to give it a try and learn how mobile apps get tested for insecurities. I found a list of Top 10 insecurities on the website called OWASP (The Open Web Application Security Project).
Back then, the list looked like this:
After learning about mobile apps’ top insecurities, I realized that half of those were similar to insecurities on the web. They are mentioned in the OWASP’s TOP 10 for web, which you all have probably seen.
The reason behind this similarity is the fact that native and web apps basically work in the same way. On mobile, a native app acts as a client. And while a browser acts as a client on the web, both send requests to a server. So you can apply half of the techniques for discovering insecurities on the web when searching for insecurities in native applications.
Let’s start by listing the instruments you need for fundamental mobile app security analysis. Then, I’ll explain how to apply them to Android app testing. iOS apps require a different approach that is better to cover in a separate article.
What We Need for a Start
The test environment, which is the app itself. We can use a DIVA app for that. It contains all the widespread mobile app insecurities so that you can practice discovering any of them.
A mobile device. An emulator like Genymotion, or a real device with the root access, since you won’t perform app penetration testing without it.
Santoku Linux. This distribution has been mainly created for Android application security testing. It comes with all the instruments for testing pre-installed.
That’s basically it.
Let’s look at the statistics of the occurrence of each of OWASP’s top 10 security threats. If we check the stats published in 2018, you’ll see what insecurity categories you should be paying attention to most when you audit a mobile app.
Now, let’s take a look at each of the categories. But we’ll start with M9 — Reverse Engineering because a pen test begins from it.
M9 — Reverse Engineering
Reverse engineering of the code of a mobile app is not a big deal. It’s a process of an unauthorized and straightforward analysis of
- the source code of the application;
- its libraries;
- algorithms;
- tables, etc.
To get the source code, you have to download the mobile application’s installation file (APK) to Santoku Linux, open Console, and perform a few simple commands.
Type unzip -d diva-beta base.apk. As you understand, the command helps unarchive the application and put all of its files into a diva-beta folder.
Then go inside this folder and perform the following command: d2j -dex2jar classes.dex. With its help, you decompile the code that’s located in this file. If you try opening the file without decompilation, you will see some weird stuff. After you perform the command, the folder will contain a new file called classes-dex2jar.jar. It will include the source code of the app that you can read and understand.
To open this file and see the source code, you will need an application called Jadx, installed in our Linux distribution. Let’s perform the jd-gui classes-dex2jar.jar. command.
After you initiate the command, the Jadx application should open. That’s where you will see the full source code and look for application security gaps.
M1 — Improper Platform Usage
From M9, let’s jump back to the start — M1. This category is about improper usage of the operating system functionality or platform security measures. Such cases occur quite often and may significantly influence the application vulnerability.
Since we have already acquired the app’s source code, let’s find an example in it.
A software developer used logcat when debugging the app to understand what errors were in the input field. However, during the compilation, they forgot to remove the debugging command.
What does it mean? It means that errors and warnings get logged. When a user fills in the form (e.g., with the credit card number) and receives an error message or a warning, the data they sent is stored in logs. It’s not hard to understand that hackers can easily access those logs.
You can learn more about this in this video.
M2 — Insecure Data Storage
In the case of physical access, a hacker can quickly enter the device’s file management system after connecting it to a computer. Many freely distributed applications allow hackers to access folders and personal data stored in them.
There are two things to keep in mind:
- Confidential data should be kept in the application encoded;
- Sometimes applications share data with other applications.
E.g., check the signup form in a mobile app.
As a user, I have signed up for the app. A software developer didn’t encrypt my data and also stored it in a folder accessed by other apps on my mobile device.
See how this data can be accessed in this video guide.
M3 — Insecure Communication
M3 is another well-known risk often neglected by mobile app developers.
Data transfer from and to a mobile app usually happens through the cellular connection or Wi-Fi. It is a well-known fact that hackers succeed in accessing users’ data via insecure transfers.
Hackers capture users’ data within a local network when connected to a compromised WiFi network via routers, cellular towers, and proxy servers. Or they use an application infected by malicious software.
Sometimes a user sends requests containing sensitive data to the server using HTTP protocol instead of HTTPS.
E.g., a user connects to a compromised Wi-Fi network created by a hacker. The hacker’s software analyzes all traffic going through to intercept data sent through HTTP protocol. A hacker will see the user’s credentials in the intercepted data.
Below, you can find examples of bad and good data transfers. You can also watch this video on traffic interception.
Wrong data transfer setup:
A developer should encrypt data so if a hacker overviews traffic by connecting to the same network, they won’t see the sensitive information. For example, we can make the hacker’s job harder this way:
M5 — Insufficient Cryptography
After reading the previous chapter, you now encrypt the data that you send and receive. However, if the encryption you implemented is weak, or algorithms that operate the encryption contain mistakes, the data can be breached again.
- There are three ways how hackers use cryptographic issues for their good:
- to get access to the mobile device itself;
- to monitor the traffic in the network;
- to use malware on the device that has access to encrypted data.
To understand what kind of encryption methods are used by developers, you can look at the source code you have already acquired.
A coder used the MD5 encryption method, which is also the easiest method to decrypt.
When you intercept a user’s request, you’ll be able to find data that seems to be encrypted.
However, if we go to any online decoder website and drop this hash into the tool, we’ll get that user’s real password in a few seconds.
M4 — Insecure Authentication
Poor authentication schemes allow hackers to imitate all actions performed by a user in the mobile app or on the application’s server. Weak authentication is quite widespread due to mobile device’s input form factor. The form factor insists on using short passwords that are often based on 4-digit PINs. Authentication requirements for mobile applications are quite different from traditional web authentication schemes due to availability requirements.
When it comes to traditional web applications, users usually connect to the network and authenticate in real-time. As soon as hackers realize how insecure the authentication process is, they imitate it or get around by sending requests to a server bypassing the mobile application completely.
For example, a hacker may use an app analyzer like Burp Suite. It’s just enough to analyze what pages the app contains.
Let’s take a look at the authorization request. We see data being sent to the server. Here, hackers can simply try to receive information from the server by imitating the user’s request. They go through places highlighted on the screenshot — to receive unauthorized access to user’s data.
- When you look at the request:
- pay attention to URLs;
- pay attention to the user type;
- try to substitute the token by one with admin rights.
- If you want to learn how to set up the analyzer to test mobile apps, you may want to check this article.
M6 — Insecure Authorization
Some people confuse M4 and M6 because both risks evolve around user’s credentials. Developers should keep in mind that M6 applies to the use of the authorization on behalf of a real user, while M4 is about a risk of a hacker bypassing the authentication process and signing in anonymously.
According to M6, as soon as a hacker bypasses the security mechanism and accesses the application on behalf of a legitimate user, their task is to receive the admin access. They try to send different requests in order to eventually get access to an account with the admin rights. Hackers usually utilize botnets or malware to make use of authentication vulnerabilities on a mobile device. As a result, they can launch binary attacks on a device in an autonomous mode.
They can also utilize Burp Suite — by sending admin requests from the account of an average user.
M7 — Client Code Quality
M7 originates from the poor coding culture when each team member sticks to different coding practices, which leads to misalignment in the final look of the code. M7 risk is pretty common, however hard to reveal. It’s not easy for a hacker to discover patterns of poorly written code as it requires too much manual work.
Poorly written code also leads to users experiencing slow request processing or the impossibility to download some data.
There was a scandal around WhatsApp when its engineers discovered that it’s possible to overflow the buffer by sending a specially crafted series of SRTCP packets. Hackers used this vulnerability to install spyware on smartphones. The vulnerability has been particularly exploited by the Israeli spyware company called NSO Group.
Do not use functions like this that can overflow the buffer:
M8 — Code Tampering
There is a simple rule. Do not download APK files from the 3rd party websites because hackers often tamper with the code of the apps to:
- receive unlimited access to other applications on your phone;
- and to act on behalf of a user.
As you remember, when we talked about M9, we reverse-engineered an app and accessed the source code. Now we can alternate it (e.g., implant a worm that will access data of other apps), and recompile it to publish the APK online, offering to download the app for free.
M10 — Extraneous Functionality
Before the application’s release to the public, developers often keep mentions of accesses to the internal servers inside the app’s code. This doesn’t affect the app’s functionality but if a hacker finds those accesses, it won’t be fun. Especially if what developers left inside is admin access to the system.
Let’s take a look at a page where you need to enter a password to access critical data. That’s how it can look in the source code.
A developer left a note here, informing us how to access the sensitive data. See more in the video here..
To sum up
In this article, you have learned about:
- OWASP’s Top 10 mobile vulnerabilities;
- instruments that help finding them;
- and programs you can use to train in finding them.
Having acquired new skills in in-app security testing, you’ll be able to take on more responsibilities and find vulnerabilities in apps you’ve been creating. Eventually, you may even specialize in cyber security, and professionals like that are in high demand on the market.
Do not forget that the information provided here is purely educational. Utilize this knowledge only with the agreement of the copyright holder.