A researcher testing of 30 mobile health apps for clinicians found that all of them had vulnerable APIs.
23m mobile health (mHealth) application users are exposed to application programming interface (API) attacks, that could expose sensitive information, according to researchers.
APIs are an intermediary between applications that defines how they can talk to one another & allowing them to swap information. Researcher Alissa Knight with Approov tried to break into the APIs of 30 different mHealth app vendors, with the agreement she would not ID the vulnerable ones. They were all vulnerable to 1 degree or other.
Hardcoded API Keys
The average number of downloads for each app tested was 772,619.
Says the resulting report from Approov, out of 30 popular mHealth apps analysed, 77% of them contained hardcoded API keys, which would allow an attacker to intercept that exchange of information — some of which don’t expire. 7% of these belonged to 3rd-party payment processors that explicitly warn against hard-coding their secret keys in plain text.
Another 7% contained hard-coded usernames & passwords.
Also, over a quarter (27%) of mobile apps tested didn’t have code-obfuscation protections against reverse engineering; & all of them without exception lacked certificate pinning, which prevents ‘Man (or Woman) in the Middle’ (MITM) attacks, for intercepting communications to observe & manipulate records.
Tokens
Also, a full 50% of the APIs tested did not authenticate requests with tokens.
Finally, if 1 patient’s records can be accessed, often many others can be accessed indiscriminately: 100% of API endpoints tested were vulnerable to Broken Object Level Authorisation (BOLA) attacks, which allowed the researcher to view the personal health information (PHI) & personally identifiable information (PII) for patients that were not assigned to the researcher’s clinician account.
For context, the report states there are more than 318,000 apps available in major app stores.
Medical Records & Cyber-Criminals
The pandemic has pushed hospitals & healthcare providers to rely increasingly on mHealth apps. But the analysis reveals they are often vulnerable to attackers, leaving critical & valuable health information sitting there just waiting to get ripped off.
What has been worsening the security strategy of mobile health apps is the rush to innovate 1st, secure 2nd, Knight explained. Now is the time for security to catch up before a big breach occurs, she added.
Threat players meanwhile have a big financial incentive to target these mHealth APIs. Knight explained that while the going rate among cyber-criminals for a Social Security number is $1 & a credit-card number sells for about $110, the big money is in full medical records, which fetch about $1,000 each.
“This growing attack surface is quickly drawing the attention of transnational crime syndicates wanting to lock-&-leak it in order to extort payments from its data owners & sell it to the highest bidder,” Knight wrote in the report.
Top mHealth App Threat?
BOLA (a.k.a. Insecure Direct Object Reference, or IDOR) is the most common abuse vector for mHealth APIs, Knight observed, pointing out it’s no coincidence that OWASP’s recently published list of top API threats put these types of vulnerabilities at the top.
“Simply put, a BOLA vulnerability enables an adversary to substitute the ID of a resource with the ID of another,” Knight explained.
BOLA Attacks
“When the object ID can be directly called in the URI, it opens the endpoint up to ID enumeration that allows an adversary the ability to read objects that don’t belong to them. These exposed references to internal implementation objects can point to anything, whether it’s a file, directory, database record or key.”
In-the-lab BOLA attacks conducted by Knight cracked 100% of the apps she tested, giving her theoretical access to downloadable full patient records, including lab results, x-ray images, blood work, family history, birth dates, Social Security numbers & more.
API Authorisation v. Authentication
Knight explained that when it comes to APIs, CISOs & security teams need to think about the distinction between authentication & authorisation.
Knight used the analogy of security at a nightclub.
In an authorisation-only scenario the bouncer (the authoriser) checks IDs & determines who is allowed inside the bar. So that inside, anyone who walks up the bar & orders a drink, the bartender can just assume, is legal to consume alcohol.
However, in an authentication situation there are 2 checks.
Added Layer of Scrutiny
The bouncer checks IDs & issues wrist bands to those allowed to drink. Once at the bar, the bartender (the authenticator) looks for a wristband as an added layer of scrutiny. The bartender double-check confirms the person is not just authorised to be in the bar, but it also ensures their identity is authenticated to make sure they are both allowed inside & allowed to consume alcohol.
APIs work much the same way, Knight explained. Half of the mHealth APIs she tested for this report did not authenticate requests with tokens.
Random Numbers
“Types of authentication in APIs include API keys, a long string of random numbers & characters generated by the API end-point that grants access to whomever passes it in the authorisation header of the request; Basic Auth where a username & password are used to authenticate an individual; JSON Web Tokens (JWTs) & OAuth, which uses tokens instead of sharing credentials“
“OAuth2, which exchanges a username & password for a token; SMART, which is increasingly becoming an implementation of OAuth in healthcare; & OpenID Connect,” Knight commented.
“There are also other methods of authentication, such as implementing multifactor authentication through 3rd-party solutions.”
Better mHealth Cyber-Security
David Stewart, Founder & CEO of Approov, explained that existing security standards are not adequate to address rising security threats to mobile health applications. Companies need to do more.
“These findings are disappointing but not at all surprising,” Stewart observed. “The fact is that leading developers & their corporate & organisational customers consistently fail to recognise that APIs servicing remote clients such as mobile apps need a new & dedicated security paradigm. ”
Open Door
Healthcare authorities must understand that APIs are an open door for malicious players, particularly in the lucrative PHI market, he underlined.
“Because so few organisations deploy protections for APIs that ensure only genuine mobile app instances can connect to backend servers, these APIs are an open door for threat players & present a real nightmare for vulnerable organisations & their patients,” Stewart concluded.
https://www.cybernewsgroup.co.uk/virtual-conference-march-2021/
