100% of Analyzed mHealth Apps Vulnerable to API Attacks

The personally identifiable health information of hundreds of thousands of people is being exposed via the Application Programming Interfaces (APIs) utilized by mobile health (mHealth) applications, as per the latest study released by cybersecurity company Approov.

Ethical hacker and researcher Allissa Knight performed the study to find out how safe well-known mHealth apps are and whether it’s possible to get access to users’ sensitive health information. One of the provisos of the study was she won’t be permitted to identify any of the applications in case vulnerabilities were discovered. She evaluated 30 of the top mHealth apps and found all were prone to API attacks which can permit unauthorized persons to acquire access to the whole patient data, including personally identifiable information (PII) and protected health information (PHI), showing that security problems are systemic.

mHealth apps had been very helpful throughout the COVID-19 pandemic and are now more and more used by hospitals and healthcare firms. As per Pew Research, mHealth apps are now generating much more user activity compared to other mobile device applications like online banking. There are presently an approximated 318,000 mHealth apps available for download from the big app stores.

The 30 mHealth applications analyzed for the research are employed by around 23 million individuals, with each and every app downloaded about 772,619 times from app stores. These applications consist of a wealth of sensitive information, from vital signs records to pathology reports, test results, X-rays and other medical images and, in certain cases, full medical files. The types of information saved in or accessible by means of the apps hold a high price on darknet marketplaces and are often targeted by cybercriminals. The vulnerabilities determined in mHealth apps make it effortless for cybercriminals to obtain access to the data.

There will generally be vulnerabilities in the code. But it’s surprising to find that every app reviewed had hard-coded keys and tokens. All APIs had broken object level authorization (BOLA) vulnerabilities that allow access to patient reports, pathology information, X-rays, and full PHI information in their database.

BOLA vulnerabilities make it possible for a threat actor to replace the ID of a resource with another ID. If the object ID can be directly called in the URI, it opens the endpoint up to ID enumeration that permits an enemy the capability to read stuff that doesn’t belong to them. Exposed references to internal implementation objects could point to nearly anything — a file, directory, database record, or key. In the case of mHealth programs, that could give a threat actor the capacity to download complete medical information and personal data that may be utilized for identity theft.

APIs specify how applications can connect with other programs and systems and are employed for sharing information. Of the 30 mHealth applications examined, 77% contained hard-coded API keys which made them susceptible to attacks that would permit the attacker to intercept data as it is exchanged. In certain instances, those keys have no expiration and 7% of the API keys were used by third-party payment processors that disagree with hard coding the private keys using plain text. Still, the usernames and passwords were hardcoded.

All of the apps didn’t have certificate pinning that is required to avoid attacks. This flaw can be exploited and enable sensitive health and personal information to be intercepted and modified. Half of the tested apps didn’t authenticate requests using tokens, and 27% failed to have code obfuscation protections, which made them prone to reverse engineering.

Knight had the ability to access highly sensitive data throughout the study. 50% of records involved names, addresses, birth dates, Social Security numbers, allergies, prescribed medications, and more sensitive health information. Knight in addition discovered that when access is acquired to one patient’s files, other patient records could likewise be accessed randomly. 50 % of all APIs permitted medical specialists to look at pathology, X-ray, and clinical data of other patients and all API endpoints were identified to be susceptible to BOLA attacks, which granted Knight to see the PHI and PII of patients not included in her clinical account. Knight likewise discovered replay vulnerabilities that allowed her to playback FaceID unlock requests that were days old and take other users’ sessions.

One more issue is mHealth applications do not have security procedures baked in. Instead of build security into the apps at the design phase, the apps are created, and security measures are applied later. That can quickly bring about vulnerabilities not being completely addressed.

David Stewart, founder, and CEO of Approov stated the fact that top developers and their company and organizational customers continually fail to recognize that APIs servicing remote clients like mobile applications need a new and focused security paradigm. Since so few organizations use protections for APIs that make sure only authentic mobile app instances could link to backend servers, threat actors exploit these APIs and cause a real problem for vulnerable companies and their patients.