mHealth apps consistently expose PII and PHI through APIs

All of the 30 popular mHealth apps that were tested are vulnerable to API attacks that can allow unauthorized access to full patient records including protected health information (PHI) and personally identifiable information (PII), Approov reveals.

The study underscores the API shielding actions now urgently required to protect mHealth apps from API abuse.

The Knight Ink vulnerability research study details findings, and also notes that the results are particularly worrisome given the increased reliance on mHealth apps during the global pandemic, which in turn is drawing threat actors to mHealth apps as an attack surface of choice.

“Observers with Pew Research noted that mHealth apps are now generating more user activities than other mobile device apps such as online banking and job searching. Observers also note that patient IDs and PHI are more lucrative in dark web markets than credit card data.

Alissa Knight, researcher and author of the report said, “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.

“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. The problem is clearly systemic.”

The study tested 30 popular mHealth apps. The average number of downloads for each app tested was 772,619, and it’s estimated that the 30 apps evaluated expose some 23 million mHealth users, at a minimum. Analysts expect that the total number of users exposed by the 318,000 mHealth apps now available on major app stores is likely far greater.

Basic vulnerabilities open the door for hackers

• Of the 30 popular apps tested, 77 percent contained hardcoded API keys, some which don’t expire, and seven percent contained hardcoded usernames and passwords. Seven percent of the API keys belonged to third-party payment processors that warn against hard-coding their secret keys in plain text.
• 50 percent of the APIs tested did not authenticate requests with tokens.
• API keys and tokens were discovered for Google, Branch.io, Braze, Tune, Optimizely, Cisco Umbrella, Microsoft App Center, Bugsnag, Contentful, Stripe, Amazon AWS, Radaee, Sendbird, AppsFlyer, Facebook, Vonage, SalesForce and Mparticle.

If a record is exposed, don’t expect privacy

50 percent of the records accessed contained names, social security numbers, addresses, birthdates, allergies, medications, and other sensitive data for patients.

If one patient’s records can be accessed, often many others can be accessed indiscriminately:

• 100 percent of API endpoints tested were vulnerable to BOLA attacks that allowed the researcher to view the PII and PHI for patients that were not assigned to the researcher’s clinician account.
• 50 percent of the APIs tested allowed medical professionals to access the pathology, X-rays, and clinical results of other patients.
• A replay vulnerability allowed the researcher to replay days-old FaceID unlock requests that allowed her to take over other users’ sessions.

Even if the app and records are well protected, communication between them is easily breached:

• 100 percent of the apps tested failed to implement certificate pinning, enabling the researcher to perform woman-in-the-middle attacks against the app to observe and manipulate records.

The findings demonstrate that the security standards required for compliance with U.S. government FHIR/SMART standards merely represent a subset of the steps needed to secure mobile apps and the APIs which enable apps to retrieve data and interoperate with data resources and other applications.

Approov CEO David Stewart said, “These findings are disappointing but not at all surprising. 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.

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.”

Key steps to protect customer data and sensitive resources

The report recommends that mHealth platform developers – and all developers and organizations using mobile applications – adopt several key steps to protect their customer data and sensitive resources, including:

• Address both app security and API security: recognize that synthetic traffic to the API is an issue and arises from bots and automated tools, not from genuine apps and legitimate data requests.
• Shift left and shield right: secure the development process and harden apps, but ensure that run-time protection is also in place.
• Protect against X-in the middle attacks: certificate pinning is critical but often left undone because expired certificates can block apps and impact the customer’s experience. However, when done correctly, certificate pinning does not impact either performance or availability.
• Improve visibility into controls: organizations and developers need to monitor the effectiveness of the controls they implement and adjust them easily – both for compliance with HIPAA mandates and to sustain data security and privacy.
• Penetration testing and static and dynamic code analysis should be performed regularly.