Slashdot Mirror
Malware Targets Shortcut Flaw In Windows, SCADA
tsu doh nimh writes "Anti-virus researchers have discovered a new strain of malicious software that spreads via USB drives and takes advantage of a previously unknown vulnerability in the way Microsoft Windows handles '.lnk' or shortcut files. Belarus-based VirusBlokAda discovered malware that includes rootkit functionality to hide the malware, and the rootkit drivers appear to be digitally signed by Realtek Semiconductor, a legitimate hi-tech company. In a further wrinkle, independent researcher Frank Boldewin found that the complexity and stealth of this malware may be due to the fact that it is targeting SCADA systems, or those designed for controlling large, complex and distributed control networks, such as those used at power and manufacturing plants. Meanwhile, Microsoft says it's investigating claims that this malware exploits a new vulnerability in Windows."
Seriously, anyone using Windows for SCADA in this day and age has to get their head checked. With the wealth of proprietary and free embedded operating systems available today, the use of Windows in any sort of embedded device should have ended a long time ago.
We all know what to do, but we don't know how to get re-elected once we have done it
...for taking shortcuts.
There's no -1 for "I don't get it."
and the rootkit drivers appear to be digitally signed by Realtek Semiconductor, a legitimate hi-tech company.
For very loose values of "legitimate." Realtek is the Yugo of hi-tech.
https://www.eff.org/https-everywhere
Funny, when I have people complaining about their audio on their computers I direct them to download the Realtek drivers to solve it.
Don't know something? Look it up. Still don't know? Then ask.
SCADA systems do not run in embedded boards but on full fledged computers. I worked in a company that designed a SCADA system long time ago using iRMX as operating system. The problem with Scada systems have always been its costs that increase when you use special operating systems. The trend now is to run Scada systems in windows machines, but the reliability is not the same.
Embedded device? No, it's the control systems. About 6 years ago I did an internship for a little SCADA company, and wrote something which took their existing customizable form structures (stored in databases, displayed in some Windows form framework that looked almost Win 3.1-ish) and made a version in HTML. The technology looked old even then; I'm sure that there are plenty of Windows control systems sitting around.
The World Wide Web is dying. Soon, we shall have only the Internet.
The target here is likely the HMI side of things. Many (most?) of the HMIs are Windows based and often built, installed and then ignored. The implementers routinely expect them to be running inside air-gapped networks, so vulnerability patching is not performed and sometimes even actively discouraged. Yes, there are open-source HMI projects available, but try convincing someone to deploy a life-critical system using one of them.
Windows is used all the time for SCADA applications, especially in distributed control systems. SCADA applications aren't just embedded devices, they are typically a Windows server installed on a workstation that is used for the HMI (human-machine interface) used for operators to communicate with the SCADA devices such as PLCs and DCSs. Most operators would not be able to function without Windows so they can check their email on Outlook, surf the web or play solitaire. If you want to use programming and algorithms from major manufacturers, a Windows machine saves money since there are already drivers and plug-ins made for Windows machines.
At least, unlike HP and Creative, they have yet to master the art of making crappy drivers larger than entire operating systems of just a few years ago...
They're talking about the master/control side of things, the main servers and the operator consoles that people sit at and view indications, and control things. That is where Windows is often run. Embedded devices to this day remain highly proprietary in SCADA systems, though we are seeing more Linux-based embedded devices now.
The server end though is very often a Windows shop. However, forms of *nix are not uncommon at all either and in fact UNIX types used to be the norm for servers in SCADA, but that's been going away for quite a while now. I'd say it's about 50/50 these days between Windows and *nix. Most of the *nix stuff is now AIX or some flavor of Linux (RHEL being the big one). That's on the server side. The actual consoles where the operators sit are about 90% Windows though, if not higher, and that's most likely where you're going to see this virus come into play in the first place because of some stupid user plugging in an infected USB device.
Though a proper SCADA shop should have their SCADA system locked down. We certainly do. All USB ports are secured and thumbdrives are not allowed, and disabled from being attached. An operator that can just walk up and stick a USB drive onto a console is a big, big no-no.
Most of the IT your life in the Western world depends on runs on Windows.
Yes, you are right: it is not suited for the purpose. It says so in the EULA.
Again, you are right: they have higher down times, increased maintenance due to weekly patching to prevent security problems.
Uh-huh, I agree. In my experience supporting such systems, they are indeed slower than a good Unix box, harder to administer because you are constantly manually typing things in as opposed to automating them.
Why are they using them you ask? Because it's all the developers/admins know how to use. They hate using the Unix boxes here at my work, and they keep coming to me to hold their hand doing anything on them. They prefer Windows because everyone has Windows at home or on their desks, and it's a lot easier for my co-workers to understand and use. That's why your quality of life is in the hands of Microsoft.
BTW, my co-workers are currently plotting to do-UNIXify one our major systems. *groan* They point out how expensive the AIX box is, and how unreliable it is. Um, the same guys who maintain the AIX box are going to maintain the Windows boxes, and if you remember, they did a terrible job keeping them up! It's not AIX that's unreliable -- it's the quality of our admins.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Seriously, anyone using Windows for SCADA in this day and age has to get their head checked.
About 6 years ago I worked as an engineer for a manufacturing company. One day a pop up message appears on my computer. It says something like, "this machine will restart in 30 seconds. Please save all of your work." I saved my work and the machine restarted. A few minutes later, it happened again, and I called IT.
IT comes out, and looks at my machine. They figure it's some sort of virus, but it turned out to be a worm. The Sasser worm to be exact.
Machines start rebooting themselves all over the office, and my boss asks the IT manager if this will effect the assembly line PLCs.
The IT manager gives my boss a very firm, "No!" and goes on to explain how those machines are behind a separate firewall, and can't possibly get the worm.
Just as he is explaining this, the foreman comes in from the plant and says, "Hey! all of those computers out on the assembly line just rebooted themselves!"
Our IT director got very red, and went into the server room and unplugged all of the switches. We were one of the few companies using VOIP at the time, and that meant no phone, fax or internet for the whole building.
Why did we use Windows on the assembly line? I asked that my first day on the job. Corporate determined it was cheaper than running embedded devices.
The company was shut down for a whole day, costing $20,000 per minute in lost revenue. I can't imagine those embedded devices were that much more expensive.
As a side note, our IT Manager developed a heart condition at a very young age, and I quit a year later.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
Not Secure OS 2k11, it includes an epoxy substance to jam in the USB ports and floppy if applicable.
Funny, because I use a reg file on a USB drive called "Audiosrvr" that resets the Windows audio server and fixes the "no sound" problem pretty much every single time. The only one I reinstall drivers on is Vista, but then again I usually tell folks to get off that turkey anyway.
As for TFA, who in the heck is using unsecured USB drives on important systems like that? This seems less like a Windows problem and more like a "stupid admin shouldn't allow USB" problem to me.
ACs don't waste your time replying, your posts are never seen by me.
Security and vulnerability assessment used to be this poor, but that has undergone significant changes, particularly in this decade. I can't speak for all vendors, but the one we use has security testing, vulnerability assessment, and full patch updates implemented as a standard part of their maintenance contract with their customers.
They have an internal process to verify all patches on the systems they support their software on (RHEL, SuSE, Windows Server 2003, 2008, Windows XP and Vista, with Windows 7 certification coming) and ensure they do not break the SCADA servers or clients, and they release this information to their customers relatively quickly (we usually are about one month behind, implementing patches that've been vouched safe within about 30 days of the patch release, but this process is faster for zero-day and other such critical things).
They do not "assume" anything for their customers. However they do strongly encourage air-gap, and frankly so would I. A SCADA system controlling the power grid should never have an Internet connection. It should never need one. If it must have this, you have something seriously wrong with your design.
Furthermore, I would add that recent (within the last two to three years) updates to CIP and NERC compliance specifications actually require patches to be kept up to date, and also require you to full document the fact that you have patched your servers and workstations. If you have not applied a patch, you must have documentation explaining why (this is why our vendor has their patch vouching program, so you have documentation on why they said don't install something). There are very heavy fines for not implementing this, and can even lead to certification revocation, which means you can't do business.
I work in support for Wonderware, which unfortunately, is in 33% of production facilities worldwide. It only runs on Windows, then there's iFix, GE's HMI software, Autosol and Standard Automation products running on windows... A GE DCS may run 'nix, but it reports to and is queried by a WinPC. I think it's probably more 75%/25% in favor of Windows for SCADA systems.
They should avoid holding the USB drive that way.
If the reliability of an embedded system is 1, and the reliability of a Windows system is i, then the modulus of the reliability of the two systems is the same.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
really you are asking the wrong questions. They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too. The question isn't "why were you using windows", vulnerabilities exist in all OS's. The question is "Why the fuck were they not patching known vulnerable systems that are mission critical?" Patch for sasser worm was available well before the worm, secondly "why the fuck if they had a reason to not patch vulnerabilities were they leaving their mission critical devices exposed?".
What you describe is a massive failure on the part of the IT staff.
Of course they did. Any successful company copies innovative ideas from the competition (like how Apple copied the mouse drive GUI from Xerox). Microsoft has had it's fair share of ideas copied too (Apple copied the popular 'right mouse click' context menu for their computers).
I judt got a nre Kinesis keybiartf so please excusr ant egregiou typos.
Cool. Let's indulge in some nineties nostalgia with a good old OS war... :-)
When I first laid hands on Win95 I thought to myself, "This feels just like my Quadra Mac."
Yes, it looked much the same, except in Win95 I could format a floppy disk while copying files over the network and typing an email.
Somebody obviously doesn't know what SCADA is used for in this day and age.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
>>>Microsoft has had it's fair share of ideas copied too (Apple copied the popular 'right mouse click'...
Uh. No. I don't know who invented right button clicking first, but I know the Amiga in 1985 had the capability with context menus arriving in OS 2.0 (1989). Ditto the Atari ST. It was not a Microsoft invention.
In fact I honestly can't think of anything MS originally invented. Maybe MS-BASIC back in the distant disco decade (70s) but that's about it.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
This is awesome. A major 0day? They stole the signing key from realtek? And it's not like you can instantly invalidate those keys without major hassle. I wonder how many other such "cert" keys have been stolen over they years.
Besides that, why code an interface specifically for Siemens SCADA? One question you'd have to ask is, does that system have marketshare for the control systems of any specific type of thing, or is it generally just popular in industrial automation? I can't find anything specific online, besides advertising writeups about factory control.
Emotions! In your brain!
Are you brain damaged?
USB drives are the new floppies. If the OS cannot handle them in a secure way the OS is the problem.
So looking at some of the linked info it appears that this is targeting a Siemens SIMATIC WinCC Database. It appears that the database uses a hardcoded username and password combination that end users are told not to change. I found some forum postings from people who made the mistake of changing the password only to have the software fail.
Server=.\WinCC;uid=WinCCConnect;pwd=2WSXcder (+1 for what appears to be a reasonably random looking password, -1 for being short, -1 for not including symbols, -100 for hardcoding it into the app and forcing all users to have the same exploitable entry point into their embedded database that this worm can use to read and inject code into the database)
https://www.automation.siemens.com/forum/guests/PostShow.aspx?PostID=16127&Language=en&PageIndex=2
Product being targeted:
http://www.automation.siemens.com/w2/automation-technology-distributed-control-system-simatic-pcs-7-1075.htm
Seems pretty clear that this was a targeted attack. (Launched by Competitor, former employee, etc)
The actual consoles where the operators sit are about 90% Windows though, if not higher, and that's most likely where you're going to see this virus come into play in the first place because of some stupid user plugging in an infected USB device.
And then the virus rootkits the control console. It can then issue commands to the SCADA systems that appear to be from legitimate operator input.
Back when I worked for Boeing, we fought a loosing battle trying to keep Windows systems off the shop floor. In an ideal world, we would have a secure subnet within the company Intranet behind its own firewall to keep the Windows systems from seeing shop equipment. In the real world, lots of the factory equipment was running Windows. Worse yet, some of the people responsible for loading firmware into avionics used Windows laptops to do so. And then they'd take them home at night where the kids would use them to log on to Facebook, or download kewl stuff from unknown sources.
You can't fire people fast enough to keep Windows out of misson critical areas.
Have gnu, will travel.
The reason they're "expensive" is because of the efforts to try to ensure secure and reliable operation in the face of attackers. Don't be laying the blame at the feet of the OSes- lay it at the feet of the cheap people that sought to maximize profits while ignoring the risks involved with the choices they were making.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
No you're wrong. Commodore Amigas had the right button context menus in 1989. In fact when I first experienced Windows 3 in 1992, I found it frustrating specifically because the right button was there, but didn't do anything. I then realized how advanced Amiga OS really was.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Oy! Dark Elves aren't supposed to make sensible comments.
Anyways, the way secure OS kernels are generally written is to move the critical functions into a "security kernel". Only that security kernel needs to be proven correct. Flaws in the rest of the OS cannot cause vulnerabilities. Well, in theory. But once that security kernel is written, then the expensive part of the development is done. It's proven complete and correct, so you should almost never have to touch the security kernel again. That component can be treated independently of the rest of the system, as that is how it is developed (and maintained). The cost of the rest of the OS can be covered by the sales of the unsecure versions (regular Solaris, regular IRIX, etc).
The utilities and userspace facilities that then get added onto that need to be audited as they get developed, and that's where the big big expense is. Not much I can see that can fix that, aside from OpenBSD-like auditing of the whole lot. Ensuring all libraries validated all inputs and that the system malloc enforced memory bounds would probably be helpful, as it would limit the exploit potential of bugs elsewhere that did exist.
But here we run into the crux of the issue. I really can't think of too many times you'd want to compile programs on a secure system that is running hardware. Nor can I think of too many times you'd want said system to provide much in the way of shell scripting or standard Unix utilities. In short, all you really want on such a box is a kernel, a skeleton system, and the applications you want to run that are supplied by some third-party.
So the only legitimate expensive component that these companies need is the security module. Which won't be cheap. But it also won't be as costly as having to pay for a complete OS as though nothing was getting reused and everything was going to get used. Neither of those is valid.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Windows' reliability can only be expressed as an imaginary number?
Thanks, that explains a lot!
Better yet, if you have a 2 independent systems running at the same time mirroring eachother, the odds failure is the odds of both of them failing at the same time.
(1 - i)(1 - i)
Or 1 -2i + i^2
And the reliability is thus
1 - [1 -2i + i^2]
Which is 1 - 2i.
Get a pair of pairs...
1 - 4i^2 = 5.
Four Windows boxes and you've got a reliability of 500%!
Ok, I am never flying on a Boeing again. Or any other aircraft. And given that modern computers on cars now use regular ethernet and unsecure protocols (see the papers on successful methods for injecting false commands to the engine and braking systems), I'm going to stay clear of the roads as well. Hell, just get me a Dyson Sphere on some star in some remote galaxy - and a wormhole so I can continue reading Slashdot. Gotta have Slashdot.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
XMLHttpRequest, for one. You know, the thing that made AJAX work (invented by MS to provide the real-time nature of Outlook Web Access). http://en.wikipedia.org/wiki/XMLHttpRequest
Depending on how pedantic you want to get, MS had precursors of the dock before Apple or NeXT, although I'm not sure they were the first. The Start menu paradigm has been copied by a number of other GUI environments; it's not the first time there was a globally-accessible go-to menu for running programs, but it introduced the concept that you do *everything* from one menu (and its submenus, if you're still feeling pedantic), from starting a program to changing the desktop background to installing a driver to turning off the computer.
Most of Microsoft's major advances have been business/enterprise targeted. Exchange+Outlook, as a fully-integrated groupware solution, had no serious competition for a long time. The degree and ease of control that Group Policy gives domain controllers is still a major reason that companies choose Windows.
Hell, as much heat as they caught for it, the very concept that an OS always comes with a web browser can be attributed to MS. You don't have to use it, and there's a number of people who don't except to, just once, download another browser... but they can do that. No needing to get an install disk, or mess with command-line FTP, or anything of that nature.
There's no place I could be, since I've found Serenity...
Re: CIP (CIP-007 R3), the standard actually requires
R3. A patch management program
R3.1. Patches be assessed within 30 days
R3.2. Document the implementation (usually interpreted as an implementation plan) and install the patches or mitigate
There is no requirement on the timing of installing the patches in R3.2, only that assessment be completed in 30 days.
As a result, certain utilities are very legally setting the install plan date for 2013. When they get the opportunity to install, they then update the plan the week they install and document the change. In the interim, they put together a document that shows that IDS, AV, Firewalls, or something else similar mitigates the attack.
While crazy in the desktop world, most control systems cannot be updated without shutting down generation plants. Transmission has a slightly easier time of it but not much. Shutting down generation during peak periods such as heat waves or blizzards are a worse choice than patching as long as decent security is in place. Major upgrades such as O/S Service Packs and SCADA/DCS upgrades only have an opportunity maybe once a year during planned maintenance shutdowns. This is true regardless of the OS ('nix, Windows, VMS...)
Yes, certain vendors are very good about updates (Wonderware and similar) and others are very poor. They are all getting better but there is no way I would patch most systema on running coal or gas turbine generation plant. Risks are too high on environment and life safety. A loss of the control system can result in a plant shutdown or scram. A problem control system can put safety at risk because the plant is running and improperly controlling.
More of a problem is the proprietary hardware, especially on DCS systems. While no direct user interface is present, these systems are never patched, run hidden or semi-proprietary OS's. Worst case I know of is a DCS board that allows remote login with a known unpublished ID/password.
At least today, virtually every control system is behind an internal firewall and the majority have a decent firewall configuration. However, the value of communicating out of the control system outweighs the risk. Especially when running 15 power plants in a major utility and the power supply/demand balance on the grid is more important than air-gapping. If air-gapped, high quality frequency control at 60 Hz would be near impossible.
I agree with the first part of that last sentence, and I suspect that if you asked people, they too would claim that Windows is easier to understand and use....
... But you'd all be wrong.
The plain fact is that Windows is simpler in places where simplicity actually hides essential knowledge. Say what you like about Linux/Unix being harder; the fact of the matter is that it's no harder than it should be. The Windows UI, on the other hand, definitely is simpler than it should be.
Every time someone takes the shortcut and runs a Wizard, the end result is that Microsoft, not the admin/developer, ends up making the majority of technical assumptions, most of which are driven by marketing, rather than actual technical needs.
The problem, in short, is not that Linux/Unix is too hard. The problem is that Windows pretends to be too easy.
Crumb's Corollary: Never bring a knife to a bun fight.
*cough*
Portable media should never be considered "secure". FFS, just think about the corporations that have distributed malware, intentionally or unintentionally, via their CD's and/or DVD's. From time to time, a story comes out about malware being distributed at the various conventions. Yeah, it's a joke, mostly, because the techies at the conventions SHOULD be savvy enough to watch for that crap. Still, the malware gets distributed, and it runs on any number of machines, before the techies get wise to it.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
The funny thing is that I work with a lot of GE products.
Sorry to hear that, if I ever catch up to you in the field I will pick up your bar tab.
Sorry buddy, but you got it wrong. This problem doesn't affect Linux based systems. I can plug my usb stick into my computer and I'm not affected by this. Everyone. EVERYONE using microsoft is affected by this. Its not a matter of proper patching or not. This is another newly discovered flaw. It was discovered because microsoft didn't test their software prior to shipping. No other operating systems are affected by this. Only microsoft. And not just 'whats a patch?' systems, but all of them. This affects every microsoft system, including yours (as someone defending them, I assume you are beholden to them for you income, and are rubbing patch disks between your legs right now). This problem affects microsoft. Not Linux, not solaris or aix or solaris or bsd or plan9 or system36 or ultrix or vms or vm/cms or mvs/xa. Even systems patched up to this very second with all the patches microsoft has are affected by this. Its a microsoft problem. Don't speculate or say 'just as likely'. Thats bullshit. I don't use microsoft, and I'm completely unaffected by this. Only microsoft is affected. They are the only ones. Quit blame shifting. Its a microsoft problem. Its not a linux problem. Its squarely a microsoft problem.
The vector is the windows machine that is networked (stupidly) to older non windows boxen that do the SCADA work.
In theory, an attacker could manipulate the SCADA machines and cause disruption.
I worked with non-windows SCADA systems. Any windows boxes operated with proprietary software and proprietary communication keys. Without the keys, you have nothing. If any dickwad engineer insisted on windows communications, they deserve exactly what they get and I hope it's a Dell.
The mind conceives, the body achieves, the spirit manifests.
Why do you presume an embedded system would even have an OS?
That probably had something to do with it. Yes, I'm sure you could have a second (or third) redundant machine on the assembly line so you could reboot each machine in serial as they're patched and verified to work--a procedure that'd have to be carried out on the order of monthly (and some times randomly on top of that) which seems unreasonably excessive for such a niche application. Or, you could use an embedded system that doesn't have an OS. Or you could use an OS that's small enough that no exploitable vulnerabilities exist because even if a vulnerability exist, you can do enough test cases (and hardware parity/checksum/crc) to verify that software always reacts properly under all possible valid inputs and always fails safe with all possible invalid input, provided the input size is forced to be limited enough.
How about "why the fuck would you use a general purpose OS with millions of lines of code to do a task that ten thousand lines of audited code could do instead"? My guess? Management thought it was cheaper and some IT people thought firewalls were magic that would remove all patching concerns.
No doubt. In management too. At best, they're responsible for hiring IT staff stupid enough to choose to rely upon Windows and a firewall. At worst, they're the ones who forced such a solution on IT staff and selected IT staff who believed it'd work.
Eurohacker European paranoia, gun rights, and h
"Windows recently downloaded and installed an important security update to help protect your computer. This update required an automatic SCRAM of your reactor."
Finally had enough. Come see us over at https://soylentnews.org/
Portable media should never be considered "secure".
Correct, and that is why "autorun" functions that are active by default are a bad idea. But convenience over security is typical for certain OS vendors, especially those from Redmond ;-)
The only instance when stuff from portable media is automatically executed should be at boot time, if the medium is selected as boot drive in the BIOS (or whatever your system uses in place of the BIOS).
C - the footgun of programming languages
Starting to wander a little off-topic here but I couldn't resist one more answer. :) I wasn't aware of the lack of timing requirement, hmm. Certainly our company didn't interpret it that way, so we're actively implementing patches on the month-behind schedule, and this includes our control systems too. We can do this because every server type (data ack, database, human interface server, etc) we have operates in tandem with an identical twin, in standard failover configuration. So we patch the backup, and initiate a controlled failover to it. Problem? Fail back. Works? Patch the other side now. This is how most every SCADA control system I've worked with has operated, even the old 1970s paired-mainframe-based system we had at the company when I first started here.
;) I didn't mean to imply it operated in a vaccuum, totally networkless. I merely meant air-gapped away from the Internet specifically. Communications between facilities is indeed vital, it's just that going the Internet route to achieve that is flat out "wrong" and really, I think should be completely banned, by regulation or otherwise.
We are a central control center though, the HQ for utility company as a whole, not an individual generation plant. So our system setup may indeed be very different from the individual plants we operate, so I can't speak for how the plants manage their DCS control systems directly. Our major SCADA upgrades though are on a yearly basis, unlike OS patches.
I see a few people all replied to my air-gap comment, but I'm lazy and don't need to make three replies!
We do indeed have inter-facility communications all over the place, to all of our various power plants we operate and control, to all our individual substations, all that stuff. However, it's done via private networks. We have our own microwave communications system licensed throughout the state and probably 90% of our communications to our assets is via this. The rest is through dedicated leased lines. We also communicate realtime with the state's central control authority, and that's done via a private frame relay circuit that THEY actually had installed at our facility (along with their equipment) because they actually require this from all utilities under their authority, to communicate to them. They did it right, basically.
I recently did installation work at one of the largest gas processing plants in Norway.
The control system HMI runs on OpenVMS, the controllers are on a redundant token ring network. (good old coax).
All the control room clients are winxp sp2 with almost no patches. This is required to have the HMI applications work. They also need to be set to 256 colors to get blinking effects (critical in such a system..).
Will the system be replaced with something newer? Not in a few years. Stopping the plant costs 23 million USD per day just in lost sale/production...
Now... have there been problems with these vulnerable machines? Nope. Not ever. Control room personell know not to fuck with the clients and behave... They are running a multimillion dollar plant and fucking up is not something you want to do.... You dont mess with the system.. EVER.
The story describes what I consider an HR issue, not a technical one...
They failed to correctly patch windows, they would just as likely fail to correctly patch linux or any other OS too
..
Bullshit
If they had Linux PCs correctly configured for assembly line work (i.e. only components necessary to that work installed, firewalls on PC as well as network, etc.) how many holes would have been left open by a failure to patch?
How many would have been left open on any other embedded device OS?
USB is handled much more securely than floppies ever were :S
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
True enough as far as it goes. Not properly maintaining any system is a problem. The firewall should have actually prevented the spread.
However, Linux and a number of other OSes (NOT Windows) make it a lot easier to produce a dedicated install with a minimal attack surface (no ports you can't close or services that you can't shut off and uninstall.). The question is why would an industrial control system not be stripped down to essential services. Why was anything there even listening to port 445 or 139?
People are moderating above post as funny. In fact, a Microsoft Security Update really did shut down a nuclear reactor.
Nuclear reactors are vulnerable to shut downs caused by network, malware, and "normal" Microsoft Windows related issues. See: malware shutting down a nuclear reactor, and network trouble shuts down a nuclear reactor.