Cyberattacks on NHS Radiology departments - suggested action

Open Forum
1

Afternoon all,

In the past few weeks, 3 NHS Trusts plus at least 1 major private provider have experienced attacks on their clinical systems infrastructure. The method and details of these attacks may or may not be made public by the departments/providers concerned over time, however one specific attack vector needs considering by PACS Managers:

Santisation of DICOM header fields in imported images

In at least one of the recent exploits which affected a UK Radiology department, a string of code was placed in the Patient Name DICOM tag on one image in a large set of imported images. When imported by the PACS team, the code in the DICOM tag was not sanitised by the PACS and the code executed. This code used the privileged account access of the PACS Manager logged in to deploy its payload.

As this is a fairly simple weakness now in the public domain, I would strongly recommend PACS Managers ask their PACS vendors to provide their DICOM header Content Security Policy and confirm explicitly that sanitisation of content in the DICOM headers is performed as part of the PACS import process by the PACS application such that no executable code can be entered into the sites database and run unknowingly by the importer. At the moment, it appears that not all of the major PACS vendors do this. If your vendor replies negatively to enquiries, it may be necessary to add this to a risk register and consider internal mitigation methods such as only importing images from ‘untrusted’ sources to a dirty / test or train PACS temporarily. This is crucial as many PACS vendors require anti-virus exceptions to cover the database, DICOM filestores and all related components - usual security measures may not notice the exploit. The Christmas period and holidays coming up present a ‘perfect’ time for attackers to attempt this, particularly if PACS offices are left with lower staffing.

Radiology has always been a prime target for attackers, but not having basic input sanitisation on DICOM headers during imports (and so blindly trusting the originator) feels potentially like an open goal now that miscreants are aware.

Al.

1 Like
2

Thanks for sharing, Al. I’ve logged a ticket with our supplier as you suggested. :heavy_check_mark:

1 Like
3

Likewise, ticket logged.

4

Has this issue been formally logged with NHS Digital?

5

Has this issue been formally logged with NHS Digital?

It has now if it hadn’t already been - I passed it on to our Cyber Security lead who tells me

“Our cyber regional lead has sent this to NHSE’s threat intel team for comment”

1 Like
6

Thank you Al - we have logged with our supplier

Best regards

1 Like
7

Thank you for sharing Al. Are you or your security colleagues able to share the code snippet or relay additional information concerning how the threat actor(s) were able to insert this code into the “read” pipeline for PACs employees at the impacted site?
Any additional information would be helpful for pacs vendors or security teams.
Thanks,
Tom

8

Hi Alex

Thank you for this information, concerning.

Can you clarify what an untrusted source would be? Assume CD imports etc but what about IEP could it be included as well?

9

For those interested in similar things, a basic example of inappropriate unsanitised user input being discovered is the 2020 Companies House database XSS issue (discussed in the mainstream press here: Company forced to change name that could be used to hack websites | UK news | The Guardian) or more technically on the official Companies House developers website here: Cross Site Scripting (XSS) Software Attack - #9 by awilliams - Companies House Developer Forum).

That particular issue was ‘more for show’ but caused a change in the Companies Act legislation to prohibit the registration of companies with HTML code in their names.

For Radiology, DICOM headers are considered to be a ‘user input’ which can be edited and manipulated with ease. If the PACS does not protect against malicious user input, there is a risk this could be exploited.

The best answer here is for suppliers to have already thought of malicious intent (the common ‘trust nothing’ approach) and have programmatically made it impossible in their software import routine. If this is the case, they should be able to confirm positively in a short period of time as it is fairly easy to test.

@TomR - It would be for the site affected really to offer that out, I am not aware what steps were taken afterwards. It usually takes a while for information to become more ‘public’.

@nicky.harvey - I believe IEP checks inputs and fails oddly formatted headers (really due to international characters being present in some transfers causing issues in the distant past - which now incidentally also removes the risk of code being included too!).

There is a theoretical issue in a miscreant physically going to an unattended modality (ultrasound machine springs to mind!), hand typing a string into a new patient screen, sending a reject image from there directly into a local PACS etc. That would be far more noticeable by staff who came along and saw it in the worklist afterwards though, and it’s likely most modern modalities don’t accept non alphabetic characters or have short field size limits in the accessible fields like patient name.

@Hughesy - I’ve heard they are.

As there has been a rather large amount of interest in this topic, both in the UK and internationally I’ll try and collate the PACS vendors responses as they are given out to Trusts. Hopefully that will help those who come to this page later see if their supplier has already confirmed such a vulnerability is not present in their PACS.

Just to be clear, none of these issues have occurred in any NHS Trust or private organisation I have personally worked in myself.

Al.

10

Not a piece of software seen much in the UK, but just received a link to a publicly available write-up of a similar recent PACS software / DICOM import vulnerability (CVE-2024-42845), which is publicly available as the imaging software affected is open source: https://cybersecuritynews.com/tic-tac-alert/

The attack described used a novel approach for malicious code to be inserted and executed using base64 (standard alphanumeric characters) in the Manufacturer and Institution Name DICOM attributes, rather than any easily filterable or disallowed special characters.

Makes an interesting read for anyone struggling to sleep after a busy Christmas day!