Welcome to part four of our long-running series on mobile application penetration testing. If you haven’t read our previous post, go take a look. Today’s post will finish up our coverage of MobSF report output from an Android APK file. In subsequent posts, we will ditch this report output get into some more lively aspects of testing such as MobSF dynamic testing, using Frida to bypass certificate pinning, proxying traffic with Burp, and even exploiting a known vulnerable application. We also have to cover iOS specific stuff, including MobSF output for it. So we are far from done with MobSF
In picking up where we left off with MobSF, we find Browsable Activities. Browsable Activities are a subset of exported activities that are specifically intended to be accessible from a web browser. We’ve all seen these. For example, clicking a link in a browser might open a specific activity within an app if that activity is marked as browsable for the data contained in the link. As seen in the screenshot, the link must meet certain criteria for scheme, host, and path. Improperly implemented browsable activities can lead to several vulnerabilities including classic vulnerabilities like path traversals and XSS.
In these sections we see some information on where HTTPS is forced to be used (or not), and some of the information we saw in an earlier post about the signer certificate. Again, these sections probably aren’t going to get you any bug bounties, but they do show some areas that could be improved upon. You should explore these a little more to determine if they may warrant being reported in a penetration test.
These sections are mostly straightforward. The code analysis section is just that – an analysis of the code. It’ll give you all sorts of output from static analysis that will be full of false positives, but it can point you in the right direction for further looks. For instance, it tells us the app is logging sensitive information. Well, in this case, the app probably isn’t logging sensitive information, though it could be. In the future, we will take a look at methods for examining both Android and iOS application logs.
The binary analysis section would typically detail the analysis of any shared object libraries (.so files in Android, for example) included in the application. It checks for security features in these binaries, such as non-executable stack, stack canaries, or whether the binary was compiled with stack protection, and whether symbol information has been stripped (which can hinder reverse engineering). In the image, this section shows “No Shared Objects found,” indicating that there are no shared library binaries within the application. Several other things could cause this, but won’t be discussed here.
I honestly didn’t even know what NIAP was until I wrote this article, so as you may guess, it isn’t of much importance to us penetration testers or bug bounty hunters (if I’m wrong, email me). Apparently NIAP stands for National Information Assurance Partnership, which is a U.S. government initiative to meet IT security requirements. NIAP Analysis would typically check for compliance with their Protection Profiles (PPs) or other security requirements. In this case, the section is empty, indicating that the analysis did not detect any NIAP-related identifiers or requirements, or that the application was not checked against NIAP’s criteria.
The file analysis section may be a little more interesting, at times. This section lists specific issues found within the files of the application package. In the screenshot provided, it shows an issue labeled “Certificate/Key files hardcoded inside the app,” referencing a file path related to Google’s Protocol Buffers (protobuf). This suggests that there are hardcoded certificate or key files within the application, which is a security concern because embedding sensitive data within the app can lead to exposure of this information if the application is decompiled or otherwise inspected. With that said, these issues are often false positives. But let’s look at this file to see if this is actually an issue.
That doesn’t look like a certificate or key file. I can’t say for sure why this shows up in the analysis, but it’s likely because MobSF is using some sort of pattern matching and got a hit on this file. This exact “finding” shows up in many MobSF reports on Android APKs.
While most of the sections found under the MobSF Malware Analysis heading aren’t of much help to the penetration tester or bug bounty hunter, we can find some interesting stuff in the APKiD Analysis section. Namely, this section will tell us about some protections the application may have against reverse engineering such as anti debug, anti disassembly, or anti VM code. These could get in our way during testing, and may require additional efforts on our part to bypass. A future post will detail the tool Frida and how we can use it to bypass protections.
Otherwise the most interesting thing in this section are the servers the application communicates with. If we suspect an app to be malware, MobSF may help us out a bit here. The Domain Malware section will even give us a malware status. Or, since we are penetration testers, we may find servers that could be in scope for the test. During mobile penetration testing at Brackish, if we discover additional endpoints during a test, we always bring them up to clients to determine if they would want them to be in scope. Clients sometimes don’t know every asset out there. MobSF can help uncover some of these assets.
This MobSF reconnaissance section may be very helpful for us penetration testers and bug bounty hunters. It has given me many quick wins.
The URLs section, true to its name, lists various URLs that the application may be interacting with or referencing within its code. More endpoints are always good when it comes to web application testing, and the same is true for mobile application testing.
The Firebase Database section shows the app is configured to communicate with a Firebase database, which is a Google cloud-hosted NoSQL database, and details the specific Firebase database URL, which can be an entry point for further investigation on data storage and retrieval practices. It’s possible there could be some sort of misconfiguration in an application under test. Additionally, we will enumerate other cloud databases later on in the test. Some tools that can be used for this are Cloud Enum and CloudBrute.
Email addresses and trackers are less interesting to us, and are self explanatory. I suppose you could report if a developer’s email address was leaked, but you aren’t going to get bug bounty money from that. If you’re doing a penetration test, there may be some value in reporting it as an informational depending on the app and the test.
The Hardcoded Secrets and Strings section can be very fruitful. Always look at these sections closely. You may find keys, passwords, or other random useful information in these sections. If you find a key, always test it for impact and report it if it is sensitive. Here is a repo that can help figure out if it is sensitive. For me, MobSF has found admin panel URLs and username password combinations for said admin panel in the strings section.
For example, in the screenshot from the YouTube APK’s MobSF ouput, you can see a hardcoded google_api_key and google_crash_reporting_api_key. Unfortunately these aren’t going to get you bounties. But it isn’t unheard of that MobSF will find keys that will actually get you bounties. Though, they are harder to find in bug bounty programs these days.
A common occurrence is that MobSF will find an API key and you don’t know what it does. It might not be in the KeyHacks repo, for instance. At that point you may need to do some legwork and read documentation to figure out what the key is for and if it is sensitive. I tend to error on the side of caution and report these keys, especially during pentests, since the application developers may have a better idea as to whether it is sensitive or not.
In our MobSF output, a few things of note remain, but have already been covered, or will be covered in subsequent posts. The Components section lists the various components of the Android application that were covered earlier – Activities, Services, Receivers, and Providers – key components of an Android application. If you don’t know what these are, please go read some more here or here.
Finally, the last thing I want to bring up is the Start Dynamic Analysis button. This feature allows you to run the mobile application in a controlled environment and interact with it in real-time to monitor its behavior. This can be particularly useful for understanding how the application operates at runtime, which can reveal security issues that static analysis might miss. This will be covered in a future post.
If I’m being honest, I’m tired of going through this MobSF output, and you probably are, too. It’s time we move on to some more hands on, exciting stuff. Stay tuned for the next post in this series!