415-684-8790Technical support
Request a Meeting
  1. Home
  2. Blog

Protecting the Holy Grail: Cybersecurity Obstacles to Lead Hackers Astray

By Dmitriy Tochilnik

In the plot of the third installment of the Indiana Jones saga, The Last Crusade, the eternal search for the Holy Grail takes center stage. In order to save his father’s life (played by Sean Connery as Dr. Jones Sr), the hero must pass a series of cumulative and lethal tests to reach the final test: choosing the right cup among many possible choices. Each test, if misinterpreted, meant certain death for Indiana Jones, and his father. Remember the scene where “only the penitent man will pass…”? The ability to Interpret penitence as kneeling before God is what saves him from being beheaded by an ancient boobytrap.


Scene from the movie Indiana Jones and the Last Crusade. Source: Paramount Pictures

In many ways (and far more nefarious than the quest for the divine), a hacker’s search for a way into your enterprise is in and of itself a search for a holy grail: a treasure trove of data to exploit for profit. We’re using this (far-fetched) analogy to make a simple point: if you place enough smart obstacles between bad actors and your patient’s data, you stand a better chance to thwart possible attacks. You simply need to design your solutions with built-in boobytraps to compound the degrees of difficulty for them to break in, to the point that the effort is no longer worthwhile. It is possible to make hacking a system as elusive as the search for the Holy Grail.
Enterprise imaging is not a common target for cybersecurity attacks. It’s a niche industry and usually unappealing to attackers because it requires significant effort to harvest data for a possible ransom. This is the main reason we don’t routinely hear about sophisticated breaches involving medical imaging. Most hackers focus their attention on EMRs and other IS systems that constitute more obvious and less challenging targets. Therefore when concerns surrounding the DICOM Toolkit (DCMTK) and its vulnerabilities surfaced earlier this year, the industry took note.

What is the DICOM Toolkit (DCMTK) and the Impact of its Vulnerability?

The DICOM ToolKit (DCMTK) is a package that consists of source code, documentation, and installation instructions for a set of software libraries and applications implementing part of the DICOM/MEDICOM Standard. When the DCMTK vulnerability was uncovered in June 2022 it created huge noise and concern in the enterprise imaging community. DCMTK is widely used among PACS/MIMPS, VNA, and other imaging software vendors. Developed for a wide range of platforms, DCMTK is a set of over 20 open-source C/C++ libraries and utilities including the following sub-packages, each in its sub-directory:

  • config: configuration utilities for dcmtk
  • dcmdata: a data encoding/decoding library and utility apps
  • dcmect: a library for working with Enhanced CT objects
  • dcmfg: a library for working with functional groups
  • dcmimage: adds support for color images to dcmimgle
  • dcmimgle: an image processing library and utility apps
  • dcmiod: a library for working with information objects and modules
  • dcmjpeg: a compression/decompression library and utility apps
  • dcmjpls: a compression/decompression library and utility apps
  • dcmnet: a networking library and utility apps
  • dcmpmap: a library for working with parametric map objects
  • dcmpstat: a presentation state library and utility apps
  • dcmqrdb: an image database server
  • dcmrt: a radiation therapy library and utility apps
  • dcmseg: a library for working with segmentation objects
  • dcmsign: a digital signature library and utility apps
  • dcmsr: a structured reporting library and utility apps
  • dcmtls: security extensions for the network library
  • dcmtract: a library for working with tractography results
  • dcmwlm: a modality worklist database server
  • oflog: a logging library based on log4cplus
  • ofstd: a library of general purpose classes

The Dicom Systems Unifier platform uses some of the core DCMTK libraries, but not DCMTK SCU and SCP, which were affected by the breach.

The DCMTK vulnerability was based on a common and basic weakness called “Path traversal.“ Path traversal occurs when there is an improper limitation of a pathname to a restricted Directory and “Relative path traversal.” This was uncovered as a vulnerability for DCMTK specifically and can also possibly affect other libraries.

According to its self-reported version number, the instance of OFFIS DCMTK DICOM Toolkit hosted on the remote server is affected by multiple vulnerabilities:

  • OFFIS DCMTK’s (All versions before 3.6.7) 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 (CVE-2022-2119).
  • OFFIS DCMTK’s (All versions before 3.6.7) 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 (CVE-2022-2120).
  • OFFIS DCMTK’s (All versions before 3.6.7) have a NULL pointer reference vulnerability while processing DICOM files, which may result in a denial-of-service condition (CVE-2022-2121).
Even if the DCMTK vulnerability was mostly theoretical, and a misconfigured OS was required for an attacker to succeed, it shouldn’t be taken lightly. It caused collective uneasiness across the enterprise imaging community. Many users were not aware of the vulnerability and didn’t try to reproduce the issue in their environment, nor did they review their architecture to see if it potentially had short to medium-term repercussions.
Threats and resulting extensive testing procedures have a direct impact on the overall cost and complexity of software development. Insurance companies demand increasingly expensive policy premiums and safety protocols from software companies. While it is extremely important to perform different tests and security verification on all proprietary software and open source code there are certain measures you can take to prevent security incidents or significantly minimize risk in the event of an incident. Vulnerabilities are unfortunately inevitable and it’s not a question of if, but rather when they will occur.
There are proactive steps to mitigate the impact of any type of vulnerability and to make sure systems stay secure even in the event of failure.

10 Cybersecurity Best Practices to Protect an Enterprise Imaging Environment and Lead Hackers Astray

Here are 10 important steps to proactively protect an enterprise imaging environment, even as new vulnerabilities occur.
  1. Minimize network exposure for all control system devices and/or systems, and ensure they are NOT accessible from the Internet. DICOM is not a secure protocol.
  2. Locate control system networks and remote devices behind firewalls and isolate them from business and other end-user networks.
  3. Use DICOM over TLS as it is highly desirable and recommended.
  4. Make sure a valid certificate is loaded on the server for DICOM over TLS and HTTPS traffic. It can be signed by a local CA authority but it has to be valid. Encryption ciphers need to be verified and complied with the latest version. The cipher suite has been whittled down substantially for TLS 1.3, to the point where there are five recommended cipher suites:
    • TLS_AES_256_GCM_SHA384
    • TLS_CHACHA20_POLY1305_SHA256
    • TLS_AES_128_GCM_SHA256
    • TLS_AES_128_CCM_8_SHA256
    • TLS_AES_128_CCM_SHA256
  5. If secure transmission over TLS is not available and remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities of their own and should be routinely updated to the most current version available. Also recognize VPN is only as secure as the devices connected within its boundaries.
  6. Only allow access to devices you are communicating with and make sure promiscuous access is disabled. Imaging device vendors can only allow DICOM traffic from/to specific devices.
  7. Don’t run programs as root. Run programs as a user with restricted access.
  8. Make sure permissions are set to restrict access to specific files for users running the application. The rest should have no access.
  9. Introduce chroot access. A program that is in a modified environment and cannot name (and therefore normally cannot access) files outside the designated directory tree. The term “chroot” may refer to the chroot(2) system call or the chroot(8) wrapper program. The modified environment is called a chroot jail. Containers are chroots on steroids.
  10. No remote access for admin users (root) and Active directory or single sign-on authentication for regular users for remote access.

The Matrix Resurrections movie has a remarkable illustration of how network access points can be routinely leveraged to create shortcuts to other access points.

Within the construct, there are a series of dark green doors in a seemingly endless white corridor, unlocked by a specially made key. These were used by Programs to quickly get from one place to another. In code, these were simply loopholes. At one end of the corridor was a door to the most special room, including the door to The Source. Backdoors act as a kind of shortcut hyperlinking system. While backdoors are part of the Matrix, Operators cannot see the code of people who enter their hallway – it is a sort of under-layer to the main construct of the Matrix, containing shortcuts to many other places.

To break into systems through a backdoor, you have to have keys to many doors, not just one. If you design your systems to natively include multiple keys for multiple doors and possibly add more doors in future design, you can substantially reduce exposure to possible vulnerabilities in your product.

A backdoor is a type of door that can be used to access nearly any part of the Matrix. Source: Fandom

An often overlooked vulnerability is browser-based password syncing for multiple accounts, commingling personal and business credentials on the same machine. The Cisco VPN breach was originally achieved by proxy, by compromising a Cisco employee’s personal Google account credentials. The end-user had enabled password syncing via Google Chrome and had stored their Cisco credentials in the same Chrome browser, thereby enabling sensitive information to synchronize to their personal Google account.

“Didn’t I tell you not to trust anyone, Dr. Jones?” the famous quote by Walter Donovan (Julian Glover) is the main antagonist of Indiana Jones and the Last Crusade. You do not want to follow the bad guy’s advice but good guys should have this approach when they design cyber security policies for the software.

Want to learn more about the Dicom Systems Unifier platform? Meet with one of our enterprise imaging workflow experts
Request a meeting