Malware Targets Shortcut Flaw In Windows, SCADA 214
Posted
by
timothy
from the thinking-big dept.
from the thinking-big dept.
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."
Re:Windows for SCADA? WTF?! (Score:5, Interesting)
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 [wikipedia.org] 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.
Re:Realtek (Score:5, Interesting)
The 8139 is one of the shittiest NICs ever created. It personifies the Realtek ethos of bottom-of-the-barrel, "get it to sort-of work and ship it" engineering. The fact that it works on "any operating system you've ever installed" is a testament not to the virtues of Realtek, but the skill and dedication of a few people who undertook the monumental task of creating drivers. Don't get me wrong, I'm glad I have $5 surround sound on my motherboard, but I still wouldn't piss on Realtek to put out a fire.
http://fxr.watson.org/fxr/source/pci/if_rl.c [watson.org]
Re:LNK files (Score:3, Interesting)
Re:And how... (Score:3, Interesting)
Besides that, why code an interface specifically for Siemens SCADA?
Because 1) it has a large market share, 2) it may have been the first brand that the virus writers managed to reverse engineer. Stay tuned for versions that work with Allen Bradley and others.
SCADA systems have traditionally been highly proprietary, depending on obfuscation for security. Some of the newer systems have learned fom the open source movement. "You may have our protocols, even our source. But you'll get nowhere without the key." But they don't have major market share yet, And that's not the way the utility industry thinks. For a business that really has no competition (Each utility operates within a designated area. Customers can't just go shopping around.) they hate sharing best practices and lessons learned. And their manufacturers have some of the strictest NDAs. Not so much to hide cutting edge technology, but to prevent customers from sharing tales of woe about crappy products.
Re:It;s a concern. (Score:3, Interesting)
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.
Re:LNK files (Score:3, Interesting)
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.
Re:It;s a concern. (Score:3, Interesting)
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.
Re:LNK files (Score:3, Interesting)
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 [wikipedia.org]
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.
Re:Windows for SCADA? WTF?! (Score:4, Interesting)
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.
Re:Windows for SCADA? WTF?! (Score:5, Interesting)
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.
Re:Windows for SCADA? WTF?! (Score:3, Interesting)
People are moderating above post as funny. In fact, a Microsoft Security Update really did shut down a nuclear reactor. [washingtonpost.com]
Nuclear reactors are vulnerable to shut downs caused by network, malware, and "normal" Microsoft Windows related issues. See: malware shutting down a nuclear reactor, [securityfocus.com] and network trouble shuts down a nuclear reactor. [pcworld.com]