Introduction
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
Workstation
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 https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
Install MobSF
First, clone MobSF from it’s Github repository at https://github.com/MobSF/Mobile-Security-Framework-MobSF.
$ git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git
$ cd Mobile-Security-Framework-MobSF
$ ./setup.sh
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 www.postman.com, 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).
E.g.
$ 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.
Amazon Web Services (Access Key ID): AKIA[0-9A-Z]{16}
Amazon Web Services (Secret Key): [0-9a-zA-Z/+]{40}
Google Cloud Platform (OAuth2): [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}
Google Cloud Platform (API Key): [A-Za-z0-9_]{21}--[A-Za-z0-9_]{8
Source: i https://github.com/odomojuli/RegExAPI
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.
Traffic Capture and Decryption
If you’re a packet monkey like me, you’ll want to fire up Wireshark to be able to capture the traffic and look at the packets. NOTE: The traffic will be decrypted and recorded by mitmproxy, but in order for mitmproxy to see all of your mobile traffic, your phone must beconnected via the lightning cable to your Mac and you must follow the steps in this section (even if you aren’t going to use Wireshark).
To connect your iPhone to the Mac and convert it into a virtual network interface, use a tool for OSX called rvictl.
Step 1: Connect a lightning cable from your Mac to your iPhone.
Step 2: Click on your iPhone in Finder on the left-hand side under Locations. This is a new change in Catalina from my previous article.
Step 3: Click once on the grey text underneath the title iPhone in the window. This will show the UDID off your phone, which you’ll need to right-click and copy the UDID.
Step 4: Next, we’ll use Remote Virtual Interface Tool (rvictl) in order to turn your iPhone into a network interface on your Mac. (Figure 3).
$ sudo /Library/Apple/usr/bin/rvictl -s <UDID>
This should then create a new interface named rvi0.
NOTE: You must run the rvictl -s command every time you want to launch mitmproxy.
Figure 3: Adding an iPhone as a virtual NIC in OSX (Source: Knight Ink)
Now that your iPhone is acting as a network interface (NIC) for your Mac, all traffic going in and out of the phone can be captured by Wireshark. Simply load Wireshark after this is done
and point it at the new rvi0 interface.
Setting up mitmproxy
Before you can successfully perform this MITM attack, you need to install the mitmproxy certificates on your ME.
Installing the mitmproxy certificates
Open Safari (do not use Chrome)
Go to www.mitm.it
Click on the Other download option
Click Allow
On your iPhone: Go to Settings > About > Certificate Trust Settings > mitmproxy (switch on)
NOTE: Some apps implement certificate pinning that will prevent mitmproxy from working. There are workarounds for this, such as patching the app and using a jailbroken phone. However, this is out of scope for this article. You will know if an app has implemented pinning if you start the app and attempt to login and you get error messages.
Definition: What is certificate pinning? Pinning a certificate to a mobile app instructs the app to only accept a specific certificate from the API server limiting the risk of a person-in-the-middle (PITM) attack.
Start mitmproxy
From a shell, simply type:
$ mitmproxy
mHealth App Reconnaissance
Now that we’ve installed mitmproxy and set the proxy on our iPhone to point all egress network traffic at mitmproxy running on our workstation, we can now begin analyzing the traffic between our mHealth apps and the API endpoints they talk to.
In order to effectively find and exploit BOLA vulnerabilities in an API, you need to fully understand how the API works, what requests it expects, how it expects those requests to be formatted, etc. This is why we use mitmproxy to analyze each and every request the app is sending to the API. We need to find those object IDs in order to be able to manually change them in Postman to request data for patients or clinicians we shouldn’t be authorized to see.
Finding and Exploiting BOLA Injection Points
This next section will walk you through performing the network interdiction, analyzing an API request in mitmproxy, then taking that information and generating a manual API request in Postman. This section will rely heavily on screenshots with slight narration.
Disclaimer: This section contains some initial results from my mHealth vulnerability research. However, some of the company names have been omitted to protect the confidentiality of the participants in this research.
Figure 3: Network interdiction of a popular mHealth mobile app containing API calls with keys (Source: Knight Ink)
In the typical mHealth API, there are a number of resources in the backend that the mHealth app consumes:
User
Clinician
Patient
Medical Records
Clinicial Appointment Dates/Times
Across the mHealth RESTful APIs, each resource is represented by what’s called a JSON object sent from the mHealth app to the API as a URI, E.g.
JSON representation: {“patient_full_name”:”Alissa Knight”,”has_diabetes”:”no”}
API endpoints for patient records:
GET /api/v1/patient/1001
Or to post a new A1C test results (blood sugar level) data to a patient record:
POST /api/v1/patient/1001/medical_records/add_glycated_hemoglobin
Because a patient can have multiple objects from the same resource, e.g. medical_records, the API endpoint needs to know which object (E.g. medical record) a patient or clinician is requesting.
In this case, 1001 in the URI is the object ID the mHealth app is sending to the API endpoint for the GET request for the patient record of Paul Nutall. However, after inspecting the traffic from the mobile app, a hacker attempts to send the same GET request to the API server, but instead of requesting any of the object IDs she is assigned to as the clinician from 2001-2003, she sends a request for 1001 and the API vulnerable to BOLA, sends the patient record to the adversary for 1001 (Paul Nutall). (Figure 4).
Figure 4: Exploitation of BOLA with an mHealth app (object ID 1001) (Source: Knight Ink)
The object ID isn’t the culprit in and of itself. It is an integral part of the REST standard and part of the fabric of modern application development and design best practices.
However, when an ID is inserted in the URI call, it opens it up to sniffing and thus, manipulation by an adversary, a la BOLA. Simply put, BOLA exploitation is an adversary sending an API request for an object ID that they shouldn’t be able to access.
Solution
There are multiple controls that can be implemented into an app for preventing exploitation of BOLA vulnerabilities -- and any API vulnerability for that matter -- that extends from left to right. Security should be implemented during the initial development of the app and API to production deployment. In the code, a decision engine [3] should be implemented into the code that determines whether or not a specific user should be authorized to view an object they are requesting.
And of course, the best way to prevent exploitation of such vulnerabilities is ensuring that the app you’ve developed and published to interact with that API is the only app allowed to talk to it.
As a sponsor of this research, CriticalBlue’s Approov solution offers an SDK capable of allowing developers to compile security baked into the app that provides an easy-to-administer certificate pinning capability as well as the capability to arm the API with inspection capabilities able to identify and prevent synthetic traffic from reaching the API endpoint.
Learn more about Approov at http://www.approov.io
Summary
In part 1 of our series, we introduced this research into mHealth app and API vulnerabilities and some of the world’s largest mHealth companies that have partnered with us in an international joint effort to secure this new vehicle for delivery of healthcare services to anyone in the world over a mobile device.
In this part, I unveiled some of the findings in the static code analysis of the mHealth apps we looked at, as well as some of the findings on the network interdiction research.
In part 3 of our series, we dive deeper into the rabbit hole, unveiling more vulnerabilities and providing screenshots from successful exploitation of vulnerabilities in the mHealth apps and APIs we tested.
Like and Share. The best way you can support me in my continued content development and influencer efforts in cybersecurity is to like and share my article.`
Subscribe and Follow. Subscribe to my YouTube channel to get notifications of my VLOG, live streams, and Vodcast/Podcast episodes uploaded weekly and follow me on Twitter. To view my latest content calendar, visit our firm's web site at Knight Ink.