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."
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.
They may be pretty chintzy; but they are downright ubiquitous. Things are going to get comedic if every Realtek-equipped PC that also gets Windows updates suddenly starts throwing "unsigned driver" warnings because Microsoft revokes their trust of the Realtek signing key(which they might chicken out of; but they really should do if there are signed rootkit drivers floating around)...
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".
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.
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.