Mobile Security Free Tools (Part 1) MobSF

Meeting some of your Static Application Security Testing (SAST) needs using MobSF

Intended Audience

This article should be helpful to anyone working for a mobile application company in the following areas:

• Security and Compliance
• Legal
• Development
• Engineering

Background

MobSF is easy to use, free, and gets you going with mobile app security scanning if you don’t have one on hand. Here’s how I installed, deployed and starting using it at scale.

Installation and Deployment

1. Follow the steps in GitHub and this handy Medium article on initializing it in Docker.
2. Once you run: docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf
3. Then input http://0.0.0.0:8000/ in your browser and you should see something like this:

From there it’s just drag, drop, and download your PDF with the report.

How I use it at work

The report shows all the findings in your mobile applications that’s publicly available. Think about it. Anyone, anywhere, can download your APK and sift through it. Are you really sure everything has been bundled up securely? Well, MobSF gives you the unbundled version of those problems in the following sections:

App Permissions

Some of the permissions your apps can have may be deemed “dangerous” and it’s with those issues I would discuss with the developers to see if it’s something that can be removed.

There’s a lot to care about in this section, namely if your app functions differently than what you intended, but there tends to be a lot of false positives, so keep this in perspective.

</> Code Analysis

Here are some typical issues that come up in this section:

• MD5 is a weak hash known to have…
• Potential information that could be logged
• IP Address disclosure
• SQLite Database that executes raw queries
• Files may contain hardcoded sensitive information like usernames, passwords and keys
• App can read/write to external storage

Keep in mind a lot of these are not taking into account the customization in what your App is configured to do and how it actually operates with the user.

National Information Assurance Protection Profile (NIAP)

This section identifies where your app does or does not follow the functional and assurance components per platform.

The sections will be categorized by Identifier, Requirement, Feature and Description. I don’t see too many findings from my reviews in this section and I’m wondering if this is because the platforms themselves don’t allow you to run if it violates any of it.

Domain Malware Check

Based on my research, this section basically “retrieves domains from binaries and compares them to non-malware domains stored in its database.”

One to thing to review here is if any backend URI’s are exposed or if these links are indeed part of your domains.

Trackers

Here you want to see things like Client Operations services (like Helpshift), Game Ads (like Unity3D Ad, Facebook etc.,), hosting services (Firebase) and other links that your technology teams are aware of. What you don’t want is your legal and security teams to be scratching their heads wondering what these Trackers are.

Hardcoded Secrets

Here you’ll see potential keys and passwords that were hardcoded to your app. Now if you’re in compliance/legal, don’t be alarmed, a lot of these are API keys that your teams are using for crash analytics and other types of reporting. But, if there are ones that go like AWS KMS, then you’re in trouble and need to IMMEDIATELY remove it.

Where does it fit in SDLC?

When it comes to the complete picture of SDLC, namely…

[Developing > Building/Testing > Acceptance > Production]

…This tool is placed somewhere between Development > Building/Testing.

…TO BE CONTINUED