GE Puts Default Password In Radiology Devices, Leaving Healthcare Networks Exposed 40
An anonymous reader quotes a report from Ars Technica: Dozens of radiology products from GE Healthcare contain a critical vulnerability that threatens the networks of hospitals and other health providers that use the devices, officials from the US government and a private security firm said on Tuesday. The devices -- used for CT scans, MRIs, X-Rays, mammograms, ultrasounds, and positron emission tomography -- use a default password to receive regular maintenance. The passwords are available to anyone who knows where on the Internet to look. A lack of proper access restrictions allows the devices to connect to malicious servers rather than only those designated by GE Healthcare. Attackers can exploit these shortcomings by abusing the maintenance protocols to access the devices. From there, the attackers can execute malicious code or view or modify patient data stored on the device or the hospital or healthcare provider servers.
Aggravating matters, customers can't fix the vulnerability themselves. Instead, they must request that the GE Healthcare support team change the credentials. Customers who don't make such a request will continue to rely on the default password. Eventually, the device manufacturer will provide patches and additional information. The flaw has a CVSS severity rating of 9.8 out of 10 because of the impact of the vulnerability combined with the ease of exploiting it. Security firm CyberMDX discovered the vulnerability and privately reported it to the manufacturer in May. The US Cyber Security and Infrastructure Security Agency is advising affected healthcare providers to take mitigation steps as soon as possible. In a statement, GE Healthcare officials wrote: "We are not aware of any unauthorized access to data or incident where this potential vulnerability has been exploited in a clinical situation. We have conducted a full risk assessment and concluded that there is no patient safety concern. Maintaining the safety, quality, and security of our devices is our highest priority. We are providing on-site assistance to ensure credentials are changed properly and confirm proper configuration of the product firewall. Additionally, we are advising the facilities where these devices are located to follow network management and security best practices."
Aggravating matters, customers can't fix the vulnerability themselves. Instead, they must request that the GE Healthcare support team change the credentials. Customers who don't make such a request will continue to rely on the default password. Eventually, the device manufacturer will provide patches and additional information. The flaw has a CVSS severity rating of 9.8 out of 10 because of the impact of the vulnerability combined with the ease of exploiting it. Security firm CyberMDX discovered the vulnerability and privately reported it to the manufacturer in May. The US Cyber Security and Infrastructure Security Agency is advising affected healthcare providers to take mitigation steps as soon as possible. In a statement, GE Healthcare officials wrote: "We are not aware of any unauthorized access to data or incident where this potential vulnerability has been exploited in a clinical situation. We have conducted a full risk assessment and concluded that there is no patient safety concern. Maintaining the safety, quality, and security of our devices is our highest priority. We are providing on-site assistance to ensure credentials are changed properly and confirm proper configuration of the product firewall. Additionally, we are advising the facilities where these devices are located to follow network management and security best practices."
A modest proposal. (Score:2)
Re:A modest proposal. (Score:5, Informative)
The passwords are available to anyone who knows where on the Internet to look.
Slashdotters don't waste their time 'looking on the internet', they wanna be spoon-fed their kompromat!
Thus...
GE Healthcare Centricity Clinical Archive Audit Trail Repository has a default password of initinit for the (1) SSL key manager and (2) server keystore; (3) keystore_password for the server truststore; and atna for the (4) primary storage database and (5) archive storage database, which has unspecified impact and attack vectors.
GE Healthcare Precision THUNIS-800+ has a default password of (1) 1973 for the factory default System Utilities menu, (2) TH8740 for installation using TH8740_122_Setup.exe, (3) hrml for "Setup and Activation" using DSASetup, and (4) an empty string for Shutter Configuration, which has unspecified impact and attack vectors. NOTE: since these passwords appear to be used to access functionality during installation, this issue might not cross privilege boundaries and might not be a vulnerability.
GE Healthcare Discovery XR656 and XR656 G2 has a password of (1) 2getin for the insite user, (2) 4$xray for the xruser user, and (3) #superxr for the root user, which has unspecified impact and attack vectors. NOTE: it is not clear whether these passwords are default, hardcoded, or dependent on another system or product that requires a fixed value.
GE Healthcare Centricity PACS Workstation 4.0 and 4.0.1 has a password of (1) CANal1 for the Administrator user and (2) iis for the IIS user, which has unspecified impact and attack vectors related to TimbuktuPro. NOTE: it is not clear whether this password is default, hardcoded, or dependent on another system or product that requires it.
The Ad Hoc Reporting feature in GE Healthcare Centricity DMS 4.2 has a password of Never!Mind for the Administrator user, which has unspecified impact and attack vectors. NOTE: it is not clear whether this password is default, hardcoded, or dependent on another system or product that requires a fixed value.
GE Healthcare Discovery NM 750b has a password of 2getin for the insite account for (1) Telnet and (2) FTP, which has unspecified impact and attack vectors. NOTE: it is not clear whether this password is default, hardcoded, or dependent on another system or product that requires a fixed value.
GE Healthcare Centricity PACS Workstation 4.0 and 4.0.1 has a password of ddpadmin for the ddpadmin user, which has unspecified impact and attack vectors. NOTE: it is not clear whether this password is default, hardcoded, or dependent on another system or product that requires a fixed value.
GE Healthcare Centricity PACS Workstation 4.0 and 4.0.1, and Server 4.0, has a password of 2charGE for the geservice account, which has unspecified impact and attack vectors related to TimbuktuPro. NOTE: it is not clear whether this password is default, hardcoded, or dependent on another system or product that requires it.
GE Healthcare Centricity PACS 4.0 Server has a default password of (1) nasro for the nasro (ReadOnly) user and (2) nasrw for the nasrw (Read/Write) user, which has unspecified impact and attack vectors.
GE Healthcare Precision MPi has a password of (1) orion for the serviceapp user, (2) orion for the clinical operator user, and (3) PlatinumOne for the administrator user, which has unspecified impact and attack vectors. NOTE: it is not clear whether these passwords are default, hardcoded, or dependent on another system or product that requires a fixed value.
The TeraRecon server, as used in GE Healthcare Centricity PACS-IW 3.7.3.7, 3.7.3.8, and possibly other versions, has a password of (1) shared for the shared user and (2) scan for the scan user, which has unspecified impact and attack vectors. NOTE: it is not clear whether this password is default, hardcoded, or dependent on another system or product that requires a fixed value.
GE Healthcare Centricity PACS-IW 3.7.3.7, 3.7.3.8, and
Re: (Score:2)
Re: (Score:2)
That's not uncommon...
It won't save anything either, managed service providers typically give lowball quotes and then make up for it with extra fees for things not covered by the initial contract.
Re: (Score:2)
Re: (Score:2)
Put the developers in jail.
I have a better proposal: put the upper management in jail.
A chain of command/responsibility should work both ways.
Re: (Score:2)
Put the developers in jail.
And their managers.
Re: (Score:2)
Years ago I worked on an embedded system with this kind of maintenance password setup. The developers knew it was a bad idea, management knew it was a bad idea, but damn it customers thought it was the best magic since unicorn farts when we could remotely fix or update systems and get them back up and running with minimal downtime. Make it more secure and they start complaining about how bad our service was and tell all the other buyers how terrible our systems had gotten.
Re: (Score:1)
Could you use a unique password or even TOTP for the remote service logon on a per-customer basis?
Either tie it to the customer account (you're calling from what company?) or to a serial number written indelibly on the side of the device...
It sounds like you had to figure out the IP address to initiate the remote connection, so adding a serial number to the mix wouldn't be the worst.
Or am I missing something?
Good times! (Score:4, Interesting)
Re:Good times! (Score:4, Insightful)
No this sounds kind worse in terms of negligence, hopefully not in terms of cost to human life.
The people behind the Therac-25 were simply working out of their depth and did not understand issues like concurrency. Yes they removed physical interlocks designed to prevent human error that had been built in to previous manually controlled equipment because "computers don't make mistakes" an other naive assumption from the early era of mini/micro computing.
Here we see all sorts of fancy security provisions and fancy encryption that no doubt was expensive to implement, test, get approval for only for someone to undermine all the value by doing something stupid and creating a static credential vulnerability that undoes all the security of the entire system; and given all those components involved, that person absolutely knew better and did not care! The people who did the code reviews and signed off on the firmware commits, also knew better but did not care enough to hold the process up and get the issue fixed. This is some esoteric threading bug, this one obvious anyone who knows what a keystore is knows you don't use the same static password on every unit you are going to sell. FFS even the cheapo SOHO router guys manage per device passwords and everyone knows it. ..
Re: (Score:2)
Re: (Score:2)
it was the closest analogue involving incompetence in close proximity to ionizing radiation that I could come up with off the top of my head.
alright, that is fair!
Re: (Score:2)
Guys guys guys, this is Slashdot, not a place for civil discussion!
Re: (Score:2)
shut the fuck up you mewling SJW degenerate. civility is literally censorship and worse than rape.
Re: (Score:2)
Why are you bringing Slack Jawed Whites into this?
Re: (Score:2)
can't do OS updates or change passwords? (Score:3)
can't do OS updates or change passwords? 3RD party vendors have way to much control!
Re: (Score:2, Interesting)
These are FDA-controlled devices. They're typically running Linux 2.6, Windows XP/7 and any changes void their warranty. They're also recommended to be put behind firewalls and can only be accessed by VPN/VLAN - IF the hospitals properly configure their network.
The problem is that management could make inadvertent changes to the software, with potentially disastrous effects (giving everyone radiation poisoning because you needed Windows 10 + McAfee on there)
Re: (Score:3)
These are FDA-controlled devices. They're typically running Linux 2.6, Windows XP/7 and any changes void their warranty. They're also recommended to be put behind firewalls and can only be accessed by VPN/VLAN - IF the hospitals properly configure their network.
The problem is that management could make inadvertent changes to the software, with potentially disastrous effects (giving everyone radiation poisoning because you needed Windows 10 + McAfee on there)
I used to work in this space for many years and that is not precisely true. We are talking about two different regulatory regimes: Clinical information systems, which store, retrieve, process, and display medical records; and medical devices, which actually deliver treatment, perform diagnostic tests, or capture telemetry. The FDA oversees both, but there is a much lighter touch for CIS. For example, the MRI that does the imaging and the workstation that sends it commands and receives the images would com
There's a nuance here.. (Score:1)
It's not that "any changes" void their warranty, but if the software is upgraded or patched, it'll have to go through the FDA Certification process again.
There's nothing to prevent the healthcare IS group managing the devices to change the hardcoded passwords. And I define hardcoded as the passwords which are set at the factory (aka default passwords).
This was actually a discussion topic at one of the 2016 Blackhat panels regarding medical devices and securing public infrastructure where they had folks fro
Re: (Score:1)
You CAN change the password, but on more modern system, they are simply reverted back the next day. Most of GE/Siemens controllers are now using a DeepFreeze-type product for "security" so that if they do end up getting infected, they simply reboot and revert the system to a factory state.
Re: (Score:2)
Old News (Score:2)
This is old news. Really old news. It's been this way for well over a decade, and I'd be shocked if most of the other manufacturers of medical equipment didn't have the very same issue.
This is inertia from before gigabit networks were common. If you look at any of the older MRI machines for example, they were originally designed to write the scan to a DVD that would be put in the patient's file, because cramming 3-8 gb images across a 10 megabit network is a recipe for disaster and would have eaten every
Re:Old News (Score:4, Interesting)
Re: (Score:2)
I've seen a lot of people complaining because this hardware often relies on WinXP or even Win2K and can't be upgraded. When someone spends a couple million on a piece of hardware they can't just toss it because the OS is no longer supported. IT departments need to cordon it off in its own protected area, but unfortunately a lot of them don't have people competent to do that and still maintain the functionality because healthcare corporations won't cough up the money to adequately support a cost center tha
Re: (Score:2)
LOL (Score:2)
"Additionally, we are advising the facilities where these devices are located to follow network management and security best practices." "
Does anyone think that they're in a position to be suggesting "best practices?"
follow network management and security best practi (Score:2)
Let's break this down (Score:1)
Weasel words; meaningless.
"We have conducted a full risk assessment and concluded that there is no patient safety concern."
Lie.
"Maintaining the safety, quality, and security of our devices is our highest priority."
Lie.
"We are providing on-site assistance to ensure credentials are changed properly and confirm proper configuration of the product firewall."
Pr
Re: (Score:2)
"We are not aware of any unauthorized access to data or incident where this potential vulnerability has been exploited in a clinical situation."
The problem is the access you aren't aware of, dumbass.
One question (Score:3)
Re: (Score:1)
GE does retarded shit like enabling remote access on all their EMR systems.
The staff that runs hospitals and radiology clinics cannot use computers. At all. And get angry if you ask them to troubleshoot, in general. The biomed departments are often worse than the technologists. The wide-open security back doors in GE systems are the only way to actually have functional EMR systems at all.
The entire healthcare system is one giant HIPAA violation at this point.
They are so behind times ... (Score:2)
Modify? (Score:2)
"From there, the attackers can execute malicious code or view or modify patient data stored on the device or the hospital or healthcare provider servers."
I guess you mean, edit the cancer out of one patient's scan and put it in another one?
Deleting allergy warnings from patient's file, changing blood-type etc would be a bit worse than wreaking havoc in Appointments.
Reminds me of when I crashed their demo (Score:2)
I stopped by their booth and with a few keystrokes, I crashed their demo. Poor rep couldn't get it back up. If a high schooler can do that from your keyboard, with no specific knowledge or password, you have a problem.
And I did feel very sorry about that, I was just checking for a HALT.
Segment (Score:2)
These embedded devices are all on their own VLAN's and LAN segments, right?
Re: (Score:2)
Maybe. But they are on there with a few Windows machines. Because why else even connect them to a network? And I'll bet that the Windows system users will cry and moan if they can't check their e-mail or surf the web while waiting for an x-ray. So those systems have a route to the Hell that is the Internet*. And hopping from machine to machine is a typical exploit.
*I'm certain that the OSI networking model is based on Dante's Inferno.