100% of Screened mHealth Applications Prone to API Attacks
The personally identifiable health information of a huge number of people is being compromised by means of the Application Programming Interfaces (APIs) employed by mobile health (mHealth) apps, reported by a current study shared by cybersecurity agency Approov.
Ethical hacker and researcher Allissa Knight carried out the study to discover how protected famous mHealth apps are and if it’s possible to acquire access to users’ sensitive health information. One condition of the study was she wouldn’t be allowed to label any of the applications in case vulnerabilities were found. She examined 30 of the major mHealth apps and identified all were susceptible to API attacks which can permit unauthorized persons to get access to the complete patient data, which include protected health information (PHI) and personally identifiable information (PII), proving that security concerns are systemic.
mHealth apps had been indispensable for the duration of the COVID-19 pandemic and are now significantly depended on by hospitals and healthcare companies. Based on Pew Research, mHealth apps are currently generating a lot more user activity in comparison with other mobile device applications for example online banking. There are at present a calculated 318,000 mHealth apps that can be downloaded from the leading app stores.
The 30 mHealth applications reviewed for the research are utilized by around 23 million persons, with every app downloaded about 772,619 times from application stores. These applications have a wealth of sensitive facts, from vital signs records to pathology reports, test data, X-rays, and other medical photos and, in certain instances, complete medical information. The types of information kept in or accessible via the apps bear a high valuation on darknet marketplaces and are usually targeted by hackers. The vulnerabilities discovered in mHealth apps make it very easy for cybercriminals to get access to the material.
There will continually be vulnerabilities in the program code. However, it’s shocking to discover that every app reviewed had hard-coded keys and tokens and all APIs were susceptible to broken object level authorization (BOLA) vulnerabilities permitting access to patient records, X-rays, pathology information, and full PHI files in their storage system.
BOLA vulnerabilities make it possible for a threat actor to swap the ID of a resource with another ID. Whenever the object ID can be directly called in the URI, it frees the endpoint up to ID enumeration that enables an attacker the capability to read things that do not belong to them. Open references to internal implementation objects will be able to point to just about anything — a directory, file, database record, or key. In the instance of mHealth programs, that could present a threat actor with the capacity to download full medical information and personal data that may be employed for identity theft.
APIs determine how applications can converse with other programs and systems and are utilized for sharing information. Of the 30 mHealth applications examined, 77% got hard-coded API keys which made them prone to attacks that could permit the attacker to intercept data as it is interchanged. In a few circumstances, those keys do not expire and 7% of the API keys were owned by third-party payment processors that firmly advocate against hard coding the private keys using plain text, nevertheless, usernames and passwords were still hardcoded.
All of the apps were lacking certificate pinning, which is employed to avert man-in-the-middle attacks. Taking advantage of this vulnerability would enable sensitive health and personal information to be intercepted and altered. Half of the reviewed apps didn’t authenticate requests through tokens, and 27% failed to have code obfuscation protections that made them susceptible to reverse engineering.
Knight could access highly sensitive details at the time of the study. Half of the records contained names, addresses, dates of birth, Social Security numbers, allergies, prescription drugs, and additional sensitive health details. Knight likewise uncovered that when access is obtained to one patient’s information, other patient records may at the same time be accessed at random. 50 % of all APIs permitted medical experts to see pathology, X-ray, and clinical data of other patients and all API endpoints were observed to be prone to BOLA attacks, which granted Knight to look at the PHI and PII of patients not belonging to her clinical account. Knight additionally identified replay vulnerabilities that permitted her to play again FaceID unlock requests that were days old and use other users’ sessions.
Another difficulty is mHealth applications don’t have security options included. Instead of establishing security in the apps at the design period, the apps are made, and security measures are employed soon after. That can readily cause vulnerabilities not to be totally addressed.
The fact is that top-rated developers and their business and organizational clients constantly fail to identify that APIs servicing remote clients for instance mobile applications need a new and specialized security paradigm, mentioned by David Stewart, founder, and CEO of Approov. Considering that very few companies utilize protections for APIs that make certain only legitimate mobile app instances could be connected to backend servers, these APIs are an open channel for threat actors and bring about a real headache for vulnerable agencies and their patients.