STE WILLIAMS

Naked Security reader Ethan alerted us to a disappointing bug that was recently logged in NVD, the US National Vulnerability Database.

NVD is hosted at NIST, the US National Institute of Standards and Technology, and sponsored by the US Computer Emergency Readiness Team, better known as US-CERT.

If you remember when the R in CERT used to stand for “response,” you’ll realise just how much has changed in computer security in recent years.

Readiness is a much stronger position than responsiveness, because it presumes a proactive and preventative approach, not merely a reactive one.

To be fair, this bug is unlikely to bring the world to a network standstill, in contrast to the LOVE BUG virus about which we reminisced yesterday.

But it is a painful reminder that there are still vendors out there who have not embraced proactivity in security.

The vulnerability has been designated CVE-2015-3459, and it’s easily described:

Hospira Lifecare PCA infusion pump running “SW ver 412” does not require authentication for Telnet sessions, which allows remote attackers to gain root privileges via TCP port 23.

To explain.

PCA is short for patient-controlled analgesia, and if you’ve ever been lying in pain in a hospital well-equipped enough to afford PCAs, you’ve probably used one.

Instead of having a nurse come around every few hours and top you up with a shot of painkiller such as pethidine, the PCA device lets you administer the drug to yourself on demand, but with careful control over the rate of your maximum intake.

A programmable lock-out interval can be set so that you can only dose yourself every so often, from once every five minutes at the most, down to once every two hours.

So, you get a small but safe and steady trickle of a very useful but potentially dangerous drug that’s locked away in the bowels of the PCA device where it can’t easily be stolen, or misadministered, or overused.

That’s the device.

Telnet is a network protocol dating from the 1960s that pretty much gives you the equivalent of a serial console connection (where you plug a special cable into the back of the server), but across the network.

It used to be very widely used for remotely managing servers, because it lets you login from a distance, but you simply must not use it any more because it is completely unencrypted.

Anyone who can listen in on your network can log every keystroke you type, and everything that the server sends back, including your username and password if you use an interactive login.

That’s the protocol.

Now for the login security: on vulnerable Lifecare PCA devices, there isn’t any, because the telnet server in the device doesn’t require authentication at all.

When you connect to a server console, whether it’s via a serial cable or a virtual network terminal session, the server decides what program to run on its end of the connection.

Usually, that’s a system tool such as getty that sets up the connection, runs some sort of login validation tool, and then starts a command shell such as bash.

But for truly local logins, where you are assumed to have physical access to a console port on the device, or before the device is set up for the first time, telnet is sometimes uses as a sort of bootstrap tool that just connects you directly to a system shell without the login part.

And that’s what happens on an unpatched Lifecare PCA, except that unauthenticated, unencrypted logins via telnet are possible across the network even after the device has been set up for use and put into service.

That’s completely contra-indicated on a device that comes with “[r]obust wireless capabilities [that] enable remote drug library updates,” to quote its own literature.

What to do

If you’re a hospital IT administrator, you’ll want to get the latest post-412 version of Hospira’s PCA firmware and make sure it’s installed.

If you’re a system developer or a software tester:

• Don’t use a telnet, full stop. Use a protocol like SSH that supports encryption instead. There’s no reason to skip the encryption these days, even on modestly-powered hardware.
• Don’t allow unauthenticated remote access, except for a one-time connection to set up a device for the first time after a full hardware reset. Be sure to remove the unauthenticated service after configuration.
• Don’t allow remote logins as root. Use a tool such as sudo that requires users to login with their username and then promote themsleves to administrator, so you have accountability.
• Do a full-on network scan of your product, using a tool like nmap, before you let it out of quality assurance (QA). Don’t let attackers be the first to dig around to see what forgotten services are listening.

In short, CVE-2015-3459 is the sort of bug that shouldn’t have happened in the first place, because telnet shouldn’t have been there, even with authentication.

And it shouldn’t have been there in the second place, either, because an errant telnet server listening on TCP port 23 is easy to spot during testing.

Oh, and if you’re a developer and the QA guys say, “No” to your release candidate, don’t take it personally.

Take it as a compliment that they care enough about your code to look for things you forgot!

Follow @duckblog

Image of syringe courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/PFcuODHwzRE/