Can I drop a pacemaker 0day?

Call up CNN and offer to demonstrate how BIOTRONIC is so evil that they refuse to fix their pacemakers. Hook it up to an ECG and use your phone to make it flatline. Then turn to the camera and tell the audience, "because BIOTRONIC doesn't want to pay to fix their product, I can now kill your grandmother just by walking past her on the street."

Watch how long it takes them to fix it then, and watch how reactive they become to responsible disclosure next time.

Also, short their stock before you go on TV. A little something for your troubles.

This is the most important problem that the internet of things faces. How can we network everything while maintaining at least some scrap of security, especially in the long term? How can we convince people that their toaster is worth patching, and, more importantly, how to we convince vendors that toasters are worth releasing patches for? What if appliance makers go bankrupt and your dishwasher no longer receives patches? How will devices be updated if another Heartbleed-esque situation occurs? It's easier for a user to protect themselves from a 0-day in an app they use, for example, compared to vital home appliances such as dishwashers, refrigerators or washing machines, which cannot merely be uninstalled.

This is a very real threat, most notably Belkin [0] has suffered critical security breaches, and this issue won't be going away any time soon. How can security researchers get CVE's patched, and how can we prevent them from occuring in the first place? This should be priority #1 for any company trying to bring internet-connected appliances to the mainstream.

[0]: http://arstechnica.com/security/2014/02/password-leak-in-wem...

Absolutely NOT because this could kill people.

If you truly have a pacemaker 0day, contact me (joelparkerhenderson) on most major service and I will connect you with my healthcare policy lawyer. She can rapidly open the doors to the vendors who have the risk.

Here's an idea:

1.) Responsible disclosure to vendor. Allow reasonable amount of time for a fix to be created and deployed.

2.) (If fix is deployed, release details)

3.) If no fix is deployed in a reasonable amount of time and the vendor is unresponsive, release a PoC that demonstrates exploitability without giving away details. eg: "Here is a pacemaker. Look, I did magic and it stopped!" This is the same idea as releasing the actual vulnerability/exploit, but doesn't put lives at risk. People that could fuzz for any type of a vulnerability would be able to find it on their own anyway.

I agree that ICS and health-sensitive vulnerability disclosure is a trickier field than most. Medical devices, cars, and power plants are much more sensitive than a random kid's iPhone; that's why groups like I Am The Cavalry are trying to address the issue industry-wide.

However, to answer the original question: don't drop a pacemaker 0day at DEF CON. Find a way to fix the problem with the vendor instead. At the very "worst," demo without vulnerability or exploit details.

- Contact the FDA, or other regulatory bodies.

- Contact the customers. They'll likely have standing to sue (they were sold a defective product).

- Class-action attorneys may be interested for this reason.

- Did you know you can pay a very, very modest amount of money to file a press release saying anything you want?

- Contact some investors. Short sellers will have a vested interest in making sure the information gets widely publicised.

This sort of 0-day has been known in the academic literature for some time[1].

Disclosure of critical vulnerabilities in implantable devices is far more fraught than your normal critical software 0-day. These devices require surgery for replacement, and a small number of those surgeries will have possibly fatal complications. The cost of immediately replacing all existing vulnerable devices could literally be measured in lives. (And that's even assuming that the device manufacturer fixed the problem!)

Implantable software is already a very tricky area, and there's no signs that it'll get any easier.

[1] Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses, http://www.secure-medicine.org/public/publications/icd-study...

It's not quite "this could kill people" but rather "this could be used to kill someone." But there are a lot of things that one person could use against another person to kill them, ethically, what does adding this thing to the list change?

If you discovered / disclosed a particular way the unit could malfunction and kill someone it seems like that's put in a different class; in that case you're a hero saving lives. But if you report on a technique someone could use to cause the device to malfunction, it's treated completely differently.

I think a related and important message is that pacemaker "malfunctions" should be treated as possibly suspicious.

How about releasing the vulnerability in stages? The author jumps from unresponsive vendor to releasing exploit code. What if you add steps between the two?

For example:

- Announcing a vulnerability has been found and identifying the unresponsive vendor.

- Announcing what the disclosure timeline will be.

- Detailing the product lines known to be affected by the vulnerability.

- Publishing communication with the vendor so far with any details about the vulnerability redacted.

- Private disclosure to professionals (doctors & journalists) to have them independently verify that the vulnerability exists and help with raising awareness.

- Full details about the vulnerability, but no exploit code.

What pacemaker communicates via blue tooth? Last I checked they all used induction telemetry (which requires the telemetry wand to be within several inches of the device) or MICS band radio for distance telemetry. I think some Boston Scientific devices used 900MHz at one time, but how many of those are still in the wild?

The only instances of "hacking" a pacemaker (or ICD) have been when researchers used a programmer from the manufacturer to "hack" the device.

So it seems super unlikely you know a blue tooth zero day for a pacer.

What do you expect them to do? Even assuming they were 100% concerned with security and did everything right and there was still a bug that allowed a pacemaker to be compromised. Do you expect them to cut open a person and replace the buggy pacemaker?

I don't pretend to be an expert in this area but getting medical equipment approved is a huge undertaking and I don't know what the ramifications of changing anything would be. Say they take your 0day and fix it. Then they have to go through the entire re-certification process again and after however many months or years, NEW patients get the fixed pacemaker. But what about all the old patients?

While I sympathize, the only realistic approach here is to make the consequences for killing someone via a 0day for the "lulz" so drastic that it would certainly legally bleed over into the disclosure. I realize this is the approach we do tend to take here in the US.

In the case of medical devices, this is squarely in the FDA's wheelhouse in the USA. The FDA likely lacks the people with appropriate expertise to evaluate these kinds of safety issues because their traditional focus has been on the more typical kinds of medical device risk. A concerted effort at dialog with them could turn that around. Particularly if it were done through a series of academic workshops with key people.

Make a YouTube video of the hack actually working on a pacemaker (preferably one that is not in a person). Show how it can be executed from a smart phone while walking down the street or sitting at Starbucks.

Send that to the company and the media. You are best off also showing documentation that you told the offending company multiple times.

Show don't tell.

"The problem is that dropping a pacemaker 0day is so horrific that most people would readily agree it should be outlawed. But, at the same time, without the threat of 0day, vendors will ignore the problem."

If this is the case, then wouldn't the same most-people (if made aware of the issue) also agree that it should be illegal for a company's management to ignore life-threatening software flaws in their products after being notified?

I mean illegal as in reckless endangerment or manslaughter, not illegal as in lawsuits and golden parachutes.

And so it begins. I was wondering when we'd finally start seeing the InfoSec guys get to this. The more recent stuff branching into CAN on cars and before that SCADA systems seemed to be the last sort of stepping stone from a traditional PC network to the internet of things networks.

I'm sort of glad, in a twisted way, that this has finally happened. Better the light get cast on this now than in a few years once the criminal(/nation-state...) equivalents have had time to go through it themselves.

I remember reading that Cheney had them remove all wireless functionality from his pacemaker because they were afraid of the potential of someone using it for assassination.[1]

[1]http://abcnews.go.com/US/vice-president-dick-cheney-feared-p...

EDIT: Also, no you shouldn't release a pacemaker 0day. As others have said, expose it without releasing details. Makes for a nice demo.

I think that there are a lot of ways to approach this. The Heartbleed disclosure was very well done and has a lot of lessons, perhaps there's something to learn from that.

Personally, I think it's completely unacceptable the way many technologies critical to keeping people alive are so vulnerable. Especially if the vulnerabilities are as widespread as the article suggests (30%!), find a list of 10-20 that vary in importance. List all the products, and list the consequences of each vulnerability.

Then start dropping 0-days one at a time until the industry realizes you are serious. Start with the less severe ones, but if the pacemaker vulnerability hasn't been addressed after a few months of weekly vulnerability releases, don't hold back. The more publicity you can get the more likely a company is to patch vulnerabilities.

If _teenagers_ are capable finding vulnerabilities that can end lives using a script they downloaded online, then we need to be ready to take drastic action. The industry is in a terrible state and we aren't safe, and decreasingly so as these gaping holes continue to sit there and be discovered.

This is an incredibly sensational piece. All of the sane suggestions are dismissed as "doesn't work" by giving one example where it didn't work. It's not that easy - going to the media won't solve the problem 100% of the time but it sure as hell would if it were a life and death 0day and wasn't fixed with urgency.

Don't even get me started about the Nazi analogy...

If it’s an obvious vulnerability, is there value in withholding the details? There is a strong case to be made for the argument that the people who would be willing to use such a 0day maliciously (sociopaths) would find it anyway.

It could potentially also depend on how easily the vulnerability can be patched—one that can be patched remotely can be dealt with much more rapidly than one that will require surgery to replace the device. If one assumes that full disclosure will lead to the fixing of the issue, the first class is probably closer to being judged “responsible” than the second.

It is certainly a difficult dilemma. The correct answer can only be known with the benefit of hindsight…

When there is a flaw in a car seat or child's toy everyone flips shit and recalls start happening. It's covered on the local news and all that. Why doesn't that happen for pace makers? Isn't this a problem for the Consumer Product Safety Commission or the FDA?

It's a product that has a flaw. Seems like it qualifies for a public recall.

I don't understand why there is such a debate here. I would absolutely disclose the 0-day if the manufacturer was unresponsive (given sufficient warning, of course). Moreover, if anyone died, I wouldn't feel the least bit guilty about that - the guilt rests firmly on the manufacturer and the individuals who choose to use the exploit.

After all, black-market exploits will come, and people will die, whether you disclose the vulnerability or not. At least with disclosure, the innocent have a chance to protect themselves.

You must weigh the lives lost to silence against the lives lost to disclosure. We practice disclosure in all other areas of computer security because we have seen the cost of silence too many times. There is no reason it should be different here.

Disclosure saves lives.

This is clearly something where a regulatory agency that can and will apply penalties to manufacturers that do not fix bugs that are physically possible to fix without ill effect in a timely manner is appropriate. You simply report to that agency.

These problems are serious enough that failing fast and hard is not a good way to go about it. This is software meets physical reality. In software land, we've developed radically different approaches to engineering problems because of the incredibly cheap costs. This is one place where we have to borrow from other disciplines that have more experience with safety issues.

Solution I find is relatively simple from a moral standpoint. Exhaust all options. Instead of saying 'ah it won't work', just do it anyway, contact anyone and everyone , privately related to this, about this and do everything you possibly can before press exposure. With the press you can demonstrate but not release the actual steps to how it's done. If it is still denied as fake or ignored despite all of that, release it if you feel the moral obligation to do so. 'You must do what you think is right, of course'.

Of course, don't publicize it.

But consider a though experiment: From a security perspective, does it really increase risk? There are many ways to kill someone that are much simpler than figuring out what pacemaker they have, finding a 0day, designing an attack and implementing it. This vulnerability doesn't necessarily increase the risk that someone will be murdered.

EDIT: Or if you want to attack the pacemaker, use radiation from microwaves or similar devices. At least according to signs posted in many places, they are dangerous to users of pacemakers.

There seems to be this idea embedded in human minds that there is a group of people who are just waiting to kill someone, and the fact that they have not yet found a way of doing it is the only thing preventing them from doing so. As soon as you show them that you can do it by hacking a pacemaker, they will go ahead and do it.

There is no shortage of methods of killing someone or inflicting bodily harm. As far as moral culpability, showing how a 0day exploit can be used to kill a person is akin to saying that you can use arsenic to kill grandma.

relevant: "It’s Insanely Easy to Hack Hospital Equipment" (wired.com)

[article]: http://www.wired.com/2014/04/hospital-equipment-vulnerable/

[hn thread]: https://news.ycombinator.com/item?id=7684291

Of course you can. Executing this type of attack would be more technically complex then executing a plain old murder, with say a simple gun.

Notify the manufacturer's products liability insurer through a respectable and concerned PI lawyer. Action will be swift.

Ideally, there would be some way to disclose this kind of info to whatever government regulatory agency is responsible for approving these things. In your situation, you have to worry that whoever you disclose this to is going to act irrationally, and governments exist to mediate between irrational actors for the benefit of the public.

Wasn't Barnaby Jack going to unveil a Pace Maker 0day last year before he [mysteriously] died?

Drop the 0day. I'd say Anonymously, but not necessarily. If its an obvious bug, this isn't a moral issue at all. Had it been a multi stage, complicated exploit (hard to find and implement), I would suggest otherwise. In this case its a no brainer IMHO.

@fiatmoney's comment seems like very good advice. Here's a link since it's very far below the fold:

https://news.ycombinator.com/item?id=7849734

I think that unless you want to carry the burden of possible assassinations that you could have stopped, you have to disclose the vulnerability ASAP. In order to avoid legal vendettas, I recommend to do it anonymously.

Pacemakers have a remote exploit bug ? If you can get this close to my heart, you might as well stick a knife in it. The only difference is the one will look like a failed pacemaker and the other will look like murder.

I suppose Heartbreak Bug would be an awfully appropriate name for one.

Write a script for CSI or one of these police procedural shows.

Warn the CDC of an impending health issue and include very specific details or the at risk group and the transmission vector.

Anonymously do what you think is right.

It would be interesting if someone created a payload that patches exploited device.

The ONLY people who need to know about this is the manufacturer and their regulatory body FDA, etc.

The company can then pull all the inventory that is in and out of the patients and apply fixes or facilitate replacements.

If this could kill people, I'd hope the above ideas would be obvious...but well I know they won't be to everyone.

Is there any secure way to update a pacemaker's software without surgery?

Contact the surgeons who implant them and demonstrate to them.

was really sketchy when it happened on homeland

http://vimeo.com/63176830

Where is the landing page and scary logo ?

You can play moral white hat hacker when you are disclosing vulns in some shitty Chinese router, or participating in one of bug bounty programs, but NOT when you play against big boys (AT&T, MBTA, Juniper, Adobe, etc). You will get crushed, jailed and humiliated.

Disclose fully, but anonymously.

I call BS.

How does an ECM (or anti-lock brake controller) "slam on the brakes"?

I would snap insta do it for the fame and future business opportunities alone.