If you haven’t read the previous entry in the Mobile Application Penetration Testing series, check it out. In this post we will start in with a frequently use mobile application security tool – MobSF. This is a tool that you’ll pretty much want to use on every mobile test that you do. As said before, this series will be long-running. Mobile testing is a large world where there are multiple ways of doing things. MobSF is just one tool, but it puts out a lot of information – more to cover in one blog post. Today we will start with MobSF and the Android APK.
Hosted on GitHub, MobSF offers a plethora of features designed to perform static and dynamic analysis on Android and iOS. Its integration capabilities also extend to CI/CD pipelines, allowing for a more streamlined DevSecOps workflow. I know this sounds a little like an advertisement, but I just wanted to show people that have never heard what MobSF a little about it.
MobSF is such a great tool that some less-than-savory companies will simply run it on your mobile application, send you the report, and tell you testing has been completed. We don’t do that at Brackish. At the end of the day it isn’t going to find too many things worth reporting, and it will miss some of the big stuff.
What can it do?
MobSF offers a wide array of vulnerability detection capabilities. Some of them more useful than others.
If I’m going to be honest, while MobSF does a lot, it will rarely point you at a direct, actual bug that will get you bug bounty money. But sometimes it will!
Visit the GitHub for more installation methods, but the simplest way may be to simply use the docker commands they have listed:
docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latestAfter you get it running, you’ll be faced with a screen like this:
Remember when I told you that there will be many ways to do things in the mobile world? Well if you look at the search bar at the bottom, that’s what I was talking about. You can search in there for the APK you’re looking for, though it seems a little wonky at times. Alternatively, since we already obtained what we need, click the upload and analyze button to upload your file for analysis. It will take a little bit of time to complete.
After analysis has completed, MobSF presents the tester with a wealth of knowledge. But, please remember that this series of articles cannot cover everything in the mobile testing world. We will take some time to hit the highlights of this report, but I suggest you poke around yourself and learn a few things in the process.
Most of the stuff in the screenshot above is fairly self explanatory. You’ll see the App Scores on the left, but I wouldn’t mind them much, especially the security score. Under App Information you can see the app and package name, plus the main activity. The “Main Activity” is the entry point of the app—essentially the first screen that appears when a user launches the application from the launcher. YouTube’s actually seems a little strange compared to other apps.
Moving down the page we see this:
which has many more things that we will want to pay attention to, including our decompiled application code. Yeah, MobSF does this work for us. Click Download Java Code and you will get a zip file containing the source code of your application, which will come in handy. You’ll also see the very import Android Manifest XML file. You’ll always want to look at this.
But there is a lot more here than just the source code. Activities, services, receivers, and providers are all important parts of an Android application. So here is what they are:
The “Exported” count indicates how many of these components are accessible from other apps. “Exported” in this context means they can be invoked by other applications, which may expose them to various types of attacks if not properly secured. So, for example, there are zero exported providers. This indicates that none of the providers are accessible from other applications, which is usually a good security measure, limiting the scope of data sharing.
As mentioned, a very important file is listed here, the AndroidManfiest.xml. This file can be considered a hub of metadata for an Android application. All of the activities, services, receivers, and providers will be specified here along with permissions and other configuration details. As a tester, you should always take a look at this file.
One thing that you may regularly find in here are API keys for various services. These may or may not be sensitive, but should be investigated. Here is spectacular link that you can use to test if your API is sensitive – https://github.com/streaak/keyhacks
As you can see, MobSF serves as a comprehensive tool for both static and dynamic analysis of mobile applications. While it offers an extensive suite of features that can be integrated into a CI/CD pipeline for streamlined DevSecOps, it’s crucial to remember that MobSF is not a silver bullet. It may not catch every possible vulnerability or direct you to a high-value bug that could earn you a bug bounty. Therefore, its utility is best realized as part of a multi-tool, layered approach to mobile application security.
Experts in the field, like those at Brackish, know that while automated tools save time and provide valuable insights, they are not a substitute for manual analysis and targeted testing. Especially in complex environments where code behavior changes dynamically or where nuanced vulnerabilities like logic flaws exist, human expertise remains irreplaceable.
Stay tuned for the next article in this series where we will look at more of the MobSF output for our Android APK!