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.
Perhaps an accessory system was involved, but rail signalling involves quite proprietary and LOW-SPEED networking (on the order of 30 baud) on TOTALLY private wires.
Rail signalling was gradually developped over the last 150 years, and the earliest remote-control and automatic operations were developped almost 100 years ago.
From the onset, reduntancy and feedback was employed (for example, whenever a switch is automated, a separate sensor arm is attached to the switch points, as to monitor the exact switch position, as opposed as the switch motor actuating arm position), and the technology is extremely conservative (gravity-actuated relays with extremely big coils to pick-up the heavy armatures, contacts made out of special alloys that are guaranteed not to stick in case of arcing - why would they, they are overwhelmingly oversized for the current they carry- and the whole thing is mounted on heavy coil-springs to insure immunity to vibrations).
For compatibility purposes, whenever solid-state components are used, they are absolutely electrically compatible (and opto-isolated) with the older electromechanical relays.
And finally, everything runs on #8 gauge wire and the nominal voltage is 10 volts.
Such an overdesigned system can withstand quite a lot of punishment. So the idea of a worm bringing down signalling is laughable at best.
But if the suits insist on using a paperwork system that is vulnerable to worms, then, such lunacy can explain the outages...
From the submission: "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."
As most people who had to fight this worm already know, a firewall doesn't do you a whole lot of good if you have users with laptops who plug in at home, then bring in their infected PCs and plug them into your internal network.
I'm not saying there aren't still ways to prevent the spread of worms, but an internal infection is in no way proof that there's no firewall. In many cases, it's just a clueless PHB who refuses to let the IT department lock down his laptop or install a personal firewall on it.
"Use a Windows 2000 machine, make sure it has only the access level needed from the outside (maybe sshd or something similar running, maybe), and keep the thing patched."
It's not uncommon for industrial applications on Windows to require admistrator access to merely run. Any services you turn off, as a result, can be modified by the user or turned back on.
Burn Hollywood Burn
Your question is answered in the following paragraph from the article,
"[T]he distinct trend within the industry is to link the systems to access control center data necessary for business purposes," reads the report. "One utility interviewed considered the business value of access to the data within the control center worth the risk of open connections between the control center and the corporate network."
IOW, they do it to save money. Time to be scared.
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.
Somebody has already mentioned QNX, but here's a quote from their 'licensing agreement:
B3.2. High Risk. Unless QSS has provided its express written consent for each Runtime Component in the Runtime Configuration, the Software may not be, and OEM will ensure that it is not, used in any application in which the failure of the Software could lead to death, personal injury or severe physical or property damage (collectively, ?High-Risk Applications?), including but not limited to the operation of nuclear facilities, mass transit systems, aircraft navigation or aircraft communication systems, air traffic control, weapon systems and direct life support machines. QSS expressly disclaims any express or implied warranty or condition of fitness for High-Risk Applications.
So if you fork out the cash, you can get a license that says, "yes, you can use this software to run a nuclear power plant."
A bold statement, but apparently it's well founded. I've heard nothing but good things about the reliability of QNX.
J
I mean seriously, how do they get away with this crap? Yes, I understand that campaign funding allows MS to sneak in their OS to the military, etc... but to actually put this nightmare in critical systems?
What the hell does it take, MS-inducted Chernobyl to make them realize that such an OS HAS NO PLACE in a nuclear reactor? Or how about NT crashing a critical system in a battleship?
Have we REALLY become so pampered that we need a bloody GUI for every frickin thing we do? I don't advocate running X in linux either, it's stupid.
If there were ever a case for a specialized proprietary system, this would be it. Just do something that does the job, and does it well. No fancy GUI crap, no million-other-f***ing-functions that can cause it to break down. Linux is a bit better than windows because you can trim it to be very specific... so something linux-based could be OK (just not a whole RedHat install, or anything else).
I mean hell, it's security monitoring. You could work this with a few text screens, some big red lights, sirens, maybe a nice voice that says "Red Alert" a-la-startrek or something.
We don't need a windows installation, with a million doodads and AOL messenger stating "You've got Meltdown" for a nuclear reactor. We don't need a GUI. We need something that does the job (well), and is secure. Cut out the extra crap... and with MS there is more and more crap you can't cut out ('nix has source, you can trim all you like, but in-house is still better).
Makes you wonder exactly how many systems like this you are trusting your life too. Wonder if we'll find out tomorrow that the power-outage was caused by a virus.
I offered this article about how the Navy/Marine network was brought down by the recent spat of worms the other day but was rejected.
There are a number of other articles our there that give info on this and the reports of other nuke plants being affected on the fateful day last Thursday.
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...).
"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."
Not really, the systems that control the signals themselves do not rely on the computers. The are fail safe systems that default to safe conditions when a part of the system fails. Worst case the conductors of the trains would see a wrong or non existant signal and stop.
Microsoft Software Causes Train Brakes to Fail. Amtrak Ruined!"
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
Keep in mind that Blaster was the only one of these DCOM worms that only exploited the DCOM hole. The newer variants, esp. Nachi, also tried to exploit the even-older IIS WebDAV hole. If the infected boxes were on the Internet and serving Web pages, no amount of firewalling will help.
Patch, patch, patch should be the mantra of every company that runs their business on MS software.
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.
First of all microsoft is losing market share, not gaining. It will never get to the point where there is nothing else... although it may get to the point where there is no microsoft.
And microsoft makes it clear in their EULA that they don't consider their software fit for any purpose (yes they actually say they don't guarantee it's suitable for ANY purpose).
Dairy Queen let alone a nuclear plant...
f ront.html
Check out http://www.ohiocitizen.org/campaigns/electric/nuc
"I was under the impression that Microsoft didnt encourage the use of its products in applications such as these."
n av y-08-07-00.asp/ 2868-1.html
I can't believe everyone is forgetting the next *nuclear* aircraft carrier, CVN-77, "will use Microsoft Windows 2000 to run its communications systems, aircraft and weapons launchers, and other ship electronics. "
http://www.fcw.com/fcw/articles/2000/0807/news-
http://www.gcn.com/vol19_no27/dod
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.
The worm I got and the reaction I got from the mail administrators was very disturbing. The thing exploded out of Outlook's preview window, spawened multiple porn browsers and did God knows what else. I turned the computer off hard. The IIS people at corporate cenrtal did not believe me, executed to completion the thing by remote control without realizing it, recomended that I simply not use the preview screen and said that they got stuff like that all the time and it was "a normal part of advertising." It made me sick. They thought I was worried about being shit canned for looking at porn and were oblivious to the implications of rooting a desktop that could remote into any other desktop in the company. STUPID FUCKING MICROSOFT CERTIFIED ASSES. Whew, I really was angry and I still am.
My plant's server was also a pain. It was some goofey overpriced Dell "server" that collected information from plant systems and made it available. It failed often and required many late nights for the people in charge of it. There were many such system but the newest one had the most information. It also had the least abiltity to do real damage. For all it's faults, it was an improvement over what was there but was not required for the safe operation of the plant. It could have been done much better had Microsoft not had anything to do with it.
The answer is not to dissconect the "business" network from the plant information systems, it's to fix the network in a fundamental way. First, the network needed to be split into an Engineering section and an Adnministrative section, with Engineers only having partial access to the Administrative network and Administration haveing NO access to plant data systems. Data systems already have NO access to control systems, and this is a good thing. These architectual changes are valid regardless of software used but Microsoft must be eliminated from all of it. From a pure business perspective, having your information available to sabotage is unacceptable and that's what Microsoft's poor security record yields. Free software is superior from a security, and functionality standpoint and is now equal in ease of use. If running Microsoft keeps engineers from viewing plant data, while giving competitors and sabatours full access to such data, the costs of Microsoft is obviouly too high. Seperating engineers from their data, as Security Focus's write up implies, would be a costly mistake. I have every confidence that power plant operators will make the right choice soon.
Hell yes, I'm mad. I just about screemed this at the top of my lungs while I was there and was ignored. When the business comes, I'm more than happy to work for someone getting it done.
Friends don't help friends install M$ junk.
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.
The low-level "reflexes" of reactors - the systems that actually run things minute-to-minute - are certified out the wazoo, and have received scrutiny at a level similar to the software that flies the Shuttle or commercial airliners.
As such, those systems are typically many years out of date relative to current hardware and software - if they were upgraded, they'd have to be recertified, and certification is so expensive that keeping thirty-year-old hardware running is cheaper. There are reactors in the US that are still controlled by PDP-8s (4K of 12-bit core memory, folks).
As others in this thread have said, the system that got hosed at this reactor was a modern status display added well after the reactor was signed off on and running. If it crashes, the operators get harder-to-understand information from the simpler systems in the control room, but the basic safety systems are still in place.
Homer Simpson to the contrary, the people who run nukes aren't completely stupid.
To a Lisp hacker, XML is S-expressions in drag.
The network administrators should still be fired. Why is a safety monitoring system sitting on any network where there are unknown machines. Internal networks should be segmented, where servers/sensitive data systems are kept on a separate network with an agressive policy in between. Anyone who is in charge of any network should know this.
For what it's worth, I remember an accident on the D.C. Metro in Bethesda when I was living there, sometime through 94 and 97. I couldn't find anything in my admitedly short search, but essentially it was on a shared part of the track during slightly wet weather. The Metro slammed into the read of a slower freight train, and the only death was the driver. An investigation showed that the train was being controlled remotely. He had radioed in they were travelling too fast, but couldn't stop it. I think he may have warned the travellers to move to rear cars, but he had no door into the cabin for security reasons.
Sudden inspiration to use WashingtonPost.com and not Google
Well, I did a search of WashingtonPost archives for 95-98. It was January 7th of 1996, the tracks were icy, and the control was by a central computer. It kept it at 75mph and when it did brake for the station it slid into a parked train. Other than later articles discussing various probes into whether the possibility of the problem was known and ignored, I can't give much more info. The full text in the archives is only available for a fee, but the relevant facts were in each's first two paragraphs.
I guess my point is even the brakes didn't help, once the train was doing 75mph. Don't assume that human intervention will overcome computer error. a) They can make the errors a lot more quickly than humans can compensate. b) Sometimes we misread the errors.
If interested, archive search. I used Metro, Train, accident, from Jan 96 - Mar 96. If you expand to later dates you will see the followups.
R: That voice. Where have I heard that voice before? B: In about 365 other episodes. But I don't know who it is either.
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 wish I could say that you are correct, but times are changing. I know of a company that is developing the SCADA systems for a chlorine gas production facility in New Orleans, and that system is being developed by a bunch of Indian programmers using Windows 2000, Visual BASIC and all Microsoft technologies at the _SCADA_ level.
If you don't know what an operating system really is, and what it is supposed to do, then you don't know why Windows is a bad choice for anything that shares the network with a SCADA system.
If your plant goes down because infected Windows machines starve the control systems for bandwidth, can you say that Microsoft wasn't the problem? Many people here (not you) have done exactly that, and it's absurd. It doesn't matter if a Microsoft system controls the switch, if it interferes with the systems that do control the switch it is just as guilty in the failure.
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)