Android Pentest: Automated Analysis using MobSF
MobSF is an open-source tool developed by Ajin Abraham that is used for automated analysis of an APK. This is a collection of tools that run under one interface, perform their own individual tasks (like Jadx, apktool etc) and display their results under a common interface. These reports can be downloaded in a PDF format too and give out detailed analysis with necessary screenshots as well. You can download MobSF here. In this article, we’ll be walking through the installation phase in Ubuntu OS and guiding you through various options that this tool has to offer.
Table of Content
- Landing Page
- Signer Certificate Analysis
- Application Permissions
- Browsable Activities & Network Security Analysis
- Manifest Analysis
- Code Analysis
- Related to Malware Analysis
- Hardcoded secrets
- Activity Components Present
- Files Present in APK Packages
- Dynamic Analyzer
- Logcat Stream
- API Monitor
- Downloading Reports
To install MobSF, create a directory and follow the commands:
git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git cd Mobile-Security-Framework-MobSF
We need to install dependencies before we are able to run:
apt-get install python3-venv pip3 install -r requirements.txt
Once done, we can run the setup file to install MobSF and all the components automatically
Now, to run MobSF we execute the run.sh file. As one could interpret from the screenshot below that MobSF would be running on a local server on port 8000.
Now let’s open the link in the browser and see if MobSF was installed properly or not.
Now that the MobSF is up and running, we can drag a dummy APK (in this case, I’ll take InjuredAndroid by Kyle Benac (here)) into the MobSF interface and see what happens. After waiting for a couple of minutes we could see that static analysis of the APK is done. Now here on the landing page, we can see that a severity score is given. The higher this score the more secure app is. Next, hashes, filename and size of the APK are also given. In the third column in the first row, we can also see the package name, main activity, min SDK version and the application version as well. The description of the application is also given.
After scrolling down a little bit, here’s what all we can see:
- In small cards, we see different application components
- Dynamic analysis option that will help MobSF conduct run time analyses
- Option to view decompiled code. This is the code that is generated by apktool. Generally, the resources file would also be decoded. It is also possible to view smali code. It makes it easier to segregate and view source code in separate java classes using this.
Signer Certificate Analysis
In the certificate column, we can see the signer certificate where one can find important information about the developer, country, state, type of algo, bit size etc.
Further, we can see all the permissions an application has. There are various permissions that are categorized as dangerous or normal. It is important from a security analyst’s point of view to understand which permissions can lead to further damage. For example, if an application has access to external media and stores critical information on the external media it could prove to be dangerous since the files stored on external media are globally readable and writable.
Browsable Activities & Network Security Analysis
Next, in the browsable activities section, we can see all the activities that have implemented a deep link schema. Please refer to the article here to understand all about deep links, its implementation as well as exploitation.
In the network security section, one can find some details about network security issues related to the application. These issues can lead to critical attacks like MiTM sometimes. For example, in the screenshot below, one can find that the application isn’t using the SSL pinning mechanism implemented.
In the next section, MobSF has analysed the manifest file. One can find many folds of information from the android manifest file like which activities are exported, if the app debuggable or not, data schemas etc. For reference look at the screenshot below.
One of the most interesting features of the MobSF tool is the code analysis section. In this section, we can see that MobSF has analysed and compared some behaviour of the application based on industry security standard practices like OWASP MSTG and mapped the vulnerabilities with OWASP Top 10. It is interesting to see CWE mentioned and CVSS score being assigned here which might help various analyst scenarios and help the creation of reports way easier.
Related to Malware Analysis
MobSF also hosts a section where an APKiD analysis is given. APKiD is an open-source tool that is very helpful to identify various packers, compilers, obfuscators etc in android files. It is analogous to PEiD in APK. Here one can see that it has detected an anti-vm code in the APK.
Something related to malware analysis is the domain malware check feature. Here, MobSF is extracting all the URLs/IP addresses that are hard-coded or being used in the application and shows its malware status as well as uses ip2location to give out its geolocation as well.
A comprehensive strings analysis is also available. People who are aware of malware analysis know about strings in-depth but for those of you who don’t, strings are ASCII and Unicode-printable sequences of characters embedded within a file. Extracting strings can give clues about the program functionality and indicators associated with a suspect binary. For example, if an APK shows something as an output so that stream would be called and hence shown in the strings. This is not the same as strings.xml file. Many times, a third party IP address with which APK is communicating gets visible here. This is essential from a malware analysis point of view.
One can also find hardcoded emails in MobSF. This is all done using the decompiled source code. Often a pentester can find critical email IDs that were being used as a credential on a third party site, say, to access the database.
Just like emails, URLs are often found hardcoded as well. One can find juicy URLs that are being used sometimes. Oftentimes analysts find malicious URLs being accessed as well or even a C&C server.
Oftentimes developers have this habit of storing critical keys like AWS ID and credentials in strings.xml and use an object as a reference in java activity. But doing this doesn’t help in any which way since strings.xml can be decoded easily.
Activity Components Present
A list of all the activities present can also be scrolled using MobSF. This gives an insight into the skeleton of the android APK. Also sometimes jadx replaces the real names of the class with some random letter if the developer has applied obfuscation, MobSF can associate its real name too (doesn’t happen all the time or in cases of strong obfuscation).
Quite similarly an analyst can also traverse services, broadcast, providers and content receivers along with all the files present in the APK archive to create a map of all the resources present in the application.
For dynamic analysis, we’d need to fire up android VM in genymotion first. Here I’ve created an android VM on version 7.1
When you press the dynamic analyser option present on the top navigation pane, MobSF will automatically attach itself to VM running if MobSF and genymotion are running on the same base machine. However, if MobSF is in another virtual machine, you might have to attach MobSF agent to genymotion’s VM’s remote IP and port. Once it is attached, we see the following screen.
Under the analyzer status bar we can see various default frida scripts available that would check various basic vulnerabilities like SSL Pinning bypass and Root detection checks. If you haven’t read about frida, please do so by going here. There are other auxiliary scripts as well that lets an analyst enumerate various classes and also capture string comparisons in real time (again helpful for malware analysts point of view). Then simply click on start instrumentation and the selected scripts will be attached to the application automatically. Hence, if I have selected SSL Pinning bypass script and traffic is getting captured (visible in log or API monitor later) that would mean SSL Pinning has got bypassed.
Now further, to analyse activities for vulnerabilities one can see two buttons on the top for both exported and non exported activities
Similarly, if one doesn’t have to make do with pre-configured Frida scripts, it is also possible that Frida script be pasted in the text box on the right. There is also a dropdown box that would load those scripts. You can also edit the same.
Logcat can also be viewed in MobSF’s native environment. There’s a button at the top menu that lets one view this.
Just like logcat monitors device logs, APIs can also be monitored. APKs use various APIs in real-time to perform various functions, for example, the Base64 library.
Hence, if a function is using this API and decrypting a value we can see that value here and decode that. For example, down below you can see the return value of once such function in Base64.
Once you have done the analysis, it is possible to download the report by sliding the menu bar slider on the left-hand side and click generate the report.
You might notice some errors while generating reports. To resolve this, you can follow the below command and install wkhtmltopdf module:
apt-get install wkhtmltopdf
Now, once again if you click on a recent scan bar, you’ll see static and dynamic report generation options.
The report looks something like this:
MobSF is a great tool for the conduction of automated analysis on android APKs. It doesn’t cover analysis of all the vulnerabilities and many tests can only be conducted manually but it is a nifty little tool that helps analysts up to a great extent. Thanks for reading.
Author: Harshit Rajpal is an InfoSec researcher and left and right brain thinker. Contact here