The document discusses hacking healthcare APIs, focusing on research related to FHIR and SMART specifications, which standardize clinical data representation and secure data access. It covers the history of HL7 and FHIR, highlights testing phases and findings from the research, and outlines best practices for securing APIs against vulnerabilities. The author, Alissa Knight, shares insights from her extensive experience in hacking various applications and emphasizes the importance of robust authorization mechanisms.

1. 1
HACKING
HEALTHCARE
APIS
Alissa Knight
“Playing with FHIR”

2. Agenda
About me and this research
Definitions
SMART versus FHIR
HL7 and FHIR History
FHIR v4 Resources & RESTful API
SMART Authorization and Authentication
Our Test FHIR App
Testing Phases
Phase 1 Findings
Phase 2 Findings

3. About Me
• ak@knightinkmedia.com
• Recovering hacker of 21 years, recovering
entrepreneur, published author (Hacking
Connected Cars, Wiley; Hacking APIs,
Wiley)
• Started and sold two companies, VC
fund, now run M&A Knight Capital, M&A
Knight Entertainment, Knight Ink
• Cybersecurity filmmaker and content
creator
• API Hacks
• 2019: Hacked 30 financial apps and
APIs
• 2020: Hacked 30 mHealth apps and
APIs
• 2020: Hacked federal and state law
enforcement vehicles through APIs
• 2021: Hacking FHIR APIs
• 2021: Hacking Connected Trains

4. How this came to be..
Approov sponsored research into
hacking healthcare APIs
All research data is being published
at www.approov.io where you can
find Phase 1 report

5. SMART versus FHIR
FHIR provides a set of models to
standardize the representation of
clinical concepts such as allergies and
medications in an EHR or other clinical
data store.
SMART standardizes the process through
which a third-party application could plug
into a data store and access that clinical
information. It acts as a security layer that sits on
top of FHIR interfaces using OAuth2.0 and OpenID
Connect.
Simply put, FHIR standardizes
data, while SMART standardizes
and secures data access
Source: https://www.smilecdr.com/smart-on-fhir

6. HL7® and FHIR History
1960s
First known health IT system
deployed
1987
HL7 Version 1 arrives,
refinement of the protocol
developed initially at UCSF.
1989
HL7 v2 released for
enterprise-wide interoperability
2003
HL7 v3 created to support data
workflows between providers
2005
CDA released (Clinical
Document Architecture (CDA) is
a Health Level 7 (HL7) standard
that provides a framework for
the encoding, formatting and
semantics of electronic
documents.)
2014
HL7 FHIR launched, using web
interfaces (Apple, Boston
Children’s Hospital, others get
involved).
2016
21st Century Cures Act makes
APIs a requirement for certified
Health IT

7. HL7® and FHIR History
2014
Release of SMART on FHIR specification.
JASON task force recommends a public API for
healthcare.
Argonaut Project launched to implant SMART
in EHRs
2016
21st Century Cures Act makes APIs a
requirement for certified Health IT (HIT)
incorporating language from the SMART team
Cerner launches SMART on FHIR Developers
Sandbox
2017
Allscripts and EPIC launch SMART on FHIR
developers’ sandboxes

8. HL7® and FHIR History
2018
Apple adds SMART support to its
health app for patient access to
medical data
SMART on FHIR published as a
HL7 standard
2019
CMS commits to SMART bulk
data specs
Microsoft launches SMART on
FHIR API in its Azure product
Proposed rules from CMS and
ONC specify SMART as universal
apps API to implement the 21st
Century Cures Act
3 Cloud vendors at White House
commit to SMART on FHIR open
APIs
2020
Final rule on ONC specifies
SMART as universal apps API to
implement 21st Century Cures
Act

9. FHIR v4.01 Resources
& RESTful API

10. SMART Authorization & Authentication

12. 12
TESTING PHASES
STATIC CODE ANALYSIS
Non-FHIR APIs that transmit, process, and
store EHI
PHASE 1
TRAFFIC
ANALYSIS
Non-FHIR APIs that transmit, process, and
store EHI
2020

13. 13
TESTING PHASES
FUZZIN
G
Non-FHIR APIs that transmit, process, and
store EHI
STATIC CODE ANALYSIS
Testing of FHIR APIs with several of the
major EHI
PHASE 2
2021

14. 14
TRAFFIC
ANALYSIS
Testing of FHIR APIs with several of the
major EHI
PHASE 2
FUZZIN
G
Testing of FHIR APIs with several of the
major EHI
TESTING PHASES
2021

15. 15
Hacking Healthcare APIs: Phase 1
- Findings:
- API1:2019 Broken Object Level Authorization
- API2:2019 Broken User Authentication
- API3:2019 Excessive Data Exposure
- API6:2019 Mass Assignment

16. 16
PHASE 1

17. 17
Stealing Pathology Reports

18. 18
Hardcoded API Keys and Tokens

19. 19
Stealing Hospital
Admission Records

20. 20
Unlocking Locked Sessions

21. 21
PHASE 2: PLAYING
WITH FHIR

22. 22
HL7® FHIR: CERTIFIED

23. 23
HL7® FHIR: NON-CERTIFIED

24. 24
PROVIDER NOT ON FHIR

25. 25
ATTACK LAB
SETUP
Web APIs
• Burp Suite
• Proxy
• Repeater
Mobile APIs
• Mobile Security Framework
(MobSF)
• Mitmproxy + Postman
• Burp Suite
• Proxy
• Repeater
• APK Extractor + AndroidOS
General
• Fuzzers: RESTler, FFUF
• Content Discovery:
Kiterunner
• MacOS

26. 26
INSTRUMENTING
API ATTACKS
Reconnaissance
• Traffic analysis
• Burp Suite
• OWASP Zap!
• Mitmproxy
• Android
• APKleaks
• Enumeration
• Ffuf
• Kiterunner
• Arjun
Testing
• Authorization
• Astra
• Apidor
• Susanoo
• JWT
• Jwt_tool
• Jwt_cracker
• JSON Web Token Attacker
• Excessive Data Exposure
• Apicheck
• Injection
• API Fuzzer
• TnT-Fuzzer
• GraphQLmap
General
• Fuzzers: RESTler
• Content Discovery:
Kiterunner
• MacOS
*Check out work by David Sopas @dsopas for work in this area

27. 27
Fuzzing and Content Discovery
REDACTED
REDACTED

28. 28
WHAT IS RESTler
•RESTler (developed at Microsoft) is the first
stateful REST API fuzzing tool for
automatically testing cloud services through
their REST APIs and finding security and
reliability bugs in these services.
•For a given cloud service with an
OpenAPI/Swagger specification, RESTler
analyzes its entire specification, and then
generates and executes tests that exercise
the service through its REST API.

29. 29
Hacking with Burp Suite
REDACTED
REDACTED

30. 30
Best Practices in Securing
APIs
The APIs I’ve breached previously were secured behind Web Application
Firewalls (WAFs) – Don’t use rules-based controls because they don’t
understand context or can protect against authorization attacks
Authorization vulnerabilities are everywhere! Authenticate but also authorize:
Ensure scopes are being used with tokens
JWT tokens should have REALLY short time to lives (5-10mins)
Use refresh tokens (they can be revoked, access tokens can’t)
Refresh token stealing! Be careful around the security of your refresh tokens
(secure storage, use refresh token rotation, etc)
Hack your own APIs
Remember that FHIR is a specification and doesn't mandate how it's secured.
Vulnerabilities are per-implementation