An examination of 30 popular mobile health apps revealed that fully 100 percent of them are vulnerable to application programming interface (API) cyberattacks that can allow unauthorized access to full patient records, including protected health information (PHI) and personally identifiable information (PII).
The study, conducted by API cybersecurity company Approov and cybersecurity content company Knight Ink, underscores the API shielding actions now urgently required to protect mHealth apps from API abuse, the organizations’ leader assert.
The Knight Ink vulnerability research study, “All That We Let In,” 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. The study’s leaders also pointed out that observers with Pew Research have noted that mHealth apps are now generating more user activities than other mobile device apps such as online banking and job searching. Experts in this space also have noted that patient IDs and PHI are more lucrative in dark web markets than credit card data.
The study tested 30 popular mHealth apps, though the report didn’t disclose the specific names of the apps that were tested. However, the average number of downloads for each app tested was 772,619, and Knight Ink estimates 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.
Among the report’s key findings, these basic vulnerabilities open the door for hackers:
- Of the 30 popular apps Knight Ink 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.
- 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.
And if a record is exposed, there often won’t be privacy: 50 percent of the records accessed contained names, social security numbers, addresses, birthdates, allergies, medications, and other sensitive data for patients.
Additionally, 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 (see study findings - Exhibits N, O and P of the study findings).
- A replay vulnerability allowed the researcher to replay days-old FaceID unlock requests that allowed her to take over other users’ sessions.
What’s more, 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
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.”
Importantly, the report states, “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.”
