Mobile Healthcare Apps are Leaking Sensitive Patient Data
- By Jeff Stuart
- Feb 09, 2021
A new study shows that popular mobile health applications are potentially compromising millions of patients, potentially exposing social security numbers, addresses, birthdates, allergies, medications and other sensitive data.
“All That We Let In” a new study from Approov and cybersecurity researcher Alissa Knight, revealed API vulnerabilities in the 30 popular mobile health apps tested, impacting an estimated 23 million mHealth users. However, with more than 318,000 mHealth apps now available on major app stores, researchers expect that the number of patients impacted is likely far greater.
Among vulnerabilities discovered:
- 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 users (medical professionals) to access the pathology, x-rays, and clinical results of other patients.
- 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 person-in-the-middle attacks against the app to observe and manipulate records.
- Of the 30 popular apps tested, 77 percent contained hardcoded API keys, some which don’t expire, and 7 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.
“There will always be vulnerabilities in code so long as humans are writing it. 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,” said researcher Alissa Knight.
“These findings are disappointing but not at all surprising,” said David Stewart, CEO of Approov. “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.”
Among recommendations offered:
- 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.
“While it is a best practice for a mainstream application’s code to move through a thorough secure code review during development, organizations are often haphazard on following the same secure systems development lifecycle (SSDLC) process while developing mobile applications,” said Tom Garrubba, rick management expert at Shared Assessments. “By not applying the same rigorous process, any defective code will lead to vulnerabilities that can be exploited by even the most novice of hackers.”