Mobile applications and their security is a huge problem these days. With over 255 billion mobile applications downloaded in 2022, there is just no denying that mobile applications are prevalent. This puts a lot of pressure on mobile application (security) testing. In this article, I'd like to talk about security testing and show an example of how an attacker can leverage a poorly created app.
Disclaimer: I have originally written this article for the Blogathon contest of the ShiftSync community. If you want to check the whole article and much more consider joining the community!
Introducing the problem
Imagine you are a small company that came up with the idea to create an app that would allow the users to rate the local pubs and breweries they have visited. You did your due diligence and figured out that Android is quite popular in your target group. The next logical step would be to create an Android app, publish it on Google Play and have the users download it from there.
Many people perceive that mobile applications are secure by nature. The developers usually write the Java (or Kotlin) code, compile it, bundle it together with other stuff and distribute the executable file for the users to download. And for the normal human being, the executable file is just a combination of unreadable mess. One might conclude that if something goes wrong during development, no one should be able to figure that out right? Wrong.
Let's go back to our story. The company published its application, but the .apk file was also published to a site called Apkpure allowing anyone to download it. The application itself attracted the attention of some shady guys on the internet. In this example, we will assume the role of these individuals. The first thing, we have to obtain the application itself which can be downloaded from the Apkpure.
Disassembling the whole thing
The file that we downloaded is just an executable (ie. it is unreadable for the muggles such as we are). To get the readable code, the attacker would usually use a decompiler which is just software that performs the reverse process of code compilation. There are various decompilers available, but in this case, a simple JADX (Dex to Java) decompiler should do the trick. What is great about this tool is that it also has a GUI version which makes the reverse engineering process much easier.
Having a code available, the attacker would start looking for interesting parts within the codebase. In this case, it might be for example secrets. By secrets, you can imagine database passwords or the API tokens to the third-party service you might be using. It is something you wouldn't want any attacker to get their hands on. There are many ways for an attacker to look for secrets. One of them would be to write a simple regex looking for strings with a given pattern (for example AWS tokens are usually in the form of "AKIA" followed by 16 characters that can be either numbers or capital letters). In this example, we have a commercial secret scanner called GGShield by GitGuardian.
Using this approach we were able to find an API key for Flurry. This is a simple mistake that could have been prevented right in the development phase as it could have been discovered early in the cycle. Many of these tests could be automated.
So to sum up the problem, the attacker was able to decompile the original APK file using a JDEX decompiler to obtain secrets that can be later exploited.
MAST as a solution
Now that we have explained a real-life scenario and showcased the problem, we should also speak about how to prevent it. The best prevention comes from the use of automation, especially automated testing. This is where MAST (Mobile Application Security Testing) comes in. It consists of the combination of various tools and processes that can be used automatically throughout the build and testing phase of the SDLC.
We can for example use a SAST (Static Application Security Testing) tool to search for the vulnerabilities within the codebase and binaries. Then we can run a DAST (Dynamic Application Security Testing) scan analyzing a running application to look for vulnerabilities that might not be evident from the code and could be only visible after running the app. On top of that, we can also use emulators that are available for both Android (AVD Manager) and iOS (iOS Simulator comes natively with Xcode). We can also leverage device farms provided by AWS or Google Firebase to perform testing on mobile devices hosted in the cloud.