This series of posts is in no way showcases a full penetration test, which does a much deeper dive into an application’s risks and utilizes many more tools and manual techniques.
I wanted to start off this new blog series “Gone in 60 Mobile Apps” by reviewing 60 different Android mobile applications within the Agriculture industry. Future posts in this series will dive into other industries.
We chose to pull examples from the agriculture sector because of my history growing up on a farm in southern Minnesota. I gathered applications from large tractor manufactures as well as companies that provide upgrades / accessories to tractors.
If you haven’t decoded the title yet it’s based off of a great car movie “Gone in 60 Seconds.” In similar fashion, this review is meant to give a high-level overview of 60 different applications in a relatively short period of time.
This post isn’t designed to make you the world’s best penetration tester, nor was it written to teach you to be an expert with MobSF.
Our goal is to bring insight into how easy it is to identify issues within the mobile platform. Mobile applications should adhere to the same security testing as other applications utilized.
The tool of choice for this blog series is Mobile Security Framework (MobSF). MobSF is an automated mobile application pentesting platform. MobSF is well-maintained and includes an easy to use Docker image. Leveraging this tool with Android applications makes for a quick and easy discovery of any “low hanging fruit”.
Installation of MobSF with Docker:
· docker pull opensecurity/mobile-security-framework-mobsf
· docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
Then navigate to http://127.0.0.1:8000/
With MobSF up and running it’s pretty simple to start assessing a mobile application. With the start page displayed you can drag/drop the mobile application file onto the screen to get started.
After selecting or drag/dropping the Android .apk file, MobSF takes a short period of time to process the file. First, we wait….
Once the .apk file is processed you will be presented with the following screen:
Now that MobSF has loaded the application there are tons of features that we can utilize very quickly. These include:
· View the AndroidManifest.xml file (May contain API keys)
· View any file that makes references to web URLs (May contain the structure of the HTTP request and even usernames/passwords)
MobSF creates a list of files that might contain passwords, utilizes insecure functions, IP address disclosure, and files that attempt to detect a rooted phone
Now to break down the results of the 60 mobile applications:
After reviewing the mobile apps, I categorized them based on the highest risk issue identified.
Overview of the issues discovered:
High
· 2+ sets of basic authentication credentials
· Username / password combination
Medium
· Developer mode passwords
· Encryption key
Now looking at OWASP’s Top 10 Mobile risks categories:
All of the risks identified in this multi-part blog series would fall under the category of M10 – Extraneous Functionality. Developers of the applications left sensitive information within the source code. A user utilizing open source tools can view these extraneous items.
Diving into the high-risk issues we notice the use of hardcoded usernames and passwords within the source code:
Application setting a username and password in cleartext:
Basic authentication credentials in cleartext:
This is bad but it could be worse…. These credentials provide authentication to some of the referenced URL’s within the source code.
This issue is becoming more and more common as developers either forget to remove them or its being utilized to access a specific resource. Some very important questions arise from this issue:
· What permissions does the account have within the application?
· Can the accounts be used to access sensitive information?
· Can the accounts log into other company affiliated web portals?
There is no perfect answer on a way of keeping the hardcoded credentials within the source code. Attackers sooner or later will be able to get their hands on it through reverse-engineering. The following options should be implemented to remediate the issue:
· Remove the hardcoded credentials
· Disable debugging
· Turn on root / jailbreak detections
· Deploy anti-tamper technology
· Implement code obfuscation tools
It’s not the end of the world…. These companies just need some guidance in regard to integrating security into their software development lifecycle (SDLC) prior to deploying the mobile application. A great reference is the OWASP Mobile Security Testing Guide: https://mobile-security.gitbook.io/mobile-security-testing-guide/.
Keep a look out for future posts where we will evaluate other industries. As we get further down the line, we can begin to perform an analysis between industries to see how they compare from a mobile security standpoint.
URL Reference’s: