Slashdot Mirror
Microsoft Worms Crash Ohio Nuke Plant, MD Trains
stieglmant writes "For everyone who thought the 'blackout of 2003' was bad, how about this, according to an article at SecurityFocus, and another article at The Register, 'The Slammer worm penetrated a private computer network at Ohio's Davis-Besse nuclear power plant in January and disabled a safety monitoring system for nearly five hours.'" Russell writes "Maryland MARC Train Service was shut down most of Wednesday morning due to what sounds like the MS-Blast worm or one of its variants. The local Baltimore news reports that the cause was a signal malfunction but CSX, whose communications system runs the tracks, has an article describing the shutdown as a result of 'a worm virus similar to those that have infected the systems of other major companies and agencies in recent days'. This indicates that the network that the train signaling stations are on is not protected by firewalls, at least to block ports 135 and 444 where the DCOM vulnerability is attacked. Wow, taken to the extreme, the exploitation of their systems could have caused a train collision and injury or death to hundreds of Maryland and Virginia commuters."
It is horrifying that critical systems such as Nuclear (or Nucular as W. says) power plant safety systems have been compromized by rampant known issues with Microsoft Security I believe that it is worse that such critical systems are not better administered. Heads should roll in the IT department. This is also an indicator of how this Nuclear power plant has treated Homeland Security in general. Having such systems exposed to the internet is just plain negligent.
That reactor had been down since February of 2002 due to a 6" hole in the reactor head.
There have already been numerous security and maintenance problems with the David-Besse Nuclear Plant...the plant has come much closer to melting down before this stupid event. See http://www.ohiocitizen.org/campaigns/electric/nucf ront.html.
Blaster got past a lot of firewalls that way.
In actual practice, that may be what happened. The critical control system network itself should be (have been) inaccessible from the desktop/laptop network (aside from known secure methods, a la ssh) with the appropriate firewalls on *that* network (at a gateway, and maybe on each host/node). I can only wonder if the submitter/commentator meant/implied this when they asked why such ports were not blocked.
I once did a laboration on an research reactor that was controlled by a computer running Windows. I think it was NT 3.5. Hopefully it isn't connected to the internet.
Here is some more information on the vulnerability actually used to crash the train signalling network in Maryland.
IIRC it specifically states in the MS EULA that the software is not to be used for running nuclear power plants among other things (life support systems, aviation systems...).
The infected systems were 'only' in the higher level of the control hierachy. Control systems in all plants like this (chemical, power etc) are built on multiple levels. You start at level 0, which is pretty much mechanical - safety valves, burst plates, simple thermostats. Those ensure that even if every control layer above that goes haywire and tries to make the plant blow up, you still remain safe.
:)
I discovered the usefulness of this after setting a digital pressure control on a pilot plant wrong - nitrogen vented everywhere (which makes an incredibly loud noise), my supervisor went mad, but nothing broke
Wow, taken to the extreme, the exploitation of their systems could have caused a train collision and injury or death to hundreds of Maryland and Virginia commuters."
railroad signaling systems being what they are, I'm certain that this could not have caused a collision. Railroad signal systems run on proprietary, failsafe software. Getting trains to bump into each other, in most systems, takes a computer glitch in code, or a specific series of commands to the signal system, plus a human overriding signal indications in the field.
in every signal system i've ever seen (quite a few across the country), the only thing that MS software/OS relates to is supervisory remote control and monitoring. The local signal logic (software or relay based) will not allow for unsafe train movements, even if accidentally commanded to do so, unless very specific conditions are met. Again, an Engineer passing a stop signal, for example, is usually one of the requirements.
Do a google search on "navy yorktown microsoft"
h tml
Yes, and find a lot of crap written by people who repeat a web myth. Now as far as people who were on the ship at the time or who actually wrote the software involved we get a different story. WinNT was not at fault. The truth is that a server app corrupted it's data, a client app tried to use that bad data, and the client app failed to control equipment. Can happen with any OS. Add to this the fact that the ship was a test platform not an operational ship and they were trying to break things.
"Others insist that NT was not the culprit. According to Lieutenant Commander Roderick Fraser, who was the chief engineer on board the ship at the time of the incident, the fault was with certain applications that were developed by CAE Electronics in Leesburg, Va. As Harvey McKelvey, former director of navy programs for CAE, admits, "If you want to put a stick in anybody's eye, it should be in ours." But McKelvey adds that the crash would not have happened if the navy had been using a production version of the CAE software, which he asserts has safeguards to prevent the type of failure that occurred."
http://www.sciam.com/1998/1198issue/1198techbus2.
"McKelvey writes that the failure, "was not the result of any system software or design deficiency but rather a decision to allow the ship to manipulate the software to stimulate [sic] machinery casualties for training purposes and the 'tuning' of propulsion machinery operating parameters. In the usual shipboard installation, this capability is not allowed.""
http://catless.ncl.ac.uk/Risks/20.37.html#subj1
At Dungeness B nuclear power station in the UK they still run the reactor control systems with BBC B computers. The reason is that the operating system and control code is so small (ca. 32KB) that the engineers have gone through it by hand and manually checked every possible scenario.
A complete flow chart exists that details all errors that can occur in the code and what the solutions are. Try doing that with Microsoft Windows or Linux. Sometimes the simple solutions are the best.
I've worked with VITAL control systems - train brake systems, landing gear, flight recorders, etc., and those systems are in a completely different space than PCs (or Suns, or IBM, etc). You're more likely to find Vertix Ada than you are MS C++ or any Java implementation. The likes of Sun, IBM, and Microsoft never even bid on the control systems I worked on.
Having said that, while the PC commercial vendor types like MS and Sun stay a far distance from control side (and rightly so), they definately bid on the monitor boxes. That SCADA may well be running a custom RTK, but the console that the operator back at base has in front of him could well be an XP system.
I've never used MS-based front ends myself, but I've written interfaces to OS/2-based consoles that talked to my onboard stuff, and I can't see any reason why a Win2K or XP front end would be any more or less contentious than an OS/2 one.
The problem is not the SCADA or braking system itself; it's the remote monitoring station. Often, those things are connected to the net to synch the atomic clocks, and sometimes for remote logging purposes. If *those* get compromised, the control systems may be affected, but they are not compromised. Which is to say, it's a major fscking PITA, but the brake system will still work on the train without remote intervention or monitoring; it's just not going to start again after it stops.
This indicates that the network that the train signaling stations are on is not protected by firewalls, at least to block ports 135 and 444 where the DCOM vulnerability is attacked.
It means no such thing. It is perfectly possible to have machine (such as a laptop) infected on the outside, then brought in and connected to the inter LAN, where it starts infecting machines it can reach.
And sicne when does port 444 have anything to do with it? Once exploited, the victim is running a command shell on port 4444.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
8-bit processors still dominate the CPU market in terms of volume, and very nearly in terms of profitability. They are virtually never used as general-purpose computers anymore, but due to low cost of development, deployment and testing, they are ubiquitous in the control systems industry.
Companies like Atmel and Microchip are constantly devising new and better 8-bit microcontroller chips for this market. A lot of them are available in hardened grades for just these uses. A modern one will often bundle the entire machine onto a single chip, with as much IO and analog interfacing as you could ask for.
Reading the ENTIRE assembly dump of a 32K program is rather simple. A team of a dozen engineers can verify it in a matter of a couple months (I mean formal verification here, like you would do for a truly critical system, not just "give it a look over").
While truly using a BBC micro is a little obsolescant, the ideals that caused them to do so are sound.
Hardware, software, and blinking lights!
I believe the article stated that at least one of the systems was NOT directly connected to the internet.
Most likely this scenario was the same as the one at TI here in Dallas a few weeks ago. Some nimrod from marketing or somewhere in the company brought their laptop home, got it infected, and brought it back to infect the network. Fact is, admins can't control absolutely everything in their networks.
It's surprising to me that during this latest ballooning Microsoft crisis, Linux and Macintosh aren't getting more press. They can always step up and say "Ha Ha, this isn't happening to us."
I'm an engineer at a safety switch company. We make Temperature and Pressure switches. Yes, the same ones that are used in nuclear power plants. Basically, as a purely mechanical switch, the entire computer systems can shut down and all our switches will do is turn off whatever is on. Or turn on whatever is off. ie: backup systems whatever. These systems are usually not computer controlled, only computer monitored. In essence you've lost all your remote ears to your nuclear power plant. The systems still works, all you need to do is walk around the plant to monitor it instead of sitting your lazy ass browsing eBay.
I think not. In his post he says that
That's the SLAMMER SQL WORM in JANUARY
Not the MSBlaster worm that's been going around for the last week or so. Blocking ports 135 or 139 or 445 would not affect the Slammer worm since it uses the 1433 MS SQL port.
Sig (appended to the end of comments you post, 120 chars)