July 5, 2011
Coding for Death: Exploits that can Kill
This is the story of how I (probably) could have used an Acrobat bug to kill my Dad.
Word Count: ~890
Please see the correction to this article at the bottom of the page
Citing prior work is important so let me be clear in stating this idea (killing someone via an exploit) isn’t mine nor is it particularly new. The first time I saw a realistic example of how hacking could be used to kill someone was in one of those Syngress Stealing the Network: * books where a character changed someone’s blood type in a hospital record. I doubt the idea started there either. That being said, what follows are my experiences and observations.
Back in 2005 Dad had his first CABG to do a quad bypass. Every year thereafter until his death in 2009 he would have cardiac incidents that would require an angiogram or angioplasty. In that procedure essentially doctors snake a thin cable with various attachments through the femoral artery in your upper inner thigh up to your heart. From there they can take pictures from the inside of various structures or using different attachments put in stents, laser out plaque, write their initials, etc. To me that kind of technology is amazing and medical science is one of the things I always wish I knew more about.
At the time of this procedure everyone was finding out that the Acrobat implementation of Javascript had more lulz per line than the script for Blazing Saddles. After the operation the doctor brought us in to the operating suite to see the results. (patients aren’t typically unconscious for this procedure, nor is the room surgical sterile)
The machine that was controlling the wire being used for the angioplasty was being controlled in turn by a Windows XP desktop. While the doctor was going over the results I noticed the Adobe Acrobat icon in the systems tray. When the doctor was done I asked if I could take a closer look at the results, “help yourself just don’t touch anything”. So I looked at the version of Acrobat and saw it was something in the 7.x series. Sorry doc I couldn’t help myself.
The doctor and I then had this exchange (I’m paraphrasing):
Me: “So I see you’ve got Acrobat on here, do you use this to view patient data?”
Doctor: “Oh yeah, if a case gets referred to us the common practice is that the patient will come with a CD on which there are test results we look at during the procedure.”
Me: “And this machine also controls the catheter?”
Doctor: “To a degree yes”
Me: “Tolerances here being very important?”
Doctor: “Yes, very.”
I had packed my CANVAS development laptop. Having something to distract you (and a mild sedative) while waiting for loved ones to get out of surgery is a plan I can’t endorse enough. We had a very reliable exploit for CVE-2007-5659 which I had previously tested to work for the exact version of Acrobat they were using.
With a bit of custom development work, here is your attack scenario:
- 1) Weaponize a legitimate PDF, repair memory such that Acrobat doesn’t crash out or reexec Acrobat on a benign PDF.
- 2) Escalate your way to Local System
- 3) Surgeons depend on the information provided to them by this machine to be exceedingly accurate, I could distort this data (how they are oriented in space for example) or just add a delay to the displayed image. Direct manipulation of the wire may have been possible.
I am very confident that this would lead to an accident involving a laser drill and the inside of your heart. Which is to say, a bad accident. Here are some other fun things I learned on that visit:
- 1) Some brands of portable vitals monitors have embedded webservers
- 2) To reduce potential tripping hazards, some medical gear uses wireless but only supports things like WEP and WPA1, it is a pain in the ass to type in complex keys on these devices
- 3) There are multiple LAN drops near every patient bed for the plugging in of the aforementioned devices
- 4) Automated pill dispensers are also typically networked (In my limited experience I have never seen one that wasn’t)
- 5) VNC is heavily used in a lot of hospitals
This is the result of what I saw with my eyes and some internet research, not any probing of the hospital network.
So for an investment of say, $250,000 in equipment and maybe $250,000 in exploit development costs (5 devs, 4 months, $50k per) you could have yourself an arsenal of reliable exploits that would allow you to do whatever you wanted on these machines. Your exploits would go a long way: hospitals don’t replace most equipment that often, there is a lot of common equipment between hospitals, I don’t know of any forensics firm that specializes in medical equipment though they may exist.
For half a million dollars you can buy yourself a infinitely reusable weapons system that’s hard to detect, hard to defend against, and allows for you to not even be in the same room as your target. People are right to worry about SCADA hacking causing industrial accidents but those sorts of things are always so, messy. Neat to think about.
In closing I’m going to recognize and dedicate this post and this blog to my Dad, who encouraged and helped me become the curious, sneaky and devious character I am today.
Correction: Friendly redditor sqrt7744 pointed out here that my initial idea of an attack vector was probably not viable. I maintain that putting a malicious PDF on a patient’s record CD that’s viewed in the OR is a bad thing, but the vector from PDF -> Death is not as clean cut (if it even exists) as I originally thought, though surely worth looking into. Also, sqrt7744 pointed out that the Syngress plot device about changing a blood type as also not likely viable, I can’t speak to hospital procedures so I don’t know how accurate that is.
Nerd Problems 
J. Oquendo said,
July 5, 2011 at 13:17
“So for an investment of say, $250,000 in equipment and maybe $250,000 in exploit development costs” Financialfail. I understand 100% where you’re coming from but the financials alone eliminate almost all of the typical players who I would equate associated with such a “kill tactic” (mobsters, dope dealers, etc.) I would even go as far as eliminating state sponsorship of such programs.
True that hospitals are a breeding ground for “pwnage” however, an aggressor would have to at some point be an insider. Most hospitals aren’t going to allow a random stranger into the building and allow that stranger to jack into a ethernet port to “do the do.” This counter statement comes via your: “There are multiple LAN drops near every patient bed for the plugging in of the aforementioned devices” Granted I’m almost sure one CAN do so (plug in), the likelihood is very low.
1) Sneak in or visit someone
2) “Jack in to the network”
a) you assume there isn’t NAC
b) you assume there isn’t NIDS
c) you assume you can find your target’s IP
d) all of the above
3) Assume you can manipulate data
a) PDFs might be locked for modification you’d need create a new one
b) Assume the doctor doesn’t have good old fashioned paper
c) Assume a second set of eyes or intuition doesn’t kick in: Dr: “That does not seem logical!” (while in surgery)
As to the wireless portion of the article, even if they are running XP, you still make assumptions:
1) Machine is exploitable
2) Machine is unpatched
3) Machine has no HIDS
It’s a nice article however, I honestly and sincerely have to throw this one into my FUD bookmarks to use for “spook marketing.”
JadedSecurity √ said,
July 22, 2011 at 04:18
I know of 20 hospitals in nyc, that will let you walk in unescorted to do the do.. and why do I keep bumpin into you?
Alex McGeorge said,
July 5, 2011 at 13:55
Thanks very much for your comments. Allow me to address a few of them.
Based on my observations on government spending, I would disagree with your assertion that the price tag removes state sponsorship from the table. I think $500k is a reasonable price tag to just see if something is possible, this is what R&D departments do.
Again based on my experiences and observations in hospitals, unless you’re wandering around in a surgical room or it’s 4 AM, I have never been stopped or questioned as to what I was doing. I will grant that I wasn’t walking down a hall way plugging into every ethernet jack I could find, but going into unoccupied rooms did not (at the time) seem to be a real problem.
You do bring up good points with regards to potential mitigating factors and defenses. My intention with this piece was not to provide a full proof plan for killing someone in a hospital and various methodologies for defeating defenses. I bring up other points of interest as exactly that, points of interest.
I do appreciate your comments, it is not my intention for this to come across as FUD and I regret that it has. I will need to pay more attention to my phrasing and examples in the future to avoid this.
J. Oquendo said,
July 5, 2011 at 14:37
Alex, your comments are eye opening, don’t get me wrong, maybe I SHOULD be the one to re-word my comments. I don’t disagree with you however, the whole scenario takes certain elements out of the equation.
Hospitals – at least the larger ones – are aware because of regulatory junk (HIPAA) that they should be doing more. Doesn’t mean they are, but it doesn’t mean they aren’t either. I had a discussion with someone in Yale New Haven about some of these same topics before when I asked: “Why the heck are you running W2K3?”
Sometimes, they cannot upgrade certain software because it would be either more expensive, or it would break something. Understandable, to my surprise when the person started briefly discussing compensating controls, etc. So *some* institutions are aware and some actually do the right thing.
So perhaps I need to do the double take here. Now, when it comes to gov sponsorship,granted it is peanuts (pricing) but its akin to throwing money in a bottomless pit. Farbeit easier to take another route to exploit a system 😉 E.g., medrecord targeting. Forget plugging into the wall, go straight to the source, its an almost concrete method to meet the objective.
Phil Brass said,
July 6, 2011 at 20:55
Yeah, having worked in healthcare IT and also done a few pentests against hospitals, I can say that security is not at the forefront of many hospital IT department priorities.
Hospitals have a lot of 3rd party gear in them, and it all needs to be supported. The way this works is that Vendor X has a small number of passwords for their gear, and they re-use them in all their hospitals. This applies to the big back-office systems, down to the smallest network-connected devices. So once you’ve broken into one pharmacy dispensing system, you probably won’t have too much trouble breaking into others.
Even when the perimeter isn’t a completely porous mess, and they have decent appsec and firewalls and stuff, the internal network is soft and chewy, more like a university network than a bank.
From my time supporting healthcare equipment in hospitals, I learned that you can stand in the middle of the ER or ICU wearing a suit and maybe holding a clipboard or a nice briefcase, and few people will question your right to be there. Probably just another vendor support guy, pharmaceutical sales guy, or any other suit-wearing non-patient-caring dork. This probably isn’t true in the OR, fortunately. But ER and ICU have plenty of high-risk patients.
As for identifying targets, anywhere with a decent naming convention or a well-cared-for directory server will practically map the network for you if you ask nicely. Look for the network with the cath carts, or the boxes named OR01-xyz.
In my experience, most hospitals do not have strong internal security controls. This kind of attack is plausible, I don’t know about the OR but definitely in other units, but only the most nihilistic, risk-tolerant attackers (with some knowledge of internal healthcare systems) would attempt it because it is murder and they do bad enough things to non-murderous hackers. This isn’t even a useful “cyber-warfare” technique, because warriors prefer to keep the enemy’s hospitals full, and if done on a mass scale this would just empty them out. It might be a plausible tool for assassination, but there are many other more reliable ways that don’t require all this R&D.