iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: https://threatpost.com/hipaa-protected-malware-medical-images/143890/
Ubiquitous Bug Allows HIPAA-Protected Malware to Hide Behind Medical Images | Threatpost

Ubiquitous Bug Allows HIPAA-Protected Malware to Hide Behind Medical Images

The ubiquitous nature of the flaw opens the door for rapidly spreading, crippling cyberattacks.

A bug in a 30-year-old standard used for the exchange and storage of medical images has been uncovered; it allows an adversary to embed fully-functioning executable code into the image files captured by medical devices such as CT and MRI machines.

This results in hybrid files that allow malware binaries to hide behind intact, standards-compliant images that preserve the original patient data – as such, they can be used and shared by clinicians without arousing suspicion.

“By exploiting this design flaw attackers can take advantage of the abundance and centralization of DICOM imagery within healthcare organizations to increase stealth and more easily distribute their malware, setting the stage for potential evasion techniques and multi-stage attacks,” said Markel Picado Ortiz at Cylera Labs, who found the bug, in an analysis this week.

Further, according to Ortiz, by mixing in with protected health information malware can effectively exploit the data’s clinical and regulatory implications to evade detection. Because of stringent privacy regulations in HIPAA regulations, medical device manufacturers and healthcare organizations often configure anti-malware software to ignore medical imagery and files containing protected health information.

Ortiz said that the vulnerability, which he has a proof-of-concept exploit for, exists in DICOM, which is a global and ubiquitous imaging standard within the healthcare industry, originally drafted by National Electrical Manufacturers Association (NEMA). It defines a file format for the representation and storage of medical imagery and a communication protocol for the transmission of imagery over a network.

The DICOM standard is used by the systems that produce imagery, specialized workstations for analyzing scan results, and even phones and tablets used to view diagnostic information.

Digging deeper, the DICOM file format standard has a header with a 128-byte section at the beginning of the file, called the Preamble, that can be used to facilitate access to the images and metadata within the DICOM image.

A third party can use the Preamble to enable compatibility with DICOM-unaware applications that expect common image formats; i.e., by design, the standard allows a third party to control the sequence of bytes within the Preamble, crafting it to trick image viewers into believing a DICOM file is actually another image format that would be compatible with them.

This however can have unintended consequences: “While the DICOM standard intends for the field to be used to enable compatibility with non-DICOM image viewers, such as JPG and TIFF images, the standard does not impose any structural requirements on the data inserted into the Preamble,” explained Ortiz. “Any arbitrary sequence of 128 or fewer bytes can be inserted without jeopardizing the image file’s conformance with the DICOM standard.”

Thus, this “feature” can be abused by attackers to fully embed a functioning executable into a DICOM image, while preserving the ability of the file to both be executed by the operating system, as any other executable would, as well as act as a standards-compliant DICOM image file.

In the PoCs, Ortiz shows that to execute commands on remote hosts, an attacker would need to have valid Active Directory credentials or permissions. “In many networks, however, it is common to have shared credentials for devices, a weakness that has been exploited in cases such as the Kwampirs campaigns by the Orangeworm Group that targeted healthcare organizations,” he noted.

A local attacker with access to the healthcare network could also locate and tamper with an image, then execute it on the network to start the attack process.

In both cases, it’s possible to create an attack that uses worm-like self-propagation to spread through the network, as he demonstrates in the PoC.

The implications of this new attack vector are myriad, Ortiz points out, including consequences on the evasion, propagation and persistence fronts.

“This enables new and existing malware to evolve into more potent variants, optimized for successful compromise of healthcare organizations, by using the infected patient data to hide, protect and spread itself – three of the primary functions that determine the effectiveness of a malware campaign,” Ortiz noted.

When it comes to evasion, the file will not exhibit any artifact “.exe” files; the altered DICOM images will retain their “.dcm” file extensions. And, when an analyst inspects the file, it will open the original DICOM image and display the clinical information as it would pre-infection. The flaw also enables evasion of A/V software in addition to human analysts and system administrators because of the aforementioned HIPAA-aware configurations of most of these solutions being used in healthcare settings.

In terms of propagation, the approach allows malware to be used as part of a multi-stage attack by making use of the transfer of DICOM imagery.

“Imaging results are not only shared within a single organization but between organizations with overlap in patients treated,” Ortiz explained. “Patients will sometimes seek specialists who are experts in particular domains that are not handled by their local healthcare organization. Infected records could be transferred to the new organization as part of a consultation, thereby spreading infected DICOM files not only between departments within an organization, but across organizational boundaries and into completely unrelated healthcare organizations. The malware effectively “follows” the patient from organization to organization.”

Also, central repositories of DICOM files provide a single infection point that could proliferate the malware-infected image to a large number of clinical devices as patient information is pulled during the course of patient diagnosis and treatment.

And finally, when it comes to persistence in the face of remediation attempts, the malware is essentially fused to legitimate imaging files. As such, incident response teams and A/V software cannot delete the malware file as it contains protected patient health information. They also cannot deny access to the retrieval and viewing of the file in order to contain the malware without the risk that they will impede clinical operations. Conversely, response teams that are unaware the file contains patient information could potentially destroy patient information in the mitigation process.

“Response teams and A/V software that are aware the file contains patient information are left in a difficult situation where they must balance cybersecurity, clinical and regulatory risk as they respond to malware that is effectively using patient data as a shield,” Ortiz said.

He added, “[These] files are not only exploiting a vulnerability in a file format, but an unfixable vulnerability in healthcare data regulation as well. If this flaw was instead in a file format for images that were not protected by HIPAA, it would not be as technically effective. This is the first vulnerability whose technical potency is derived from a regulatory environment in addition to a software design flaw.”

Fixing the issue is not an easy one. In the long-term, a modification to the DICOM file format specification is ideal, but that’s sure to be an extensive effort.

“DICOM has become ubiquitous within healthcare,” Ortiz said. “The number of systems supporting DICOM is innumerably large. There is no single vendor that can provide a patch and no single action that can be taken to fix the root cause of the issue across all systems using DICOM. Any change to the specification must be carefully considered to preserve interoperability between systems that may be designed to different versions of the specification before software vendors even begin to upgrade their own implementations.”

Thus, in the short term, healthcare organizations should fortify existing systems with network segregation, changing default credentials, and by implementing mechanisms to detect abuse. They also should proactively create processes for “appropriately responding to and mitigating attacks exploiting this flaw,” according to Ortiz – that means having a way to analyze the Preamble and wipe it clean, if necessary.

Don’t miss our free Threatpost webinar, “Data Security in the Cloud,” on April 24 at 2 p.m. ET.

A panel of experts will join Threatpost senior editor Tara Seals to discuss how to lock down data when the traditional network perimeter is no longer in place. They will discuss how the adoption of cloud services presents new security challenges, including ideas and best practices for locking down this new architecture; whether managed or in-house security is the way to go; and ancillary dimensions, like SD-WAN and IaaS.

Suggested articles