Team82 Research
DICOM, the Digital Imaging and Communications in Medicine standard, governs the way medical imaging and patient data is transferred between physicians and healthcare delivery organizations (HDOs).
Team82 has researched the attack surface of this critical healthcare communication protocol and has uncovered a number of vulnerabilities in different DICOM implementations from leading medical device manufacturers. These vulnerabilities include CVE-2022-2120 (CVSS 7.5), CVE-2022-2119 (CVSS 7.5), and others.
The vulnerabilities could enable attacks against DICOM servers (mainly Picture Archiving and Communications Systems (PACS) machines) that expose their DICOM service or web management to the internet, without requiring the PACS server to expose additional services.
Successful exploits of these security flaws could result in denial-of-service and remote code execution attacks against these imaging devices. Impacted imaging devices that are taken over could damage the confidentiality, integrity, and availability of critical services, and impact patient care.
Have you ever had a CT scan? How about an MRI or an ultrasound? You might not know it, but besides being critical diagnostic tools that provide detailed images of our organs and bones, those scans have another thing in common: they communicate using the DICOM protocol standard.
DICOM, short for Digital Imaging and Communications in Medicine, is the standard network protocol and data format for the storage and transfer of medical images and patient data. The DICOM standard—used in hospitals, clinics and radiology centers worldwide—ensures that medical imaging equipment can properly share, store, transmit, process, and display medical modality images regardless of the manufacturer or proprietary technology involved.
From a cybersecurity perspective, DICOM addresses how data should be managed as it traverses digital channels, ensuring the protection of medical information in the digital realm. In this blog, we'll delve into the technical intricacies of DICOM's data exchange mechanisms, highlighting its vital role in cybersecurity.
Many different types of medical devices communicate over the DICOM standard, ranging from modality machines such as CT scanners, MRIs, ultrasounds, and PET machines. These kinds of modality machines create a new DICOM study or series—either a single image or scan (a series), or a related set of series (a study). Inside the study there are two types of data: the medical images taken by the machines, along with metadata such as information about the patient (like name, gender, age, etc.), the test performed on them (i.e., an abdominal scan), metadata about the study (date of the procedure), and more.
DICOM viewers are the client used by medical professionals to analyze and examine test results. These DICOM viewers usually receive or retrieve a DICOM sample, and display the images and metadata it keeps. This is the main business logic and requirement of the DICOM process, because it is here where the images are looked at and examined, and the patient is medically diagnosed.
While in the past DICOM viewers used to be a desktop application, receiving a DICOM study on a burned disk, in today’s age of hyper connectivity, this use case is no longer valid. In modern hospitals a network-based solution known as a picture archiving and communication system (PACS) machine is used. PACS acts as a database of DICOM studies, allowing medical professionals to connect to it using a viewer and fetch any studies they choose. In a sense, the PACS server connects the modality machines conducting the studies to the DICOM viewers, archiving the tests for later usage.
In order to fulfill the data-exchange needs of the protocol, a DICOM server (also called SCP Service Class Provider) implements and exposes different functionalities and interfaces.
For example, in order to store a study, a DICOM client (also known as SCU Service Class User) will invoke the C-STORE function, supplying the server with the study to store. If the user will instead want to query the server about different studies (for example, fetching studies of a specific patient), the SCU will instead invoke the C-FIND function, searching for studies with a certain filter.
In order to initiate a DICOM connection, the SCU and the SCP will first perform a handshake using the A-ASSOCIATE function, where each side will inform the other what kinds of features they support. During this handshake, the SCU and SCP will decide upon a common presentation context, which is an integral part of the DICOM handshake.
The presentation context answers two integral questions: what kind of data is exchanged, and how it is exchanged? It is composed of two parts:
abstract syntax which tells the parties what kind of data they wish to exchange, for example, data related to CT scans.
presentation context which is the transfer syntax that tells the two parties how the data is being sent over the network. For example, if a compression algorithm is used on the images (JPEG, JPEG2000), both parties should be aware and make sure that they support this compression algorithm for the data exchange to go through. Another example of the transfer syntax is whether the parties will use an explicit or an implicit syntax in their network communication (which will be explained below).
Lastly, before understanding the attack surface and risk on DICOM applications and devices, we must understand how data elements in DICOM are structured and interpreted. Each element in a DICOM study is composed of a tag, a value representation (VR), and the data element itself.
First comes the tag, whose main purpose is specifying what information is being passed (for example, Patient’s Name). DICOM tags are 4 bytes long and are composed of two sections: group number (GGGG) and element number (EEEE), each represented by two bytes (4 hex characters). Together, the two parts identify and describe the element that will be passed. Let's take a look at the Patient’s Name tag for example:
Group Number (GGGG) = 0010
Element Number (EEEE) = 0010
Patient’s Name = (0010,0010)
After the tag, comes the value representation (VR) of the element. A DICOM VR defines the data type and format of an element, which is used in order to understand what information is being stored, and how it should be represented and parsed. The VR is two bytes long and is composed of two ascii characters. Different types of VR exist; for example a VR of PN represents a person’s name and should be read as a string, where DA represents a date.
While VRs are an integral part of DICOM elements, they are not always explicitly specified. If an Implicit Transfer Syntax is decided, no VR will be sent inside the data element and the DICOM application should use the default instead. For example, if the tag is Person Name (0010,0010), the application should set the VR to PN. If an Explicit Transfer Syntax is used, a VR value should be sent as part of the element.
Lastly, after the VR comes the actual data element, which is sent according to the VR that should be used.
While the DICOM protocol and standard is precise and details in great length how applications should send and parse DICOM studies, it does not explicitly define strong security mechanisms, instead leaves this section vague and up to the vendors and users to define.
With regard to encryption, while it is possible to use DICOM over a TLS connection, it is not explicitly a requirement/part of the protocol, rendering the use of TLS in DICOM up to the developers and implementers. In reality, DICOM servers rarely use an encryption protocol for their traffic, and instead send sensitive information over the network in plain text. This leaves DICOM traffic an easy target for attackers, allowing them to exfiltrate and obtain sensitive personal identifiable information, along with the ability to MiTM traffic and alter it.
DICOM has also been heavily criticized for having weak username/password-based authentication and lacking features such as multi-factor-authentication and strong access control lists (ACLs). While it is possible to have proper authentication in DICOM, a majority of DICOM servers do not use these features, and instead leave their sensitive information exposed to unauthenticated/unauthorized attackers.
We have seen a spike in recent years of attacks targeting servers that store DICOM studies. Currently, DICOM servers are a prime target for rogue hackers, hacktivists and ransomware gangs, as they hold sensitive personally identifiable information (PII) that organizations do not want leaked.
By targeting and exploiting DICOM-based PACS machines, attackers can disrupt medical organizations by threatening the exposure of sensitive patient information. Extortion attacks against healthcare delivery organizations (HDOs) are rampant; attackers demand payments, or otherwise threaten to leak patient and business information, sometimes in conjunction with a ransomware attack that encrypts and decommissions DICOM studies, which could cause serious physical damage and risk.
During an incident in June, a hacking group had access to a popular radiology center’s DICOM studies and leaked patient information of thousands of people, including their medical records, personal information, diagnoses, etc. The hacking group later leaked the entire attack’s database in their Telegram channel and website.
To better understand the exposure of private DICOM studies, we used available tools and information to search for publicly accessible AWS and Azure cloud storage buckets containing sensitive and unencrypted DICOM files. We learned there are thousands of these storage buckets accessible to anyone that contain millions of exposed DICOM files that are within reach of attackers. For example, we used GrayhatWarfare’s tool to search buckets for any files ending in DICOM’s suffix (.dcm), which resulted in us finding millions of DICOM files stored on public buckets.
These buckets are a serious security and privacy concern, because many organizations upload all of their samples to the cloud automatically, and due to misconfigurations, these buckets are set to public access rather than private. In many cases, the organizations are not even aware of the state and configuration of these buckets.
In addition to the open buckets, we wanted to search for internet-facing PACS servers, mostly due to misconfiguration, which hold the DICOM samples and might expose them to an external actor. To look for internet-exposed PACS servers, we used internet-scanning services, including Shodan.io. By leveraging Shodan, which constantly scans the entire IP range, we were able to query its dataset and search for servers exposing DICOM services. We were surprised to discover ~4,150 PACS servers around the world that expose their DICOM service to the internet.
When we looked at the results of the data we acquired, we discovered that the vast majority of these servers are located in the USA (~1,200), India (~400), and Germany (~300). In these open DICOM servers we noticed popular universities, radiology centers, clinics, and even some hospitals among those exposed.
While simply having the PACS server exposed to the internet does not mean that attackers could access the sensitive information kept on the PACS machine, mainly due to strong authentication/ACL, it does increase the attack surface considerably.
This was the point we started our vulnerability research, pointing our focus to DICOM software development kits (SDKs) because of the potential a single SDK vulnerability could have on thousands of products where it may be implemented.
We started our research looking at the collection of DICOM libraries and applications called DICOM Toolkit, or DCMTK, used by thousands of medical device manufacturers and developers.
We examined two main functionalities implemented in DCMTK, DICOM file parsing and the handling of different DICOM functions, such as C-STORE and C-GET. At the end of our research into DCMTK, we managed to identify three different vulnerabilities:
CVE-2022-2121: A null pointer dereference vulnerability leading to memory corruption during the DICOM parsing routine when reading files from STDIN.
CVE-2022-2119: A path traversal vulnerability in the DCMTK SCP application, inside the C-STORE routine. By connecting to a DICOM SCP server and invoking a C-STORE function, providing a malicious DICOM study, it is possible to write files in arbitrary locations on the server, which could result in a denial-of-service attack, and in some cases even remote code execution, depending the high-level application using this library.
CVE-2022-2120: A path traversal vulnerability in the DCMTK SCU, inside the C-GET routine. By allowing an SCU to connect to a malicious DICOM SCP, it is possible for the malicious server to achieve write primitives on the connecting client, which could lead to a DOS attack and in some cases even remote code execution, depending on the high-level application using this library.
By identifying vulnerabilities in the DICOM protocol implementation, it is possible to attack DICOM servers (mainly PACS machines) that expose their DICOM service to the internet, without requiring the PACS server to expose additional services.
After we found vulnerabilities in one of the most popular DICOM libraries, we started to focus on a popular PACS implementation: Softneta MedDream. MedDream is one of the more popular viewer and PACS applications, boasting many DICOM and web management capabilities.
Our goal this time was not finding vulnerabilities in the DICOM parsing primitives necessarily, instead we aimed to find vulnerabilities in the platform, which might be exposed on internet-facing installations. Since MedDream exposes a few web-based endpoints, mainly the web-based DICOM viewer and the PACS management platform, we started our research there.
We were able to identify an unauthenticated remote code execution vulnerability on Softneta Meddream PACS installation, tracked as CVE-2023-40150. The vulnerability, stemming from a route that does not require authentication and allows users to execute arbitrary code, could be abused by attackers to take over PACS machines and take over the DICOM network.
The core issue we exploited in our vulnerability is an unauthenticated API route, /Pacs/originalImage.php, which allows users to move files in the server’s filesystem. While this API route does not allow users to move arbitrary files, this primitive could still be achieved by performing a specific set of operations.
In its regular usage, this API route receives only one parameter: a path parameter, and tries to rename the file by removing the first six characters of the filename. The actual usage of this API route is to rename backup files to their correct name, by removing the backup prefix from the filename.
While this does not allow us to move arbitrary files in the filesystem, we still managed to achieve this primitive by combining multiple techniques, mainly gaining the ability to move files into other directories, and changing a file’s suffix. This gave us the ability to move any file on the system to any location we choose, along with the ability to change its name arbitrarily.
First, we start moving a file to the previous directory in the filesystem tree by abusing the bug that the server only tries to split the filename and directory by searching for a forward slash (/). However, on Windows machines, a backslash (\) serves the same purpose, separating two different parts of a path. By using a backslash (\) instead of a forward-slash (/), we managed to move files one directory at a time. For example, to move a file named FILENAME from DIR_A/DIR_B to DIR_A, we can supply the following payload:
c:/DIR_A/DIR_B/..\\\\FILENAME
This will result in the file being saved under DIR_A/FILENAME instead of DIR_A/DIR_B/FILENAME changing its location in the filesystem. Similarly, we managed to move files downwards in the file directories, giving us the ability to move files completely arbitrarily to any place we want as SYSTEM.
In order to write a malicious PHP payload to a file on the system, we abused the fact that the server initiates a session and saves a parameter we control in the session (the $path variable). In PHP, sessions are saved in files, meaning we can simply move our PHP session file to the web root directory, allowing us to cause the server to execute it. This gave us the ability to execute arbitrary PHP code, giving us preauthenticated remote code execution on the vulnerable PACS server.
Because of the vulnerability’s severity, allowing attackers to execute arbitrary code remotely on the PACS machine, and because it does not require authentication or preknown knowledge, this vulnerability received a 9.8 CVSS score.
To demonstrate the possible severity of attacking DICOM PACS machines, we created a demo showcasing such an attack scenario.
In our demo, a pregnant person is undergoing an ultrasound test, allowing the doctors to see and test the fetus’s health.
First, the ultrasound technician takes images for the doctor to perform their checkup. Behind the scenes, a DICOM study is created, organizing the entire test under study, including the images the technician took, along with the patient information and general metadata. This study is then stored in a PACS machine, allowing the doctor to connect with their viewer and perform the checkup.
This is where our attack begins, where a malicious attacker tries to cause physical damage and disruption. By attacking the PACS machine, the attacker leaks the entire patient database, including personal medical information, images etc. However, to make matters worse, the attackers do not simply leak the information, instead they choose to alter some of its data.
By gaining full control over the PACS machine, the attackers alter some of the DICOM studies, specifically the pregnant person’s ultrasound test. The attackers alter the images the ultrasound technician took, and choose to add another fetus to the woman’s test. By changing the DICOM study, attackers managed to confuse and force the doctor into thinking that the pregnant person has a set of twins, which might cause catastrophic consequences.
DICOM’s standing as the standard medical imaging communication protocol reinforces the need to secure it properly, especially as more HDOs digitize diagnoses, treatments, and patient consultations.
Team82 has demonstrated vulnerabilities and insecure implementations of crucial DICOM software libraries that could affect products from dozens of medical device manufacturers and impact the personal safety of thousands of patients.
In this report, we provided some details on three vulnerabilities in the DCMTK DICOM SDK toolkit that could disrupt the operation of critical imaging machines in hospitals worldwide. Further, some of these security issues could also be abused for remote code execution. In one example, we demonstrate how an attacker may remotely inject code that alters DICOM images and could impact patient diagnoses and treatment.
As more HDOs connect medical devices to the internet, awareness of the existence of these vulnerabilities is crucial to the long-term safety and privacy of patients.
CWE-23: RELATIVE PATH TRAVERSAL
The affected product's service class user (SCU) is vulnerable to relative path traversal, allowing an attacker to write DICOM files into arbitrary directories under controlled names. This could allow remote code execution.
CVSS v3: 7.5
CWE-22: IMPROPER LIMITATION OF A PATHNAME TO A RESTRICTED DIRECTORY ('PATH TRAVERSAL')
The affected product's service class provider (SCP) is vulnerable to path traversal, allowing an attacker to write DICOM files into arbitrary directories under controlled names. This could allow remote code execution.
CVSS v3: 7.5
CWE-749: Exposed Dangerous Method or Function
The affected product does not perform an authentication check and performs some dangerous functionality, which could result in unauthenticated remote code execution.
Softneta recommends users update to v7.2.9.820 of MedDream PACS Server or patch their current system using Fix-v230712.
CVSS v3: 9.8
CWE-476 : NULL POINTER DEREFERENCE
The affected product has a NULL pointer dereference vulnerability while processing DICOM files, which may result in a denial-of-service condition.
CVSS v3: 6.5
