Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Over 1,400 Vulnerabilities Found In Automated Medical Supply System 85

An anonymous reader writes: Security researchers have discovered 1,418 vulnerabilities in CareFusion's Pyxis SupplyStation system -- automated cabinets used to dispense medical supplies -- that are still being used in the healthcare and public health sectors in the US and around the world. The vulnerabilities can be exploited remotely by attackers with low skills, and exploits that target these vulnerabilities are publicly available. Things already seem to be getting out hand.
This discussion has been archived. No new comments can be posted.

Over 1,400 Vulnerabilities Found In Automated Medical Supply System

Comments Filter:
  • No surprise (Score:5, Insightful)

    by marcansoft ( 727665 ) <(hector) (at) (> on Wednesday March 30, 2016 @11:26AM (#51807633) Homepage

    Medical and healthcare companies consistently seem to have *no idea* whatsoever about security, and *no idea* that they actually need to hire someone who knows security.

    Anything with a computer in it needs to take into account security. If you're putting code into your product and don't know security and aren't hiring someone who does, you're doing it wrong. Medical devices, cars, even Bluetooth toilets. If it communicates with the outside world or is exposed to users who aren't authorized full control over the device, it needs security. If you don't do it, your product is a ticking time bomb waiting for a researcher, if you're lucky, or a malicious attacker, if you aren't, to notice the lack of security. This will keep happening until everyone gets the message.

    • by Salgak1 ( 20136 ) <salgak@speakeasy. n e t> on Wednesday March 30, 2016 @11:40AM (#51807743) Homepage

      . . . . year or two back, my oldest daughter entered a program to learn the "EPIC" medical records system. Now, admittedly, we're a geekhaus, my daughters were doing computers at age 5, and my youngest managed to hack the oldest by examining her browser cache at age 8.

      But she came back from the first day or two of training, shaking HER head. Not only was there no folder security, but, at least as configured there, every user was an admin.. Each of which could mess with another's files and account settings.

      Worse still, they were being trained at the site where the system was being hosted for production. No physical security. No backup power: in fact, zero redundancy whatsoever. And data backup ? "What's that ?"

      She wrote up a 2-page summary of problems SHE saw (and her training was in Medical Administration, although she DID learn Security from me. . .). She sends it to the POC at the Hospital the system was in the process of being installed for. . . .and the EPIC people dropped her from the course.

      There's a cherry on the top of this Sundae of Fail: she was eventually hired by the Hospital as, surprisingly enough, a Ward Medical Admin. And the IT Department comes to HER for help and suggestions. . . .

      • Does MUMPS even do security or does it need root / admin to run at all?

        • by Salgak1 ( 20136 )

          No clue. . . but as MUMPS is now 50 years old [], it's entirely possible that it was built without multi-user systems in mind. Looking at the basic description in Wikipedia, and perusing the Annotated MUMPS standard [], I don't even see provisions for accounts, much less security. . .

        • The original MUMPS started on VMS VAX computers. Security was baked into the operating system. Users ran in captive accounts restricted to application access. You could run multiple departments on one platform with restricted rights. The grandchild, CACHE now runs on UNIX and Windows as another back end database.

      • EPIC is like any other big system the base design sucks, no different than any big Oracle or SAS application.

      • by Anonymous Coward

        Well, EPIC is pretty evil. They also attempt to keep any of their ex-employees for working in the field.

      • by dmr001 ( 103373 )

        Epic is a big suite of applications that run on top of a big iron server - typically Unix (ours is AIX, I think). There's fine-grained user permissions in the application itself. End users do not have shell access or filesystem access or MUMPS prompt access, and everything has an audit trail. A select group of IT nerds get access to a text-based system running as a (Unix) application (with audit trails), and, at least at our organization, next to no one gets MUMPS prompt access or shell access. We have hot

        • by Anonymous Coward

          Meditech user here. Still uses MUMPS though.

          I can tell you for a fact that if you have access to their report writer you have access to MUMPS. Although the vendor has attempted to exclude access to the more "dangerous" functions (basically anything that is a write operation), their logic for doing so has some giant holes in it.

          This is, in a generic sense, the problem with a lot of these old systems. They don't have modern object or scoped security and what they do have has gaps in it. Gaps that can be e

    • At one time that was the case, but things are changing. These organizations have become well aware of what breaches can cost them from news related to the legal ramifications, and that's what finally gets people motivated to beef up security... the dollars at risk.

      The problem is exacerbated by the shoestring budgets that health care orgs run on these days, due to declining reimbursement, an increase in government as payor reimbursement models (but I repeat myself), and ever-increasing levels of unreimbursed

    • by Anonymous Coward
      If Jackie keeps stealing oxy from the Pyxis, Eddie's gonna get fired and they're going to replace it with a Pill-o-matix.
  • Things already seem to be getting out hands.

    Getting or giving? Big difference.

    On a completely unrelated note, I could use a hand.

    • "The vulnerabilities can be exploited remotely by attackers with low skills"

      This also applies to the editors, for whom apparently the ability to edit text into something coherent in the English language is only a soft requirement.

  • by bigdady92 ( 635263 ) on Wednesday March 30, 2016 @11:30AM (#51807661) Homepage
    No Shit sherlock.

    Windows XP and Windows 2003 systems are prone to all sorts of horrible security flaws. Reading the Fucking Article I see that the newer, non EOL, equipment isn't prone to any of these problems.

    I wonder how many vulnerabilities are in older Cisco routers that haven't been patched since 2007?
    • by aaarrrgggh ( 9205 ) on Wednesday March 30, 2016 @11:38AM (#51807721)

      The bulk attacks that are likely enabled by XP/2003 I would agree with you on. However, they are representative of many other problems with brand new Pyxis units from what I hear. The unspoken word seems to be that it is still less vulnerable than the traditional human-centric supply systems. The typical solution is defense in depth, with a key-code door lock to the room and a camera in the room-- so things can be tracked by belt and suspenders in a failure/attack.

      • by Anonymous Coward

        These things sit in the hallways on every floor in my hospital.

        • For sterile products or drugs?

          Who really cares about sterile products...

        • That's not exactly the best design. There are a lot of ways around the problem - you put them in nurses' stations where the likelihood of someone observing an intruder is very high, you put cameras on the area, you limit accounts from being able to dispense meds when outside their proper work area, you put them on a separate network. I'm an anesthesiologist. If I need to get into a drug dispensing machine I need to get into it right the hell now, but my login only works in the operating rooms and the obste
      • ++++


        Nothing is going to be inherently secure in the medical field. Too many people need to get at information / equipment / supplies. You will have breaches.

        For a Pyxis-type system you need to be able to see if someone is shortchanging the loading of the drug or taking out drugs where they shouldn't. You also need to ensure basic database integrity (surprisingly the vendors don't seem to think much of this concept). These machines don't control anything else and don't have much patient information

        • by plover ( 150551 )

          Sure, you need to audit the systems (as the anesthesiologist pointed out above, he believes he could siphon 10% of his prescriptions without notice.) But the human side isn't the security issue here. Any automated dispensing system is going to need auditing of the inventory, regardless of how "digitally secure" the appliance is, because it's full of really valuable drugs.

          The real problems at stake are access when it's needed; and integrity that the drug dispensed is the drug prescribed in the correct quan

    • I wonder how many vulnerabilities are in older Cisco routers that haven't been patched since 2007?


  • by ranton ( 36917 ) on Wednesday March 30, 2016 @11:32AM (#51807679)

    I worked at a competitor of Pyxis who created similar automated drug dispensing cabinets, and the market research at the time was that they all were pretty insecure. When I left my company they were dealing with a defect where anyone with a screwdriver could bypass the locking mechanism of our newest model (meant for the area where the schedule 2 drugs were kept).

    At the time (almost 10 years ago) these devices were meant to help with inventory management, not to be ultra-secure safes. Anyone with even moderate training using these devices could steal drugs if they wanted. Most thieves were caught only because of the sheer volume of drugs they stole over months or even years.

    • by tnk1 ( 899206 ) on Wednesday March 30, 2016 @11:45AM (#51807801)

      I think that's the major issue with medical IT and computing in general. The products are designed to do something, and security is an afterthought. That's made worse because many of the products were designed a long time ago and not updated for various reasons, including a long regulatory approval process to get them to market.

      So you have a supply cabinet that was designed to help with inventory, but now we expect it to be a safe. And the network infrastructure that probably grew ad hoc in the hospitals was just meant to enable interconnection and security only became an eventual concern as attacker capabilities grew. Because the product cycle is so long for medical purposes, they don't react in a timely way to anything, especially something that is not the primary concern of the equipment that is being deployed. So now you have this issue.

      I don't think this is a permanent problem for hospitals, but there will be some sacrificial lambs before the process changes. Once those cases are over, there will be more money put into security at those places.

      Unfortunately, it's just another thing that is likely to raise the cost of medical care because they will continue to be bad at it, but now they'll be trying to compensate for their incompetence by overpaying for security products and services.

  • "The vulnerabilities can be exploited remotely by attackers with low skills"

    Then what the f**k are these devices doing even directly connected to the public Internet?
    • ...what the f**k are these devices doing even directly connected to the public Internet?

      Dispensing drugs to script kiddies?

    • by plover ( 150551 )

      Then what the f**k are these devices doing even directly connected to the public Internet?

      I'm not aware of any such devices being directly connected to the public internet. But, they're on a hospital or pharmacy's internal network, and those networks almost always have direct access to the Internet.

      Hospital network admins have a thankless job. They have to secure their networks against all this kind of crap, but every time they lock down some terrible gaping security hole, the doctors scream "I need this Ultrasound machine to send PDFs to my office! You can't disable the FTP function or close

  • This is why I don't feel like my expertise is a frivolous cost, no matter how many times corporations try to tell me that.
  • by JustAnotherOldGuy ( 4145623 ) on Wednesday March 30, 2016 @12:28PM (#51808219)

    I don't know about you, but I'd be proud as hell if I'd managed to write an application that had 1400+ vulnerabilities.

    It must have taken a lot of work and testing to make sure it was that porous and vulnerable. I mean, just think of all the work involved in taking out all of the bounds checking, sanity tests, input validation, error checking, etc etc.

    IF ($INPUT){

  • Pyxis (& similar supply cabinets) were primarily concerned with keeping unauthorized staff from taking prescription drugs from the cabinets and properly documenting the authorized clinicians who did access drugs.

    From what I've heard hear in this post, it seems security mostly stopped at that level of clinician access limitations.

  • by jasnw ( 1913892 ) on Wednesday March 30, 2016 @02:10PM (#51809183)
    I've seen this problem in many organizations run by people who consider themselves to be in a "profession" like doctors, lawyers, and to a varied extent anyone with a non-computer PhD. The attitude seems to be that "I am smart, so I can figure this out without paying someone who knows what they're doing, and I'll do a better and less expensive job." This applies to many aspects of running an organization, with IT and finance/budget being two very egregious areas. I've seen many a small R&D company fail because its principle owners/operators try to do the finance/budget side after the company has become larger than a couple of people, and lots of computer security issues in companies where this "we can do it all" attitude holds sway. They can't quite see that people pay them for their expertise, so why should they balk at paying other people for expertise they don't themselves have. I've been expecting a security meltdown at hospitals and medical facilities ever since the big money pushed in a few years ago by the Government to drag medical IT into at least the last decade of the 20th century. This will be quite the roller-coaster ride.
    • Good Point... I helped a Lawyer friend upgrade his systems. He didn't want an in-house IT person, so I strongly recommended the cloud based solution. One of his practice partners had too much regulated and sensitive data to move to the cloud (I warned them about the common practice of cloud vendors with their contracts which absolve the cloud vendor of nearly all accountability...) That contract had so many red lines by the time they were done it was funny.

  • Apparently "security researchers" now means "anybody who can run a Nessus scan. I am disappointed.
  • CRAP... I don't want to clean up the mess when somebody does a knee jerk reaction and jumps first (without looking at downstream dependencies)

This process can check if this value is zero, and if it is, it does something child-like. -- Forbes Burkowski, CS 454, University of Washington