Submitted via IRC for Bytram
Bug Allows HIPAA-Protected Malware to Hide Behind Medical Images
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.
[...] “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.”
(Score: 4, Interesting) by hendrikboom on Thursday April 18 2019, @02:56AM (14 children)
The bug allows a single file to simultaneously satisfy the file formats of DICOM files and of Microsoft executable images.
Thus systems that treat DICOM files as DICOM files will have no problems.
It's systems that look at the files to determine what to do with them that will have problems, assuming they have a preference for execution, ignore the file type extension, and have no worries about executing files of unknown origin.
(Score: 5, Insightful) by NotSanguine on Thursday April 18 2019, @03:06AM (13 children)
Most of the time, these images are distributed on DVD with accompanying software provided by a radiology lab.
Given that those labs *create* such files and then burn them to DVD, it's likely (and much easier than a doctor's office or a hospital) that such labs would be the primary place to inject malware into the distribution stream.
And if a radiology lab that services hundreds of medical practices is compromised, this *could* be a really big deal.
Since the white hats only identified this vulnerability eight days ago and the vulnerability has been around for 30 years, there may well be many compromised systems *right now*.
But even if this hasn't been exploited previously, all it takes is one compromised system to give malicious actors access to whole hospitals, potentially allowing them to modify drug and treatment regimens, prescriptions, patient health and billing data and who knows what else.
As such, mitigations need to be applied ASAP and the DICOM standard modified to disallow the execution of arbitrary code, or people may die.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Interesting) by Rich on Thursday April 18 2019, @12:13PM (9 children)
That's more like a text file "how-to-wipe-a-drive.txt" with content similar to:
causing Clippy to jump into action: "It looks like there is shell code in your text file. Do you want me to execute it? [ >>> YES <<< ] ...... [no]"
(Score: 2) by NotSanguine on Thursday April 18 2019, @12:38PM (8 children)
I'm sorry. I don't really understand the point you're trying to make.
Is this related to the potential for embedding executable code in DICOM files? If so, what's the parallel?
If not, what are you trying to get at?
I'm honestly not trying to bait you, I really don't get your point.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by hendrikboom on Thursday April 18 2019, @03:13PM (7 children)
Actually, those two lines of shell script are small enough to fit in the first area of a DICOM file, and so can be propagated the way TFA says.
(Score: 2) by NotSanguine on Thursday April 18 2019, @03:35PM (6 children)
True, but Windows doesn't ship with the Bourne Shell.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by Rich on Friday April 19 2019, @11:44AM (5 children)
The point was that executables in any form cause no harm unless they are run, not even if they are in a proper ".exe". Security researchers with their collection of malware samples can attest to that. And executables should run only in a limited number of circumstances: when invoked in a text shell, opened in a visual shell, scheduled by the system, or as sub-task by one of the above.
The idea that an end-user application (which in this case might think it's some sort of shell) looks into arbitrary files and launches alien code whenever it thinks it might be executable, even when the filename suffix (which is so 70's!) indicates something entirely different, is pure lunacy.
Thinking about it, they said it's a systemic bug with the format, which doesn't imply that the affected systems run Windows.
(Score: 2) by NotSanguine on Friday April 19 2019, @05:08PM (4 children)
Funny. I guess it's understandable that you would say such a thing, given that you likely didn't read TFA.
From TFA:
Aside from the fact that the exploit appears to be Windows specific, many applications use header information to make decisions as to the purpose of a particluar file based on the file's preamble. *nix will also use the preamble to determine the file type as well (cf. file(1), magic(5) )
Beyond that, GP's comment [soylentnews.org] includes an example with a bourne shell script and then invokes "Clippy." I was unaware that MS ported Clippy to *nix platforms.
As I mentioned [soylentnews.org], this could be particularly problematic in radiology labs that service dozens or hundreds of hospitals and medical practices.
Not so much that the particular payload (128 bytes) in such a modified DICOM file could be incredibly functional, but given that most devices hae access to the internet wold allow an attacker to embed code to download/execute malware compromising that system and actively seeking to exploit others on the same network.
As to GP's "example," it's a terrible example that doesn't fit with the real world.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by Rich on Friday April 19 2019, @06:08PM (3 children)
Well, what mechanism executes this preamble, as benevolent, or malevolent as it may be, then?
To the best of my knowledge, the Windows system wants an extension for executing anything (hence these phishing mails with "malware.pdf.exe" filenames or weird extensions that MS once forgot to clean up) and doesn't use tools like "file". (In fact, UNIX would be more threatened when the malware DICOM image comes on a DVD or DOS image that gets mounted with 777 permission for everything, and then someone uses the equivalent to shell "open").
So, unless there is some utterly braindead application pretending to be a smart shell (hence the Clippy example), there is simply no way to get the payload executed. Someone makes the deliberate decision to look into the file, decides it looks like an executable, and then blindly runs it, DESPITE it having a different extension (unless the above "malware.dicom.exe" trick is leveraged). It takes effort to go THAT far.
By the way, the Mac had all that right in 1984 with type/creator codes.
(Score: 2) by NotSanguine on Friday April 19 2019, @06:32PM (2 children)
Looking back at your original comment, I see that you are the GP. As I said in my initial reply, I wasn't trying to bait you or troll, I just didn't understand what you were getting at. Thank you for elucidating.
That's about the size of it. But of course there aren't any brain dead applications out there.
Which is, of course, why the exploit developed could never, ever work. Except the PoC exploit [github.com] demonstrates that it can.
As I said in my initial comment:
A back door into hospital systems could allow malicious actors to modify drug dosages in treatment orders (potentially causing toxicity, overdose, and/or death), change billing records, exfiltrate private medical information and who knows what other sorts of mayhem.
As such, even *if* the risk of exploitation is low (and with the publication of the analysis we're discussing, that risk just went way up), the potential consequences are way too serious to ignore, IMHO.
I take your point that this vulnerability shouldn't be exploitable but, sadly, it is.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by Rich on Friday April 19 2019, @06:44PM (1 child)
Which is, of course, why the exploit developed could never, ever work. Except the PoC exploit [github.com] demonstrates that it can.
Here's the demonstration:
https://github.com/d00rt/pedicom/blob/master/rsc/poc.gif [github.com]
Well, as we can see, it does work.
If someone renames the file to end in ".exe" by hand.
If you get them THAT far, you can also to ask them to just download whatever you want them to, and run it.
By the way, there were legit use-cases for actual dual-use files which you would either want to run OR execute, like self-extracting archives. I say "were", because that's obviously high-risk these days. The risk might be bearable with signatures.
(Score: 2) by NotSanguine on Friday April 19 2019, @07:20PM
By *default* file extensions are not shown in Windows explorer [howtohaven.com].
As such, if you are given such a file (say on a DVD), unless your system has already been modified (manually or through group policy) to *always* show file extensions, you'll never see it coming.
Which is why the example I gave of compromising a radiology lab is particularly pernicious, since most folks (whether doctors or patients) will just stick the DVD in and click on what they think is just an image file and they're compromised. What's particularly bad about this is that the user will then see the image(s) load normally and won't realize what's just happened.
As I've said repeatedly, *even if* (and. after the publication of this analysis, not so much) the risk of exploitation is small, such exploitation could result in serious consequences, up to and including the death of patients.
Are you suggesting that because *you* (and I) know how to detect such subterfuge, that mitigations (e.g., Group Policy modifications to always show file extensions) and modification of the DICOM standard to disallow such preamble inclusions aren't useful or are unnecessary?
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Interesting) by DavePolaschek on Thursday April 18 2019, @02:10PM (2 children)
Or sometimes they're distributed without accompanying software. My most recent knee MRIs came with no software. All I got was the images.
In that case, a naïve user might double-click the file to see what application might open it.
(Score: 3, Insightful) by NotSanguine on Thursday April 18 2019, @02:22PM (1 child)
An excellent point. That's certainly a vector for compromise. Especially since more people get copies of medical imaging *and* have the means to view them.
Upon re-reading my original comment, I wasn't explicit about the risks associated with DVDs *with* software. If a radiology lab is compromised via DICOM images, the systems that create the DVDs could be used to inject malware into both the images themselves *and* the software included.
Apologies if that wasn't clear.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 0) by Anonymous Coward on Thursday April 18 2019, @05:03PM
I read just enough of TFA to figure out what file extension to be wary of--
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.
(Score: -1, Offtopic) by Anonymous Coward on Thursday April 18 2019, @03:24AM
see doctor, i told you that gerbil is not in my ass
(Score: -1, Offtopic) by Anonymous Coward on Thursday April 18 2019, @04:18AM
DIC