Forget sexy zero-days. Siemens medical scanners can be pwned by two-year-old-days Hackers can exploit trivial flaws in network-connected Siemens' medical scanners to run arbitrary malicious code on the equipment. These remotely accessible vulnerabilities lurk in all of Siemens' positron emission tomography and computed tomography (PET-CT) scanners running Microsoft Windows 7. These are the molecular imaging …
"Oh I don't know, I suspect I would secretly be thankful for the early demise."Stated with great confidence, no doubt. My brother refused treatment for his cancer because irrational fear of gamma radiation. He died a very gruesome death.
Me? I'm sticking around. I've been irradiated a few times, and survived cancer.
Evidence for beneficial low level radiation effects and radiation hormesis
My partner has had perhaps an even dozen PET scans in the last 3.5 years. They are a godsend for definite answers. When the cancer is potentially as mobile as this one, they told exactly where and how much was involved, and then the progress against the cancer. And perhaps even more important (now) they say that 3 years post stem cell transplant "still clear". Some like that kind of reassurance, y'kno?
So given that in the developed world one in three of us or someone very close to us will get cancer, I am very glad for the possibility for definite answers.
Similar to the idea that radon in your basement is a greater danger to you than mad scientists:
"In a human body of 70 kg mass, about 4,400 nuclei of 40K (potassium isotope) decay per second. The activity of natural potassium is 31 Bq/g. About 0.001% of these 40K decays produce about 4000 natural positrons per day in the human body."
This from 'positron' article on Wikipedia. Share and Enjoy!
"I am none too sure about the water either, there is some Hydrogen3 oxide around as well."
AFAICR we weren't terribly worried about tritium in the water that went into the benzene synthesis for the carbon dating system although it might well have been because it could be reasonably well separated in the kick-sorter. Radon in the water supply from the Mournes was a different matter...
Paranoid much? Please see https://www.gov.uk/government/publications/ionising-radiation-dose-comparisons/ionising-radiation-dose-comparisons a PET scan comes in at slightly less than whole body CT or a year in Cornwall. You would have incredible difficulty injecting any more than that, partly due to the level of control on radioactive materials, and partly because the positron emitting isotopes (you do end up with gamma shortly afterwards) have very short lifetimes (longest half-life 110min for 18F, also means stockpiling not possible) and in most centres will have been manufactured somewhere else and ferried (very quickly) to you after going through aforementioned radioactive substances handling processes. A medical physicist has to evaluate the imaging protocols used, which includes the dosing.
So, I'm not sure what you're suggesting these power-crazed radiographers will do, but if it's some mad Harold Shipman style plot to very slightly increase people's risk of cancer over the rest of their lifetime then they would have a very hard time of it.
For a long time, medical equipment chose Windows because you had many tools (development environments and libraries) to quickly write applications with a complex GUI, and print out or export results. None of these machine are run from the command line, and the result shown in ASCII, believe me.
The biggest roadblock for Linux were - and is - the lack of such tools and libraries. Qt & friends - besides being far more complex to use - lacked many of the specific libraries for medical imaging, and GUI widgets.
Sure, in some environments like CERN and some universities have legions of undergraduates to attempt something in *nix, most commercial companies don't have such source of underpaid developers, and a good GUI is also a sales advantage.
The contempt greybeards always shown towards GUI applications, and any tool designed to ease their development, is on of the reason Linux has a 3% market share on desktop systems.
"The contempt greybeards always shown towards GUI applications, and any tool designed to ease their development, is on of the reason Linux has a 3% market share on desktop systems."
The reason Linux has 3% market share on the desktop is because of years of Microsoft leaning on H/W manufacturers to ship Windows and only Windows pre-installed.
Years ago, late '80s or maybe 1990 we were running a Unix box with an NCD X-terminal. As a cheaper way of getting more X-terminals we installed a very early version of Windows on PCs as there was X-server S/W available for them (note that in X the applications are clients - the server provides the display service). That's right, the function of Windows was as a platform to display the real GUI which was that of the Unix box. Eventually Microsoft picked up a few GUI tricks that had been kicking around in the Unix world for years and stuck them together to make Win 95. Admittedly they hit a sweet spot with the combination but pretty well everything that went into that had been around in Unix for years, together with some New Wave stuff that HP had devised to improve the functionality of Win 3.x. Up to then, and for a good while afterwards, any serious graphical workstation was a Unix box.
And way before that, maybe 1980ish, we had analytical instruments using graphical displays way before Gates got QDOS at a knock-down price. I remember a Micro-Nova driving an X-Ray microprobe back at that sort of time.
TL;DR Windows was a late-comer in the GUI game and even then it took a few years to grab enough ideas to become usable.
"The reason Linux has 3% market share on the desktop is because of years of Microsoft leaning on H/W manufacturers to ship Windows and only Windows pre-installed."That's the myth. The reality back in the 1990s was that Lunix had decided to adopt a version of ISO 8859 character set that excluded typographers' quotes, the en dash, the em dash, the ellipsis and several useful ligatures. Microsoft, Lotus, Digital Equipment Corp and Commodore had adopted an earlier version of ISO 8859 that's called Windows ANSI.
Hence the quotes around “this” in Windows ANSI were either ("), or `` for the opening quote and (") for the closing quote. Missing also were †, ‡, €, ƒ, ‰, and ™.
For those of us in publishing, Lunix had effectively put itself out of the running, even had DTP software of the calibre of Pagemaker, Ventura, or QuarkXPress been available. The introduction of proper typographers' marks in Windows and MacOS word processors meant any correspondence generated on Linux looked distinctly amateurish. It's not only MS that shoots itself in the foot.
It's also part of the myth that you could only purchase a PC with Windows installed. Apart from portables, only two out of dozens of PCs I've purchased came with an OS.
Edit: dunno why I can't get inch marks to display here. [sigh]
"For a long time, medical equipment chose Windows because you had many tools (development environments and libraries) to quickly write applications with a complex GUI, and print out or export results."
*NIX systems (and others) had had a GUI and supporting libraries since before Windows 1.0. What they did not have was a WYSISWG IDE for creating these GUIs.
Which turns out to be not much of an impediment. In practically every application which offers both a point and click as well as a keyboard input (like AutoCAD, for example), skilled users tend to rely on the keyboard input. Skilled users like the developers of complex medical imaging applications (I would hope). What the point-and-click or drag-and-drop environment does is impress management. Who don't have the same skill sets and extrapolate their ability to MS Paint a simple app to the output of their s/w deportment's productivity.
I've built a few enterprise web applications using vi. With management continually looking over my shoulder, asking if some web tool set would be faster. Given the amount of time I'd have to spend with a text editor, repairing broken HTML and filling in generated function stubs; Nope. Might as well just use a text editor from the start.
"Skilled users like the developers of complex medical imaging applications"
You seem to have ignored orthopaedic surgeons in your user list. They tend not to be too good with command lines.
Don't understand why the natural default to not Windows is Linux; any Linux would have its own collection of bugs.
Nothing wrong with using vi to create a GUI based application. X-Windows and Motif, however, were a whole together different kettle of fish. Did the job, but buggy as hell, and highly idiosyncratic. If it weren't for the flakiness of that particular platform, I doubt that O'Reilly publishing would be the power house it is today. They were the only ones who published any halfway decent books on the platform.
"X-Windows and Motif, however, were a whole together different kettle of fish. Did the job, but buggy as hell, and highly idiosyncratic."
To an extent, yes. But with a bit of practice and attention to (poorly documented) details, it wasn't that difficult. I never had an opportunity to do much X/Motif development. But I have done some Perl/Tk interfaces. Not really all that difficult.
"If it weren't for the flakiness of that particular platform, I doubt that O'Reilly publishing would be the power house it is today."
If I recall my last peek at my O'Reilly manuals, they were little more than reprints of the X/Motif man pages. Back in my days at Boeing, we got a set of these shipped with every HP workstation. Most of them ended up in the dumpster, never unwrapped. So have got a complete set at home (somewhere).
"Which turns out to be not much of an impediment. In practically every application which offers both a point and click as well as a keyboard input (like AutoCAD, for example),"
Ex-draughtsman here, worked on DOS versions of AutoCAD all the way to Windows 95! Keyboard input was the way to go, mouse in right hand, left hand mashing various keys to manipulate what I was drawing at the time.
Yes there were GUIs especially in 95, but they were almost always slower unless buttons linked to macros we'd setup for snapping at pre-set distances etc. At all other times typing singular keys was quicker as the mouse pointer could remain on target.
A remote admin tool that does not ask for a password by default.
Very impressive. :-(
I can sort of get why Siemens would not release updates unless they were internally checked for compatibility with their embedded apps but this should be an existing, ongoing process in Siemens for Windows updates, IE more or less automated.
A remote admin tool that does not ask for a password by default.
Not defending bad security, but you can see how that might happen. Machines like this are operated by medical staff, not IT. And this is just one machine out of dozens of computerized scanners, monitors, and other devices that they have to use every day.
You can't have 20-random-character passwords that are changed every 90 days on machines that have to be deployed quickly in emergency situations. If it had a password, it would probably be something like "1234" or "doctor" anyway, and it'd be written on a post-it note on the side of the machine...
"it'd be written on a post-it note on the side of the machine."
A password written on a post-it note adjacent to the legitimate operators is vastly less of a risk than a passwordless remote admin tool.
Could some sort of PKI Card reader not be implemented, so doctors would only have to remember their own PIN.
Probably, but you'd need to link to some broader ident PIN. Giving them something else to remember isn't a good idea.
Rather OT, but I had to have a scan in a Siemens machine a year back. And it struck me that the patient experience lacked the "wow" factor. The rotating scan head is just about visible through a deeply coloured perspex window, but with a bigger, lighter grey window, some multi-coloured flashing LEDs with patterned timing they could create a really super display. And the machine was commendably quiet, but if they'd use a noisier gearbox it'd produce a super "wooowooooo.waooooooo.waoooooooooooooo" noise with a rising pitch as the head is accelerated. Add some strobing high intensity lights and a Star Trek transporter noise as the head reaches full speed, and the people being scanned would think what a super duper, high tech experience they've had.
Come on SIemens, what are you playing at?
I had a CT scan when my bowel perforated at Christmas, my first one infact. I like to think I'm okay with most medical procedures but the noise those things make and the fact you're so close to it is actually quite un-nerving and uncomfortable. (This is coming from someone who's had most medical diagnostic procedures in various orifices that things really ought not to be inserted!)
Sure - it can still be turned on, and take pictures, but that's not how you expect to use your phone, and now how radiology departments work.....the patient information is normally downloaded from the radiology information system (RIS) and incorporated into the images which are sent to the Picture Archiving Communication and Storage system (PACS) to enable use around the hospital, comparison with previous scans etc. All this uses the DICOM protocol, which whilst far from secure is sufficiently obscure that most hackers haven't bothered (yet!), and there is no need (probably) for complete unplugging. On the other hand, why anyone would want to introduce easily exploitable weaknesses by adding an unnecessary web server etc. to such primary imaging systems is beyond me......those ports need to be blocked (on all machines, not just the ones we know about) now and forever.....
no one wants an X-ray scanner to go nuts at the hand of a hacker while a patient is in it.
Well, except for the hacker.
The rest of us would prefer that the scanners don't "go nuts" at all, regardless of their occupancy status. The machine could be damaged, and someone who needs a scan in a life-threatening situation might not be able to get it.
So thanks, Siemens, for making these gazillion-dollar machines easily pwnable by script kiddies. Awesome job.
It never ceases to amaze me why these vitally important items which CANNOT be allowed to be damaged are even connected to the outside world directly.
If they need external data, then download that external data into an internal server (via a firewall), and connect the scanners to the internal server. The internal server could be supplied by the scanner company; it could be a simple single-use box.
It's not completely foolproof, but it's much safer than just connecting to the outside world.
<quote>But why are they on the Internet anyway? </quote>
Well, because these machines have to be used. I appreciate that you think that these machines just need to be net connected for "external data" (aka random stuff? updates?). But you then completely forget what they actually do: they scan patients to aid diagnosis. As Dave Harvey described here very well, we sped up things (among other things, not talking about e.g. 3D tomography) by not having to "develop films and carrying them around" like I remember from my early days (~ 25 years ago). We also made it more powerful, comprehensive, and (NHS budget anyone?) economical, even by just developing PACS/ RIS that makes all those records easier to store and document. So yes, radiologists have immediate access can can work more fluent, more efficient, which helps patients better and quicker. On the back of this, this has also made other developments like telemedicine possible (whether you agree or not), where radiologists all over the world (yes, India, but also that expert in US, CH or NZ) can easily and quickly diagnose images of patients in the UK. In short, stop seeing scanners like this like a stand alone box, and see it as an interconnected component of a work flow.
And @FlamingDeath:
At the risk of sounding pedantic, but isotopes used for diagnosis or treatment don't emit gamma radiation exclusively, but some also emit alpha, beta, or positrons. And although I also have my gripe with the industry I work with/ in, I really struggle to see how you come to label them sociopaths. Sounds like you don't have complete inside into "how things work". As Credas said, hope for you you don't "get your cake and have to eat it too".
@Nattrash
Dave Harvey also made the point that they use a specific protocol, DICOM. a moment's googling takes be to the wikipedia article which in turn tells me that DICOM uses specific ports. If the system has to be exposed to the wider internet (as opposed to a network whose access is limited to legitimate users) then only those ports should be open.
@DrSyntax
Perhaps it's better to call DICOM a standard and a guideline? But yes, you're absolutely right, although I must admit I'm very rusty on the communication side (hell, I'm just rusty I suppose ☺). Having found the wiki, you probably also found that DICOM is produced and maintained by NEMA, which basically is a coop of the medical imaging manufacturers. This was a sensible and much needed solution in the early days, when stuff was manufacturer specific, locked and non interchangeable.
Having moved on to other medical devices, I'm afraid I can't tell you what DICOM standards are nowadays. Their "resource page" is still there (http://dicom.nema.org/standard.html - Jeez, people, do a bloody face lift! I'm also not using Mosaic anymore!).
If my memory serves me well, you'll find info of your interest most likely in part 8 and part 15.
In fact, the biggest risk isn't the "internet" - that's pretty much fire-walled to death in most hospitals - it's the internal "trusted" network which is the problem - everything from administrative PCs to network points for patient kiosks in public areas and doctors' PCs which need to be able to access the imaging systems in examination rooms - any of these are at significant risk of being pwned or abused, which is why the devices need their own defences to be as good, with the smallest attack surface as possible.
"the devices need their own defences to be as good, with the smallest attack surface as possible."
That brings us back to the original article and the point that in this case they don't have the smallest attack surface possible.
I have to take SWMBO to an outpatient eye clinic from time to time. As it involves sitting around for a good while I sometimes take a small laptop to do some work - ooh, look, three open SSIDs! No I didn't try connecting.
They are also often on heavily locked down networks. This can be a pain if you are (for example) attempting to conduct a multi-centre study and need to have people send MRI to you for analysis, outside their normal connection to the hospital PACS. There are ways to set that up safely over a network, but we work with some people who have to transfer every scan onto CD and upload from a separate computer because they can't get local agreement for it. (We've also come close to being told that sites are simply not able have a computer that can connect outside the network and would like to send the CDs to us.)
PET is an entirely tracer-based technique, it always requires an injection. You could use a PET-CT machine for only CT, but likely you would just use a much cheaper CT only machine. There are injectable CT contrast agents, which can include for angiography in stroke, but they don't have to be used in head imaging, and can be used outside the head too.
A drug cart in an emergency room has a lock, it's a weedy little lock sufficent to stop some passer by helping themselves. It isn't proof against a prolonged attack by a group of bank robbers. If you wanted to make the drug cart proof against a directed attack by a state level attacker it would be just a little bit more expensive and inconvenient to use.
But it doesn't need to be because it is installed in an area where access is relatively controlled and people are watching it.
The same with the scanner, it should be protected by the hospital's network security. If they want to put it on a public facing net then they are going to have to pay for a military grade secured system and have to deal with the inconvenience of the necessary access controls.
They are also going to have to pay for the weeks/months of testing necessary everytime Windows releases an update and the downtime while the scanner is disconnected until the patch has been tested.
> "They are also going to have to pay for the weeks/months of testing necessary everytime Windows releases an update..."
That's fair. Say Siemens spend £1M a year on that testing (10-20 FTEs). Divide it amongst their customers (Say 1000), and add it to the maintenance costs of the scanner. £1000 p.a. each isn't going to make a blip on the costs of running a scanner.
(Part 2 of the plan is to make security a selling point and block competitors from winning sales on those grounds. Win-win)
Which is good, because no one wants an X-ray scanner to go nuts at the hand of a hacker while a patient is in it.
Given the useless and utterly inaccurate diagnosis endured from the last consultant, perhaps the hacker may have more chance of giving a better one. The cat certainly does a far better job than the overpaid twonk.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
