Protecting the Holy Grail: Cybersecurity Obstacles to Lead Hackers Astray
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
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).
10 Cybersecurity Best Practices to Protect an Enterprise Imaging Environment and Lead Hackers Astray
- 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.
- Locate control system networks and remote devices behind firewalls and isolate them from business and other end-user networks.
- Use DICOM over TLS as it is highly desirable and recommended.
- 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
- 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.
- 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.
- Don’t run programs as root. Run programs as a user with restricted access.
- Make sure permissions are set to restrict access to specific files for users running the application. The rest should have no access.
- 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.
- 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.