API VULNERABILITIES IN HEALTHCARE

Application programming interfaces (API) are being used by more healthcare organizations every year. The APIs help healthcare organizations to coordinate care for patients in a way they’ve never experienced. Interoperability is at an API’s core and it’s able to retrieve or send data that update’s a patient’s medical information into a system. The API makes things much faster and easier for healthcare organizations to send or store valuable patient data.

However, with the implementation of innovative technology, comes security risks. Yes, APIs seems like the ultimate solution to the healthcare industry’s interoperability issues, but there are still challenges when working with them. Because most healthcare organizations don’t manage their own APIs, it leaves the door open for devastating cyber attacks.

Cybercriminals know that the healthcare industry is not as prudent about securing their cyber environments as other industries and they will take every opportunity they can to infiltrate their systems and networks. Every day, threat actors are realizing how lucrative it can be to target APIs. The failure of traditional security measures is the prime reason why APIs are a favored attack vector for threat actors. Let’s take a look at what APIs are, API attacks/vulnerabilities, and how healthcare organizations can stay safe when using one.

 

TIR snapshot-Aug-02-2022-03-14-49-03-PM

Related reading: What Software Companies looking to develop for the Healthcare Industry need to know

 

 

What is an api?

In May 2022, Avertium published a Threat Intelligence Report regarding API attacks and best practices. An API is a software that allows two applications to communicate with each other. If you’ve checked the weather on your mobile phone, used a social media app, or sent an instant message, then you’ve used an API.

Healthcare organizations use APIs to help close the gap in how information is sent, retrieved, and processed. For example, it can be cumbersome to have to wait for every patient to get to a medical office to fill out forms, but APIs make the process simple, easy, and efficient for both the healthcare provider and the patient. Healthcare providers are now able to put a patient’s information into a system that works with insurance companies and that system can determine if the patient is covered for a particular medication or medical procedure.

 

How Does an API Work?

When you use an app on your mobile phone, the app connects to the internet – sending data to a server. After the data is sent, the server retrieves the data and interprets it before sending it back to your phone. Once the application interprets the data, it then presents you with the information you wanted in a readable way.

Although it may appear as such, your phone’s data is not completely exposed to the server and the server is never completely exposed to your phone. Both your phone and the server communicate with small packets of data, and they only share what’s necessary.

In the past, APIs were described in generic terms as a connectivity interface to an application. However, today’s APIs are more complex and have characteristics that make them far more valuable than in previous years. Today’s APIs adhere to HTTP and REST standards and are developer friendly. They are also designed for consumption by particular audiences and are documented for consumption and versioning.

 

 

how was patient data handled prior to APIs?

Prior to APIs, interoperability was quite tedious and daunting. Most healthcare organizations were sending, retrieving, and processing patient data through calls and fax machines. A healthcare clinic would call a local hospital to schedule surgeries or fax a patient’s chart over before scheduling a pre-surgical screening for their patient.

On the day of the patient’s surgery, a physical copy of the patient’s chart was given to the operating physician with the patient’s pre-surgical test results and their physical examination history. This would all have to be done weeks or days leading up to the surgery.

The process was quite tedious with a lot of moving parts, which means that APIs are much needed within the healthcare sector. APIs have the chance to revolutionize interoperability efforts within healthcare and to comply with the CMS Interoperability and Patient Access final rule, healthcare organizations are implementing APIs at a quick rate.

 

 

API vulnerabilities

As we stated above, with innovative technology comes security risks. Imperva recently released a report analyzing API-related incident data and quantified the cost of API security. The organization found that the lack of security APIs may cause is $12 billion to $23 billion in average annual API-related cyber loss in the U.S. Globally, the average annual API-related cyber loss is between $41 billion and $75 billion.

According to Imperva’s report, the estimated losses are entirely avoidable. If organizations invested in properly securing APIs, their losses would decrease even if they continued to adopt APIs into their daily operational processes. The report also discovered that the healthcare sector is one of the largest adopters of APIs across all sectors. In 2020, healthcare API traffic grew by more than 400%. By 2021, health monitoring API use increased by 941%. Additionally, the report stated that there is an increase in account scraping, account takeovers, and malicious traffic surrounding API use.

According to the Daily Dot, in July 2022, a mental health app called Feelyou exposed over 80,000 of its users' email addresses. Up until the company issued a patch, anyone could obtain the personal email addresses of users and link them to anonymous posts by accessing the app’s GraphQL API, which didn’t require authentication. The security issue had been present since January 2022.

Because there are so many APIs currently available, attackers are seeing APIs as a new attack vector of opportunity. Threat actors are gathering the tools they need to exploit every vulnerability they can find in APIs. Also, organizations are not treating APIs in the proper way, instead, they are treating them as if they are standard web applications. Healthcare organizations aren’t doing enough to ensure that they’re being used safely.

Interestingly, the same attacks that stopped working on websites years ago, still work on APIs. If APIs are not secured properly, healthcare organizations run the risk of patient data exposure and cyber attacks. Cyber security content creator Alissa Knight conducted research on API vulnerability and the mHealth app. As a result of her research, she was able to access more than 4 million patient and clinician records with a single patient login account.

Knight tested three APIs, that serve a network of over 48 mobile apps and APIs. All of the APIs allowed her to gain access to health data from other patients by using one login. Fifty-three percent of the mobile apps Knight tested had hardcoded API keys and tokens that could enable attackers to infiltrate the APIs.

The most disturbing part of Knight’s research was that she didn’t use complicated hacking techniques. Her techniques have been described as “kindergarten cybersecurity”.

 

“There were no vulnerabilities found in the EHR companies themselves,” said Knight, discussing the report during the same YouTube Livestream. “These issues were found because of a lack of harmony and secure co-development with the integrators and the app developers. That is an important distinction here.” – Alissa Knight (FierceHealthcare.com)

 

 

api risks & Healthcare

There are many risks healthcare organizations face when dealing with APIs – one of them being Broken Object Level Authorization (BOLA). In Alissa Knight’s published report, she explained that BOLA is the most prevalent API vulnerability today. During Knight’s research, she found that in every API she tested and exploited, BOLA was leveraged to access data that she should not have been able to read, write, put, or delete.

 

In fact, many of the vulnerabilities Knight found, were BOLA vulnerabilities. BOLA is described as an insecure direct object reference or IDOR. IDOR means that a user is able to directly access resources they shouldn’t be able to access by way of user input functionality.

User input functionality can be carried out in various ways, including changing an ID somewhere the user can input information (i.e., cookies, URL, etc.). Because the API doesn’t check whether a user owns a resource before the user can do anything (modifying or deleting the resource), the API becomes vulnerable after the ID parameter has changed. This means that an attacker could gain access to a health care organization’s patient data, which then can be used for further attacks like targeted phishing attacks, complete account takeover, or social engineering.

APIs use an ID in the request, taking the form of UserIDs, UUID, cookies, URLs, and other forms. Evidence of a BOLA exists when changing the ID in the request allows users to gain access to information that they didn’t have prior access to. There is a way to prevent this from happening, but healthcare organizations need to implement API best practices to get a handle on the issue.

Another issue that makes APIs a risk to healthcare organizations is the fact that APIs are often managed by third parties or middlemen, and not the healthcare facility using the API.

Unfortunately, third-party APIs don’t always practice API best practices because they don’t need to adhere to HIPPA regulations – making patient data easily accessible for attackers.

Yes, using third-party APIs saves healthcare organizations time, but there are consequences.

Cybercriminals research business systems and try to identify weak tools and packages on targeted servers. These weaknesses open up many options for threat actors, depending on how well the third-party’s API was designed for security. The common vulnerabilities exposed by APIs that threat actors find include cross-site request forgery, denial of service, man-in-the-middle attacks, replay and spoofing, and unencrypted transport of data.

According to a Trustwave Report, the biggest API security risk is cross-site scripting (XSS) – an attack that’s used in 40% of all attacks reviewed in the report for 2018. SQL Injection (SQLi) and Path Traversal attacks were also used often and are used to steal data and credentials.

Related reading: How to Raise Your Organization’s Game to Combat Cybercriminals

 

 

how healthcare organizations can stay safe

Unfortunately, existing security measures don’t work for APIs in general and those measures are not stopping threat actors from stealing sensitive data and causing damage to an organization’s API. A lot of times, organizations will implement API gateways, API management tools, firewalls, and IAM tools to prevent API attacks. However, the truth is that those tools were not designed to prevent API attacks, and securing APIs comes with its own set of challenges. Those challenges include:

  • The API landscape is constantly changing and it's nearly impossible to keep up with changed or new APIs. Documentation is of little use since it's almost always out of date or incomplete.

  • While other kinds of attacks such as SQL injection attacks are quick and follow the protocols for leveraging known vulnerabilities, API attacks do not. The attacks are slow and because every API is unique, so are the attacks. Threat actors often probe the APIs for business logic gaps they can exploit.

  • Finally, although pre-production testing is able to find gaps in API security best practices, they don’t uncover vulnerabilities within API business logic gaps – developers don’t write fully secure code all the time.

Related reading: Reducing Ransomware Risk in Healthcare

 

What Works?

Fortunately, API attacks are preventable. To help keep your organization safe, implement the following:

  • Vet third-party APIs – It can be a challenge to properly vet a third-party API but it’s necessary. Constantly monitor APIs for updates that can impact your organization’s security. Because healthcare organizations have to manage massive amounts of simultaneous connections using different devices and browsers, it’s important for them to complete a bi-directional audit trail between the third-party API and the digital assets served by the APIs.

  • Penetration testing in systems – performing API penetration testing in systems with protected health information twice per year could save healthcare organizations from becoming victims of an API attack. Generalized penetration testing can miss attack vectors.

  • Maintain inventory – all healthcare organizations should know what’s connected to their APIs. It’s tedious but it can be done with the help of automated tools that can identify known, as well as unknown APIs. They can also provide insight and information about APIs that could be important to securing your environment.

  • Implement authentication and authorization - before a request is processed, an API performs authentication to verify the identity of a user or program that sent the request. APIs authenticate via a password, authentication token, or multi-factor authentication. The OAuth protocol is the accepted standard for API user authentication. Authorization is implemented after verifying the identity of the user sending the request.

  • REST APIs especially must authenticate and authorize each request made to the server - even if several requests come from the same user. You can govern authorization by user roles, giving each role different permissions. Adhere to the principle of least privilege and only grant users access to resources necessary for their role.

  • You must log API activity - if an attacker breaches the above protections, you’ll be able to see how they did it. You’ll also be able to use the attack to harden your API and prevent attacks from happening in the future.

 

 

How Avertium is Protecting Our CUSTOMERS   

Maintaining a robust security architecture can and implementing API best practices can help keep your healthcare free from threat actors seeking financial gain. Avertium offers services that prevent API cyber incidents and keep patient data secure:

  • To identify the source of your breach and the scope that it reached; you’ll want to include Avertium’s DFIR services in your protection plan. We offer DFIR (Digital Forensics and Incident Response) to mitigate damage from a successful breach.

  • Avertium offers VMaaS to provide a deeper understanding and control over organizational information security risks. If your enterprise is facing challenges with the scope, resources, or skills required to implement a vulnerability management program with your team, outsourced solutions can help you bridge the gap.

  • Avertium offers Zero Trust Network as a Service (ZTNaaS) for any organization that wants to control their attack surface. The zero-trust security model delivers exactly what the name promises: it's an IT security concept that specifies no access is allowed until the successful completion of authentication and authorization processes.

  • Avertium has virtual CISOs who can provide a high level of service by helping you develop a plan to conduct a physical hardware inventory assessment. This service includes a visibility study to help discover what devices are on your network. This can be done remotely or in person.

 

 

Avertium’s Recommendations  

  • Require multifactor authentication to protect employees’ accounts from being used by attackers to obtain account credentials and use them to escalate privileges and move laterally within the network.

  • Perform daily backups and keep them offline to avoid losing data.

  • Disrupt network movements/investigation by way of creating separated segments of network, clear access hierarchy, and additional security for active directory, domain admin, and local domains – thus complicating LockBit 3.0’s operations.

  • Relying on outdated tools and point solutions will compromise your network or system. Better technology exists to detect complex attacks like LockBit 3.0 ransomware.

  • Use anti-ransomware technology as a prevention method. Deploy prevention that works like next-generation antivirus and explicit anti-ransomware technology.

  • Reduce the target by including these technical practices: close vulnerabilities, augment security hygiene, create and enforce strong general policies, and sustain backup and recovery practices.

  • It’s likely that LockBit 3.0 monitors the latest CVEs. Monitor exposed endpoints and application of CVE-addressing patches.

 

MITRE Map

API Mitre Map

 

Supporting Documentation

What you need to know about healthcare APIs and interoperability | Healthcare IT News

API Attacks & Best Practices (avertium.com)

What is an API? (redhat.com)

As API Adoption in Healthcare Skyrockets, Cybersecurity Risks Follow (healthitsecurity.com)

Mental Health App Had Data On Tens Of Thousands Of Users Exposed (dailydot.com)

The Biggest Security Risks of Using 3rd Party APIs - Ipswitch

Security flaws in health apps, APIs potentially put millions of patient records at risk, report finds | Fierce Healthcare

All That We Let In: Hacking Mobile Health APIs (Part 1) | by Alissa Knight | Medium

Broken Object Level Authorization - Traceable API SecurityAs API Adoption in Healthcare Skyrockets, Cybersecurity Risks 

Importance of API Security in Healthcare Grows as Cyberattacks Increase (healthitsecurity.com)

All That We Let In: Hacking mHealth Apps and APIs (Part 2) | by Alissa Knight | Medium

Broken Object Level Authorization - Traceable API Security

 

 

APPENDIX II: Disclaimer

This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.

Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.

COPYRIGHT: Copyright © Avertium, LLC and/or Avertium Tennessee, Inc. | All rights reserved.

 

Related Resource:  API Attacks and Best Practices