Exposing Vulnerabilities in mHealth Apps and APIs

Last updated February 2021.

Eight and a half minutes can seem like an excruciatingly long time, say if you're amateur freediving or late for a job interview. However, the same time period can seem alarmingly brief if that’s all it takes to download a company’s app from a public app store, reverse engineer it and gain access to back-end systems.

And yet, the latter scenario was exactly what cybersecurity analyst and ethical hacker Alissa Knight was able to demonstrate in 2019, documenting her findings in a report titled ‘In plain sight: The vulnerability epidemic in financial services mobile apps.’ Using a rather simple MO — download publicly available financial services apps and use readily available tools to probe for vulnerabilities — Knight demonstrated “a systemic lack of application appropriate protection” in mobile apps from some of the largest financial institutions in the US and Europe.

Approov asked Knight to apply her incisive and insightful approach to vulnerabilities in mHealth apps and APIs. The report is now available. The results are shocking and the implications for the Healthcare industry are enormous.  

In July this year, we had addressed the issue of security in mHealth in an earlier article. Today, mHealth apps are being used across the healthcare value chain with patient usage projected to grow at a 10-year CAGR of 40%. The current pandemic has served to highlight and heighten the security challenges of healthcare apps. The current state of mobile security in the industry, however, is not so reassuring - with expediency, convenience, and “getting the job done” taking precedence over even basic mobile security principles. Ergo all this, without adequate attention to mHealth security, mobile healthcare will remain more risk than opportunity.

This is the status quo that our research partnership with Alissa Knight aimed to address. And that has to begin with a broad level understanding of the state of healthcare app security today.

Knight-testing mHealth Apps and APIs

A 2020 Security Report on Global mHealth Apps that tested 100 mobile telehealth, COVID-tracking, health commerce, and medical device apps came to this unnerving conclusion that over 70% of publicly available mHealth apps have at least one high-level security vulnerability. This is followed by a litany of issues including mishandled/weak encryption (91%), data leakage (85%), and unencrypted data storage (60%). More importantly, the study found that up to 83% of the high-level security vulnerabilities could have been addressed through prevalent application protection practices like code obfuscation, tampering detection, and white-box cryptography.

However, fixing issues in the app security only addresses one half, or less, of the attack space. Securing the app is good, but securing the APIs that service them is better. For bad actors, setting up scripts to impersonate mobile app traffic and using them against the APIs is a lot less work than reverse engineering apps. Hence this remains the most popular attack vector against mobile channels.

During the final months of 2020 Alissa assembled the components required to execute the first-ever vulnerability research campaign focused on mHealth apps and APIs. The objective of the research was to focus attention on protected health information (PHI), not only the most critical of personal information there ever will be but also the highest valued data on the black market.

This research has now delivered a report which provides the most comprehensive inventory of current healthcare app vulnerabilities and an urgent call to action to address them.  It is essential reading for everyone in the industry who is involved in architecting, building, and maintaining mHealth solutions.

This research into mHealth apps and APIs also goes a few steps further than Knight’s 2019 shake-up of fintech mobility’s passive approach to security. While earlier the process terminated with the extraction of hardcoded API keys, tokens, and credentials, this year’s research involved the participation of a number of major mHealth companies who  agreed to have their APIs tested.

What's in the Report?

The research kicks off by exploiting authentication and authorization vulnerabilities in established sessions between mHealth apps and their API endpoints. Using static code analysis, mobile apps are reversed back to their source code in order to perform manual queries and “find patterns that match API keys, tokens, and other secrets, such as credentials or private certificates.”

According to Knight, most of the exploits during this stage focus on Broken Object Level Authorization (BOLA) vulnerabilities and involve sending API requests for access to objects that should not be available. Though this is a common and critical vulnerability, according to the OWASP API Security Project, there are several controls that can be implemented to thwart these kinds of exploits. For instance, a decision engine implemented into the code can determine if a request has the authorization to view the resource that is being requested. An even better approach is to ensure that only untampered apps are allowed to interact with the APIs.

The report also exposes the sorry state of implementation of TLS in available mHealth apps. All of the apps tested allowed woman-in-the-middle attacks because they didn't implement certificate pinning. Why not? Sometimes it seems because the DevOps team are concerned about potential performance and availability issues. It doesn't have to be this way. There are ways to implement the full TLS toolkit easily and consistently without affecting app availability.

Today, there are robust API protection solutions designed specifically to secure mobile businesses against different types of techniques to gain unauthorized access to backend services, data, and assets. The best solutions even go a step further and provide valuable insights into the type and state of devices using the API to communicate with protected services, the share of API requests coming from potentially malicious sources such as bots, scripts, etc., and even identify requests from rooted/jailbroken mobile devices and repackaged apps.  

These, then, are some of the more significant takeaways in the report. For the more technically inclined, Knight also provides a deep dive into the requisite tools, processes, and setups as part of her research. This can provide the essential guide to your pen-testing team as they test your mHealth apps.  

You can download your copy of the report here