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.
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".
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
https://www.eff.org/https-everywhere
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.
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.