mHealth Apps Expose Millions to Cyberattacks

Researcher testing of 30 mobile health apps for clinicians found that all of them had vulnerable APIs.

Some 23 million mobile health (mHealth) application users are exposed to application programming interface (API) attacks that could expose sensitive information, according to researchers.

Generally speaking, APIs are an intermediary between applications that defines how they can talk to one another and 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 wouldn’t ID the vulnerable ones. Turns out, they were all vulnerable to one degree or another.

The average number of downloads for each app tested was 772,619.

According to the resulting report from Approov, out of 30 popular mHealth apps analyzed, 77 percent of them contained hardcoded API keys, which would allow an attacker to intercept that exchange of information — some of which don’t expire. Seven percent of these belonged to third-party payment processors that explicitly warn against hard-coding their secret keys in plain text.

Another 7 percent contained hardcoded usernames and passwords.

 

But that’s not all: More than a quarter (27 percent) of mobile apps tested didn’t have code-obfuscation protections against reverse engineering; and all of them without exception lacked certificate pinning, which prevents man (or woman) in the middle (MITM) attacks, for intercepting communications to observe and manipulate records.

Also, a full 50 percent of the APIs tested did not authenticate requests with tokens.

And finally, if one patient’s records can be accessed, often many others can be accessed indiscriminately: 100 percent of API endpoints tested were vulnerable to Broken Object Level Authorization (BOLA) attacks, which allowed the researcher to view the personal health information (PHI) and personally identifiable information (PII) for patients that were not assigned to the researcher’s clinician account.

For context, the report said there are more than 318,000 apps available in major app stores.

Medical Records Attract Cybercriminals

The pandemic has pushed hospitals and healthcare providers to rely increasingly on mHealth apps. But the analysis reveals they’re are often vulnerable to attackers, leaving critical and valuable health information sitting there just waiting to get ripped off.

What’s been exacerbating the security posture of mobile health apps is the mad rush to innovate first, secure second, Knight explained to Threatpost. And now is the time for security to catch up before a big breach happens, she added.

Threat actors meanwhile have a big financial incentive to target these mHealth APIs. Knight pointed out that while the going rate among cybercriminals for a Social Security number is $1 and a credit-card number sells for about $110, the big money is in full medical records, which fetch about $1,000 apiece.

“This growing attack surface is quickly drawing the attention of transnational crime syndicates wanting to lock-and-leak it in order to extort payments from its data owners and sell it to the highest bidder,” Knight wrote in the report.

What is the Top mHealth App Threat?

“Simply put, a BOLA vulnerability enables an adversary to substitute the ID of a resource with the ID of another,” Knight explained. “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 percent 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 and more.

API Authorization Versus Authentication

Knight explained to Threatpost that when it comes to APIs, CISOs and security teams need to think about the distinction between authentication and authorization.

Knight used the analogy of security at a nightclub.

In an authorization-only scenario the bouncer (the authorizer) checks IDs and determines who is allowed inside the bar. So that inside, anyone who walks up the bar and orders a drink, the bartender can just assume, is legal to consume alcohol.

But in an authentication scenario there are two checks.

The bouncer checks IDs and 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 isn’t just authorized to be in the bar, but it also ensures their identity is authenticated to make sure they’re both allowed inside and allowed to consume alcohol.

APIs work much the same way, Knight explained. Half of the mHealth APIs she tested for this report didn’t authenticate requests with tokens.

“Types of authentication in APIs include API keys, a long string of random numbers and characters generated by the API endpoint that grants access to whomever passes it in the authorization header of the request; Basic Auth where a username and password are used to authenticate an individual; JSON Web Tokens (JWTs) and OAuth, which uses tokens instead of sharing credentials; OAuth2, which exchanges a username and password for a token; SMART, which is increasingly becoming an implementation of OAuth in healthcare; and OpenID Connect,” Knight said. “There are also other methods of authentication, such as implementing multifactor authentication through third-party solutions.”

Implementing Better mHealth Cybersecurity

David Stewart, founder and CEO of Approov, explained that existing security standards aren’t 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 said. “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. ”

Heathcare entities must understand that APIs are an open door for malicious actors, particularly in the lucrative PHI market, he underlined.

“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,” Stewart said.

Save your spot for “15 Cybersecurity Gaffes SMBs Make“:

Join us for a  FREE Threatpost webinar on Feb. 24 at 2 p.m. ET. Cybercriminals count on you making these mistakes, but our experts will help you lock down your small- to mid-sized business like it was a Fortune 100. Register NOW for this LIVE webinar on Wed., Feb. 24.

Suggested articles

vmware

VMWare Patches Critical RCE Flaw in vCenter Server

The vulnerability, one of three patched by the company this week, could allow threat actors to breach the external perimeter of a data center or leverage backdoors already installed to take over a system.

Discussion

  • Pete Nicholls on

    > “Types of authentication in APIs include API keys, a long string of random numbers and characters generated by the API endpoint that grants access to whomever passes it in the authorization header of the request; Basic Auth where a username and password are used to authenticate an individual; JSON Web Tokens (JWTs) and OAuth, which uses tokens instead of sharing credentials; OAuth2, which exchanges a username and password for a token; SMART, which is increasingly becoming an implementation of OAuth in healthcare; and OpenID Connect,” Knight said. “There are also other methods of authentication, such as implementing multifactor authentication through third-party solutions.” This comment gives a somewhat confusing view of web authorisation. Some clarifications: * JWTs are part of OpenID Connect (OIDC), and OIDC operates on top of OAuth 2. * Although common, API keys aren't exclusively sent in an authorization header * SMART is a collection of standards for healthcare and promotes the use of OAuth 2 and OIDC * Multi-factor authentication can be implemented by first-party solutions as well

Leave A Comment

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.