100% of Tested mHealth Apps Vulnerable to API Attacks

Share this article on:

The personally identifiable health information of millions of individuals is being exposed through the Application Programming Interfaces (APIs) used by mobile health (mHealth) applications, according to a recent study published by cybersecurity firm Approov.

Ethical hacker and researcher Allissa Knight conducted the study to determine how secure popular mHealth apps are and whether it is possible to gain access to users’ sensitive health data. One of the provisos of the study was she would not be permitted to name any of the apps if vulnerabilities were identified. She assessed 30 of the leading mHealth apps and discovered all were vulnerable to API attacks which could allow unauthorized individuals to gain access to full patient records, including personally identifiable information (PII) and protected health information (PHI), indicating security issues are systemic.

mHealth apps have proven to be invaluable during the COVID-19 pandemic and are now increasingly relied on by hospitals and healthcare providers. According to Pew Research, mHealth apps are now generating more user activity than other mobile device apps such as online banking. There are currently an estimated 318,000 mHealth apps available for download from the major app stores.

The 30 mHealth apps analyzed for the study are used by an estimated 23 million people, with each app downloaded an average of 772,619 times from app stores. These apps contain a wealth of sensitive data, from vital signs data to pathology reports, test results, X-rays and other medical images and, in some cases, full medical records. The types of information stored in or accessible through the apps carries a high value on darknet marketplaces and is frequently targeted by cybercriminals. The vulnerabilities identified in mHealth apps makes it easy for cybercriminals to gain access to the information.

“Look, let’s point the pink elephant out in the room. There will always be vulnerabilities in code so long as humans are writing it. Humans are fallible,” said Knight. “But I didn’t expect to find every app I tested to have hard-coded keys and tokens and all of the APIs to be vulnerable to broken object level authorization (BOLA) vulnerabilities allowing me to access patient reports, X-rays, pathology reports, and full PHI records in their database.”

BOLA vulnerabilities allow a threat actor to substitute the ID of a resource with the ID of another. “When the object ID can be directly called in the URI, it opens the endpoint up to ID enumeration that allows an adversary the ability to read objects that don’t belong to them,” explained Knight. “These exposed references to internal implementation objects can point to anything, whether it’s a file, directory, database record or key.” In the case of mHealth apps, that could provide a threat actor with the ability to download entire medical records and personal information that could be used for identity theft.

APIs define how apps can communicate with other apps and systems and are used for sharing information. Out of the 30 mHealth apps tested, 77% had hard-coded API keys which made them vulnerable to attacks that would allow the attacker to intercept information as it is exchanged. In some cases, those keys never expired and 7% of the API keys belonged to third-party payment processors that strongly advise against hard coding these private keys in plain text, yet usernames and passwords had still been hard coded.

All of the apps lacked certificate pinning, which is used to prevent man-in-the-middle attacks. Exploiting this flaw would allow sensitive health and personal information to be intercepted and manipulated. Half of the tested apps did not authenticate requests with tokens, and 27% did not have code obfuscation protections, which made them vulnerable to reverse engineering.

Knight was able to access highly sensitive information during the study. 50% of records included names, addresses, dates of birth, Social Security numbers, allergies, medications, and other sensitive health data. Knight also found that if access is gained to one patient’s records, other patient records can also be accessed indiscriminately.  Half of all APIs allowed medical professionals to view pathology, X-ray, and clinical results of other patients and all API endpoints were found to be vulnerable to BOLA attacks, which allowed Knight to view the PHI and PII of patients not assigned to her clinical account. Knight also found replay vulnerabilities that allowed her to replay FaceID unlock requests that were days old and take other users’ sessions.

Part of the problem is mHealth apps do not have security measures baked in. Rather than build security into the apps at the design stage, the apps are developed, and security measures are applied afterwards. That can easily result in vulnerabilities not being fully addressed.

“The fact is that leading developers and their corporate and organizational customers consistently fail to recognize that APIs servicing remote clients such as mobile apps need a new and dedicated security paradigm,” said David Stewart, founder and CEO of Approov. “Because so few organizations deploy protections for APIs that ensure only genuine mobile app instances can connect to backend servers, these APIs are an open door for threat actors and present a real nightmare for vulnerable organizations and their patients.”

Author: Steve Alder has many years of experience as a journalist, and comes from a background in market research. He is a specialist on legal and regulatory affairs, and has several years of experience writing about HIPAA. Steve holds a B.Sc. from the University of Liverpool.

Share This Post On