– The 30 most popular mHealth apps are highly vulnerable to API cyberattacks, which could enable unauthorized access to full patient records, such as protected health information and personally identifiable information, according to a report from Knight Ink and Approov.
Alissa Knight, a leading cybersecurity analyst and partner at Knight Ink, analyzed the leading apps over the course of six months to assess vulnerabilities. The companies behind these apps agreed to participate in the study, as long as the findings were not directly attributed to the vendor.
App use has dramatically increased amid the COVID-19 pandemic, with more than 60 percent of people downloading an mHealth app and about 318,000 mHealth apps available for download through major app stores. As such, attacks on these endpoints are also on the rise.
For the analyzed apps, the average number of downloads for each was 772,619. Knight sought to determine the risk APIs and vulnerabilities in mHealth apps pose to these mHealth companies and patient PHI.
The findings were both alarming and surprising.
The report estimates that about 23 million mHealth users have been exposed, at a minimum, through the 30 evaluated apps. Given the number of users leveraging the total 318,000 apps available for download, it’s likely the number of users with exposed data is much greater.
About 77 percent of the assessed apps contained hardcoded API keys, some of which will not expire. Another 7 percent contained usernames and passwords, with 7 percent of the API keys belonging to third-party payment processors that warn against hard-coding their secret keys in plain text.
Another 50 percent of the tested APIs did not authenticate requests with tokens, while 63 percent of the apps contained hardcoded private keys.
The researcher also found 114 hardcoded API keys and tokens, meant to be used for authenticating with the mHealth company and third-party APIs.
Further, the researcher found API keys and tokens for 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 100 percent of all tested API endpoints were vulnerable broken object level authorization (BOLA) attacks, which leads to unauthorized access to complete patient records, downloadable lab results and x-ray images, blood work, allergies, and PII, like contact details, family member data, and even Social Security numbers.
In fact, 50 percent of the records accessed contained names, social security numbers, addresses, birthdates, allergies, medications, and other sensitive data for patients.
“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,” Knight said in a statement.
“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 BOLA vulnerabilities allowing me to access patient reports, X-rays, pathology reports, and full PHI records in their database. The problem is clearly systemic,” she added.
The statistics only worsen throughout the report: 100 percent of the apps failed to implement certificate pinning, which allowed the researcher to perform X-in-the-middle attacks against the app.
As a result, the researcher was able to view PII and PHI for patients who weren’t assigned to the researcher’s clinician account.
What’s more, 27 percent of the apps were not secured against reverse engineering through code obfuscation.
The results for the tested APIs were equally concerning: 50 percent of the APIs allowed medical professionals to access the pathology, X-rays, and clinical results of other patients. The researcher also found a replay vulnerability, which allowed her to replay days-old FaceID unlock requests, enabling her to take over other users’ sessions.
The findings demonstrate shielding actions for APIs are urgently needed now to protect mHealth apps from API abuse. Further, security standards required to comply with US government FHIR/SMART standards are just not enough to secure mobile apps and the APIs.
“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,” Approov Founder and CEO David Stewart said in a statement.
“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,” he added.
As such, mHealth platform developers and all organizations using mobile applications must adopt key privacy and security measures to protect patient data and other sensitive resources.
The report made several key recommendations to accomplish this, including the need to address both app and API security. These entities must also secure the development process and harden apps and ensure run-time protection is also in place.
Certificate pinning is also critical to defending against X-in-the-middle attacks. When properly implemented, it will not impact availability or performance. Developers and entities also need to gain visibility into controls to ensure the effectiveness of implemented tools, which will allow them to be easily adjusted for compliance with HIPAA and to maintain privacy and security.
Lastly, the report stressed the need for pen testing, as well as regularly performed static and dynamic code analysis.
The report adds to previous data, which highlighted the massive privacy risks of third-party apps that don’t fall under HIPAA regulations. Multiple reports show both mHealth and mental health apps routinely share data without transparent policies about the practice.
Not only that, but the COVID-19 vaccine distribution has spurred a 51 percent increase in attacks on healthcare web apps.
Combined with the vulnerabilities outlined in this report, the need for Congress to take action on regulating these apps will be imperative in the coming year.
“mHealth apps – even before the pandemic – have had real problems with security,” Chloé Messdaghi, Chief Strategist, Point3 Security, said in a statement. “Unfortunately, many of these types of apps don’t have strong security – they don’t allow MFA, they only require short passwords, and of course, the API-related issues this researcher has underscored.”
“Another area of vulnerability is how the apps are put together. Are they using OS software? If so, are they checking for vulns in OS code? That’s a common problem, and it’s worth remembering that anything that’s free usually comes with a price,” she added.
— to healthitsecurity.com