Pacemakers, defibrillators open to attack

Crims could send 830 volts straight to your heart


Pacemakers and implanted defibrillators are vulnerable to wireless attacks that could kill tens of thousands, says the security researcher best known for "jackpotting" an ATM on stage at the BlackHat security conference in Las Vegas in 2010.

The researcher in question, Barnaby Jack, today told the Ruxcon Breakpoint security conference in Melbourne, Australia that “the most obvious scenario would be a targeted attack against a high profile individual.”

Jack also warned of a worst-case scenario in which a worm could infect multiple devices, spreading from patient to patient, re-flashing the devices with malicious code as it foes. This code could be programmed to deliver fatal shocks to patients implanted with vulnerable implants at a scheduled time.

Such an attack would be possible because pacemakers possess a wireless interface designed to deliver telemetry and allow maintenance. But Jack, who works for US-based security company IOActive, has subverted security in that interface and showed delegates a video demonstration of a wireless attack against an Implantable Cardioverter-Defibrillator (ICD). "There's 830 volts going into the heart there, which is a bummer," he said as an audible zap played over the conference audio system.

Hacking the devices was too easy, Jack says. "There's no attempt to obfuscate or hide anything from a would-be attacker".

They key problem is the devices rely solely on the device's serial and device numbers for authentication. Unfortunately it's trivial to enumerate these numbers wirelessly, authenticate to the device and reprogram them with malicious code.

In addition to his much-publicised attacks against ATMs, Jack recently made headlines when he reverse engineered and exploited insulin pumps, but the issues identified in his latest research are grave; millions of people worldwide rely on pacemakers and ICDs.

Jack says medical device manufacturers should be held liable for vulnerabilities in their products. "I 100% agree that they should be held liable… removing liability from the manufacturers is ridiculous. It allows them to write shoddy code and have no consequences from it," he says.

In the meantime, he recommends a complete redesign of the devices' security model, starting with the introduction of encrypted communications between devices and transmitters and a "reasonable" authentication scheme.

Jack did not identify affected vendors and says he hopes to work with them to improve the devices' security. ®

Patrick Gray's Risky Business podcast will bring Reg readers special coverage of the Ruxcon Breakpoint conference.

Similar topics


Other stories you might like

  • Cisco warns of security holes in its security appliances
    Bugs potentially useful for rogue insiders, admin account hijackers

    Cisco has alerted customers to another four vulnerabilities in its products, including a high-severity flaw in its email and web security appliances. 

    The networking giant has issued a patch for that bug, tracked as CVE-2022-20664. The flaw is present in the web management interface of Cisco's Secure Email and Web Manager and Email Security Appliance in both the virtual and hardware appliances. Some earlier versions of both products, we note, have reached end of life, and so the manufacturer won't release fixes; it instead told customers to migrate to a newer version and dump the old.

    This bug received a 7.7 out of 10 CVSS severity score, and Cisco noted that its security team is not aware of any in-the-wild exploitation, so far. That said, given the speed of reverse engineering, that day is likely to come. 

    Continue reading
  • Google battles bots, puts Workspace admins on alert
    No security alert fatigue here

    Google has added API security tools and Workspace (formerly G-Suite) admin alerts about potentially risky configuration changes such as super admin passwords resets.

    The API capabilities – aptly named "Advanced API Security" – are built on top of Apigee, the API management platform that the web giant bought for $625 million six years ago.

    As API data makes up an increasing amount of internet traffic – Cloudflare says more than 50 percent of all of the traffic it processes is API based, and it's growing twice as fast as traditional web traffic – API security becomes more important to enterprises. Malicious actors can use API calls to bypass network security measures and connect directly to backend systems or launch DDoS attacks.

    Continue reading
  • Zero Trust: What does it actually mean – and why would you want it?
    'Narrow and specific access rights after authentication' wasn't catchy enough

    Systems Approach Since publishing our article and video on APIs, I’ve talked with a few people on the API topic, and one aspect that keeps coming up is the importance of security for APIs.

    In particular, I hear the term “zero trust” increasingly being applied to APIs, which led to the idea for this post. At the same time, I’ve also noticed what might be called a zero trust backlash, as it becomes apparent that you can’t wave a zero trust wand and instantly solve all your security concerns.

    Zero trust has been on my radar for almost a decade, as it was part of the environment that enabled network virtualization to take off. We’ve told that story briefly in our SDN book – the rise of microsegmentation as a widespread use-case was arguably the critical step that took network virtualization from a niche technology to the mainstream.

    Continue reading

Biting the hand that feeds IT © 1998–2022