All That We Let In: Hacking mHealth Apps and APIs (Part 2)


Have you noticed recently that the number of API breaches seem to be rising, not ebbing? You’re not alone. As a matter of fact, the number of API breaches have been going up exponentially and it’s only getting worse as we move into 2021.

In part 1 of our series, I introduced my mHealth app and API vulnerability research and unveiled the trailer for this research.

In this part, I walk you through configuring your tools and performing the techniques I use in targeting and exploiting mHealth apps and APIs in my research campaign and unveil some of the findings from my research.

Many of the vulnerabilities found and exploited during the network interdiction stage of the research are classified as Broken Object Level Authorization (BOLA) vulnerabilities, once referred to as Insecure Direct Object Reference (IDOR) vulnerabilities. I’ll explain further below, but in summary, this is exploitation of vulnerabilities found in authentication and authorization of established sessions between the mHealth apps and their API endpoints.

Understanding Broken Object Level Authorization

Broken Object Level Authorization (BOLA) as its come to be known as, is the most systemic API vulnerability today. In every single one of the APIs I’ve tested and exploited, BOLA was leveraged to access data I shouldn’t have been authorized to read, write, put, or delete. Many of the vulnerabilities discovered in this research are BOLA vulnerabilities. But, just what is BOLA and why is it so difficult to protect against?

My favorite explanation of BOLA to a non-technical audience was conceived by Inon Shkedy [1]. Shkedy describes it as analogous to receiving a number from the coat check room of a party. When attending a party, you wish to check in your purse and coat at the coat check. The attendant takes your purse and coat and hands you a number. You realize that the number is nothing more than a piece of paper with the number 11 written on it with a blue ink pen. Throughout the event, you decide to modify that ticket and change the 11 to a 14 and pick up the purse and coat of whomever has the real #14 ticket. You create another ticket and write down 2, 3, 4 and so-on. Meanwhile, you’ve taken all of the items that don’t belong to you by simply modifying the ticket you were assigned or just creating new ones. This is akin to how the BOLA exploit works — an adversary sending the object ID from a resource they shouldn’t have the authorization to access, which the API accepts and provides you.

This can be summarized simply as a session management vulnerability — exploitation of authentication and authorization, two key components of session management. This answers the fundamental question “who am I” and “what am I allowed to do?”

Lab Setup

Before we can put “pedal to metal”, we need to setup our attack lab. In this section, I decompose the tools you’ll need to perform static code analysis of mobile apps and the tools used in performing vulnerability analysis and exploitation of APIs as well as how to install and configure them.

Mobile Phone

While it’s possible to reverse engineer iOS apps, I’ll be walking you through how to extract mobile apps off of an Android device where they’ll then be transferred to Google Drive, then to your workstation for reversing back to their original source code. Reverse engineering iOS apps, while a bit more difficult than Android, is possible. It’s simply out of scope of this article.

Install APK Extractor

In order to extract an Android app off your device, you’ll want — to ironically enough — install Apk Extractor from the Google Play Store. This tool will enable you to extract any app you’ve installed to a destination of your choosing, such as Google Cloud or a directory on your mobile equipment (ME). Once you’ve downloaded the mHealth apps you’re targeting, use Apk Extractor to pull it off your ME to Google Cloud as an Apk file, which you’ll download to your workstation. (Figure 1) I’ll walk you through setting this up in the next section, which you’ll then import into MobSF.

Figure 1: Apk Extractor in the Google Play Store (Source: Google, Inc.)

Set Proxy on your iPhone

Before mitmproxy can see any of your app traffic on your phone, you need to set your proxy to tell your ME to send all network traffic through the proxy you install on your workstation. To do this, simply go to Settings > Wifi > Info icon next to your wireless network > Configure Proxy > Manual

Server: <IP Address of your workstation>

Port: 8080


It’s no secret and should come as no surprise, that I’m an Apple user. While MobSF can be installed on multiple platforms, such as Linux and Windows, I’ll be using a Mac in this section. There are enough write-ups out there for installing MobSF for those distros without me having to recreate the wheel.

Install Xcode

You’ll need to make sure Xcode is installed before you can install any other apps we’ll be using on your Mac and can be easily installed from the Apple App Store.

NOTE: You must start xcode after installing it in order for rvictl to be installed into the correct location by xcode.

Install Homebrew

Homebrew is the package manager for OSX, similar to rpm or apt. It allows easy installation of software that exists in its repositories. Several of the applications we’ll be installing can be installed using Homebrew.

$ /bin/bash -c "$(curl -fsSL"

Install MobSF

First, clone MobSF from it’s Github repository at

$ git clone

$ cd Mobile-Security-Framework-MobSF

$ ./

Follow these steps for installation if you run into any issues.

Install mitmproxy

Installing mitmproxy now that we have Homebrew installed is trivial. Simply use the

command brew to install the mitmproxy package.

$ brew install mitmproxy

Install Postman

Download Postman from, a free API client that you’ll use to generate your manual API requests to the mHealth APIs by recreating the API requests you capture in mitmproxy.

Static Code Analysis

Static code analysis of a mobile app is simply taking the app and reversing it back to its source code for further analysis. Once you’ve done this, you can then perform manual queries using GREP and AWK to find patterns in the source code that match API keys, tokens, and other secrets, such as credentials or private certificates. (Figure 2)


$ grep —no-case “_key” <MobSF/uploads>

Figure 2: Static code analysis for keyword “_key” (Source: Knight Ink)

There are published REGEX patterns for other cloud service providers, p2p payment providers, and more on several Github projects. I’ve provided a few below for some of the major CSPs, such as AWS and Azure, but definitely check out the sites below for more. But to be honest, I’ve had more luck simply using “_key” as a search term using grep than fancy REGEX.

  1. Amazon Web Services (Access Key ID): AKIA[0-9A-Z]{16}

  2. Amazon Web Services (Secret Key): [0-9a-zA-Z/+]{40}

  3. Google Cloud Platform (OAuth2): [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}

  4. Google Cloud Platform (API Key): [A-Za-z0-9_]{21}--[A-Za-z0-9_]{8

Source: i


Network Interdiction

Interdicting mobile app traffic off of a ME is a relatively simple architecture. By connecting both the ME and workstation to the same wireless network, set the proxy of your ME to the workstation’s IP address running an SSL MITM tool, such as mitmproxy (Mac). Other tools exist for Windows or Linux, but this section covers setup using an iPhone 11 Pro Max and Macbook Pro running OSX Catalina.