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: 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