Automated drug cabinets have 1400+ critical vulns that will never be patched

Be careful what you wish for. There are vendors that care; but the ones that don’t can ship some amazing linux-based horrors. Kernel a zillion versions old based on the atrocious BSP from whatever SoC vendor was cheapest at the time? Check. Bunch of binary blobs so that even a fairly skilled linux wrangler couldn’t do much about this? Check. Basically all functions implemented either as ghastly CGI scripts on an ancient and known-vulnerable http server running as root; or a giant all-in-one blob(running as root, with one or more wildly insecure excuses for management or debug interfaces listening on random high number ports)? Oh hell yeah.

Really, once your vendor doesn’t give a damn not much will save you. Best case, in a situation where some degree of modularity is practical(as in this case, it would appear that the access-control GUI, the various sized cabinets, and probably the backend authentication and inventory system are logically separate systems, in order to allow various cabinet configurations and presumably integrated management of one or more supply rooms in a hospital facility) is that the interfaces between the modules are sufficiently standard (or nonstandard-but-well-understood-and-available-from-more-than-one-vendor quasi-standards) that you can rip out part of the system without having to throw away the whole thing.

Even if the software doesn’t rot, parts and maintenance for an EOLed product will dry up eventually; and there is precious little software in commercial service that is actually so flawless that it won’t need fixes.

(Apropos of the Linux thing specifically, I dealt with a bunch of HP thin clients at work at one point: HP, a company with its own UNIX line and pretensions to being an enterprise software and services provider, had taken fairly normal x86 Debian, albeit an older version, and brutalized it “What? Why shouldn’t the UI for establishing an RDP/ICA/X11 run as root?” until it was nearly unrecognizable. I spent ~18 months trying to find someone at HP who wouldn’t just transfer me to tier 1 tech support when I tried to report the pitiful little proof of concept attacks that were so obvious I could find them; and eventually just gave up. Happy times.)

2 Likes

That additional piece of information did not inspire confidence! Quite the opposite, in fact. :scream:

1 Like

Probably…in the sense of being an English term. Remember, I’m used to hosting German exchange students, and we always have fun comparing the BBC English they learned in school for how we speak here in the U.S. As they say: two nations separated by a common language.

1 Like

it’s not a problem - if an update breaks the HL7/ASTM/GDT interface only a few dozen to a few hundred blood or urine examination results have to be manually entered in the LIMS. totally reliable and the lab staff don’t minds at all!

3 Likes

How is it messily messy? It’s a maintenance cost (like 1400 holes in the roof.) I’m sure there’s some vertical tosh to heed, but you feed it to the CIO and see that she spins it back out as something usable to the business. Solver programs will be put to task. Previously solved problems and a small console of panic nudge buttons (TFA in place and all that) will be put about on schedule. There will be hunks on Github and other bits people just had to pipe through their particular contract stuff so Watson can print you how intensely well considered drinking a caffeinated phosphate was just that once (and charge 80 cents for a Coke.)

edit: wasn’t fun. sorry!

Oooh. You’re fun.

In many department stores, the cash was handled in a central office, and the sales staff sent cash via pneumatic tubes… (Or so I hear, they probably took out the last of those before my time.)

Okay, so (after the edit) your response is, just run it up the flag-poll, because the structures are set up to fix the problems?

Years ago we had one of these devices as DRM for software our company used. I needed it off-site, but it had to remain on-site for others. After watching the numbers change over time and seeing a pattern, I wrote a simple program to duplicate it. Of course, other keys would likely have other patterns.

Modern versions like RSA SecurID are better, but not stand-alone. They’re used in two-factor authentication where you still need regular passwords. This is a good thing, as the Chinese demonstrated:

Someone used a phishing attack to get an employee at RSA to open a spreadsheet containing malware. (Apparently a Flash app can be embedded in a spreadsheet cell.) With the information downloaded from RSA’s network, the Chinese were able to do what I did above for EVERY SecureID device.

Being just one part of two-factor authentication, that wasn’t enough to get them into systems. But using malware, phishing and social engineering methods to get people’s passwords, they were able to get into SecureID-protected systems at Lockheed Martin, Northrop Grumman and other defence contractors.

RSA sent out new SecureID devices to ALL their customers.

For what you propose to be secure, Facebook would have to sell their accounts to include those devices. And users would still have to use their own passwords in addition to the devices.

iirc it took them a long time to acknowlegde the wider problem and at first they said a token replacement is not needed

Aside from RSA’s pitiful response, the worst thing is that the whole episode could have been avoided if RSA had simply not retained the seed values or (shock, horror, let the customers initialize the fobs).

The mechanism used is actually pretty clever, in that it completely removes the need for any communication between the auth token and the server, unlike a CAC/PIV/SIM or anything else that uses certificates(start with a seed value, apply a transform to it every N seconds, the transform is designed such that you can reveal some of the result, what actually gets displayed on the screen, without allowing an attacker to infer future results with just access to past display data); but it does require that both the authentication server and the fob have clocks relatively close to one another, and that the server know each fob’s initialization time and seed value so that it can run the correct number of rounds and compare the result with what you type in. What is not at all necessary; but RSA did it anyway(hubristic incompetence or NSA escrow service?) is the vendor retaining the initialization values for all keys produced; making it such that anyone who cracked them could compute the display value of every RSA fob ever made at any point in its lifetime. That was…profoundly foolish at best.

On the plus side, at least their software is kind of flaky and their prices, even in quantity, for the little fob things are pretty usurious.

1 Like

Someone’s just got to figure out a way out of the stupid password stuff. It doesn’t work. I feel like two factor authentication could be better than forgetting the version of the thing I using this week and then using my “forgot my password” completely insecure questions about my dad’s uncle’s cat’s nickname.

2 Likes

I know people who went from using the same simple password for EVERYTHING, to using opposite, extreme - different messes of upper and lower case letter, numbers, symbols that HAD to be written down and/or stored in a plain text note in their cell phone.

Other than two factor authentication, I think the best practice is to drop the word “password”, and start using the word “pass phrase.”

1 Like

This topic was automatically closed after 5 days. New replies are no longer allowed.