Posted
by
Soulskill
on Wednesday January 16, 2013 @02:12AM
from the under-your-thumbdrive dept.

angry tapir writes "Two U.S. power companies have reported infections of malware during the past three months, with the bad software apparently brought in through tainted USB drives, according to the U.S. Department of Homeland Security's Industrial Control Systems Cyber Emergency Response Team (ICS-CERT). The publication (PDF) did not name the malware discovered. The tainted USB drive came in contact with a 'handful of machines' at the power generation facility and investigators found sophisticated malware on two engineering workstations critical to the operation of the control environment, ICS-CERT said."

...If they have them installed and actually recording. Find out which ones were inserting the USB drives in question, fire them and ban them from ever being hired at any infastructure facilities. Train the remaining employees in security best practices and run random scans of any equipment they bring into the premises.

More often than not security breaches are a result of an oversight, but far too often, it's laziness and incompetence.

They know who did it - it was apparently a contractor installing software.

And banning USB keys or "scanning" is not the solution - the solution is to not use vulnerable crap like windows for any critical functions at something like a power plant. Although banning/firing any contractor that specified a windows based system for the installation in the first place, could be a good first step.

The FBI has been after him, since he began promoting usage of the Windows hosts file to evade tracking and detection. They have a black mark next to his name and are looking for enough evidence for a "material support of terrorism charge" based on messages like these:

But, it was a contractor installing software.The OS didn't need to be vulnerable.The infected application had super user rights.Of course no doubt it DID leverage holes in windows and it wasn't there to compromise the power station, just run spam chewing malware.And it was only ON the stick in the first place because of Windows security holes.

But by definition any OS (GNU Linux, OSX, Windows) on which you are installing software if vulnerable by defaultOf course in a secure environment such as GNU Linux or

Ah, but you're reading MORE into this than is actually there (HINT: This story'd been WAAAAY different if it'd been YOUR story...).

Quite simply put, you're glossing over that Windows is actually a BAD choice for a SCADA system software component- because this wouldn't have happened the way it was read and seems to be playing out if it'd not been a Windows system in the first place.

I agree, but what you suggest is impractical. Normally the consultant would have specified the requirements, and then chosen from a list of options given. Practically, all of those options would be Windows, because, guess what, it is the industry standard. Practically then, any contractor suggesting a different system would be at a disadvantage because they would be deviating from the de facto standard. Industry has so much momentum changing from windows is excessively difficult.

If you think the only OS with issues are Microsoft OS', explain how all the centrifuges in Iran got infected? OS no longer matters, there is mal-ware out there for all OS'. There is no way to stay in front of all possible mal-ware threats so the simple method to address the issue, ban all USB drives, one of the main vectors for transmission of bad-guy software. Also ensure everyone doing ANY installs are well trained to not make mistakes like this in the future and also educate everyone else, being in a USB

1) These are due to trying to make Linux "easy". If you're using a desktop install, it's going to happen. Autorun is a BAD and bogus idea, really.2) An embedded or secured Linux won't respond to Autorun like this. I think only the ones trying to be a Windows/OSX "competitor" like Ubuntu have this on by default.

Sorry, it's more that the OS in question (Windows) does stupid things that're insecure by design- and adopting any of those bad ideas in your OS will cause the same sorts of problems. Your set of

The problem is you HAVE TO disable it in windows, along with a toilet papper roll's length of other bullshit vulnerabilities. If you use embedded Linux, you're checklist can be written on the palm of your hand with a sharpie.

The exploit you posted is two years old and fixed. But I do get your point about no OS being 100% secure. But most of these Industrial automation infections are most likely due to bad security practices or outdated and unpatched Windows systems.

My bet is the control systems are running windows XP or worse, 2000 (I wouldn't be surprised if NT can be found in some places). Manufactures of soft PLC/PAC hardware still offer systems pre-installed with Windows XP and XP embedded even though it is a security night

The exploit you posted is two years old and fixed. But I do get your point about no OS being 100% secure. But most of these Industrial automation infections are most likely due to bad security practices or outdated and unpatched Windows systems.

Exactly. This is most likely not because of the OS but because of poor security procedures at the plant. My point was exactly that this was most likely not due to the OS but rather due to lax procedures. The carbon between the keyboard and the chair is more and more becoming the weakest link.

In short the mentality is "if it ain't broke, don't fix it". And often enough, you can get away with it.

Yes, provided that you put procedures in place which compensate for the weaknesses, e.g. if a system needs to run a 10 year old XP system then *disconnect* from the network or at least *isolate* it, block the USB ports

Before you fire them, find out *why* they did it. Was it necessary to do their job? Organizations often impose restrictions that make the expected processes impossible, and it works only because employees ignore the restrictions. If that is the case, make it clear to the other employees that they were close to being fired too because, presumably, they did similar things. Do not spare the culprit -- he/she should have reported that the expected processes don't work under the imposed restrictions, not ignore

When firing him, make him walk past all the other employees lined up at the front doors, who turn their backs one by one as he passes them. And as he walks to his car, the slow-clap chant of "unclean, unclean, unclean" should be encouraged. And a hail of out of date McAfee trial disks thrown at his car as he drives away.

No. It's not to punish him further, it's to reinforce acceptable group behaviour on those who remain.

"We don't do this to you if you steal a laptop or a roll of copper wire. We don't do this to you if sneak out at noon every day. This is the thing we do this for."

And more often than not the message that is actually recieved is "Dont do whatever you have to do to make this backwards shithole actually operate on the outdated, broken, kluge of a system that's been cobbled together by hogtied engineers over a generation of mismanagement. Just sit back, and watch it collapse under its own wait and tell the bosses, 'I told you so....'."

Uhhh...Why have USB slots on the PCs in the first place? Its really not that hard to just epoxy some plugs into the slots in the back and pull the cable to the front ya know. Even if they did do what you say its still possible an enemy might in the future blackmail an employee into plugging a drive in, can't do that if its common knowledge there ain't no USB slots on their machines.

If it were me while I was at it I'd set a GPO blocking Windows from enabling any CDROM or floppy drives along with the USB d

To do it right, you would need one machine that you load the USB stick into, another machine scans that stick and copies selected file to the network. Very few guarantees in this situation though that you would be able to scan for all vulnerabilities or potentially damaging configurations.

About the only thing you can do is have a second supervisory network watching the first, and taking over (with reduced functionality) when an abnormality is detected. If course that system needs to running different hard

Uhhh...Why have USB slots on the PCs in the first place? Its really not that hard to just epoxy some plugs into the slots in the back and pull the cable to the front ya know. Even if they did do what you say its still possible an enemy might in the future blackmail an employee into plugging a drive in, can't do that if its common knowledge there ain't no USB slots on their machines.

If it were me while I was at it I'd set a GPO blocking Windows from enabling any CDROM or floppy drives along with the

Well I don't know why I was downmodded for pointing out the obvious, but as far as me when I had locked down systems I would use DVDs. I had the system set up so I could put in a password and re-enable the drivers for the DVD, then update through DVD. It worked great and we never had a bug.

But it's a huge problem with no easy solution - Stuxnet, the USAF, they all suffered when airgapped computers got infected. (The USAF when their UAV control PCs got infected because they used a thumbdrive to move a map update across).

The kicker is that it was already against DOD policy to transfer thumbdrives between secure and non-secure networks before the 2008 incident (which I assume is what you're referring to). So policy alone obviously isn't the only piece of the puzzle.

This assumes, of course, that your security staff is better qualified and trained than your other staff. And that they have been granted authority to build adequate security measures.

Security personnel (physical or digital) are not immune to negligence and incompetence . If they were there would be safeguards against allowing a USB drive to be functional in a critical infrastructure system or not having USB ports at all, and issolation from those machines that require such inputs.

Everybody is rushing to agree with you, but I don't see how the use of a USB drive is the problem in this case. USB drives are a bad way to transfer information to secure systems because they are writable, so sensitive information can leak back into the open environment. But that's not what happened here, so it makes no difference whether the upload to the sensitive system had been done with a CD, USB drive, floppy... what do you think they should use, and what difference would it make? Are you assuming

Stuxnet was specially designed to go after equipment used in Iran for enriching Uranium. However, the code has been in the hands of hackers around the world for a while now, and I'd be surprised if it's never reused.

On another note, as early as 2009 we've known China has been probing US electric companies and installing logic bombs. We know they're there, and we can't get rid of them. China has the ability already to shut down our power indefinitely, as in destroy the generators. And take a wild guess who

It seems to me that the US government wants to be able to use software-based attacks on other countries (like Iran with Stuxnet), while being totally protected from software-based attacks from the outside. In my opinion, this will never happen: US, like any other country, is and will be vulnerable to these attacks. No matter how much money they throw at it. In this context one might wonder whether it's in the US government's interest to bring the war to this terrain, like they did with Stuxnet.

3. Do not ALLOW any USB based access to any of the networked machines, ever. If at all, the USB drive needs to be connected to a Linux machine, that does not auto-mount or run any auto-magic stuff. Then, any files that need to be sent to the server need to be quarantined prior to updating.

The problem is the entire process of adding the software in the first place. The application should have been placed into a sterile test environment and proved out prior to ever being approved, then moved in a secure fashion to a staging environment for actual deployment. This whole thing reeks of massive violations of best practices, no matter what OS you happen to be using.

For example: "ICS-CERT recommended that the power facility adopt new USB use guidelines, including the cleaning of a USB device before each use."Uh, yea NO SHIT. I work for an ISP and any code deployments which have to be done via USB, flash, or any other removable media MUST be done using company-owned media devices, that media is completely sterilized and staged in a pre-production environment prior to actual deployment. Anybody who let a contractor use his own equipment for such a deployment would be sacked without a second thought, and for this type of critical system we wouldn't rely on an outside contractor in the first place. Whoever is in charge of their practices and network/IT policies needs to be fired immediately and replaced by someone who is at least halfway competent.

It must be nice working at a place where money is no object when it comes to security. For most places they will look at something like this and do a cost/risk analysis before deciding to just format USB drives before using them for deployment.

Compared to the cost of setting up a secure staging area and doing proper security management simply recovering from occasional incidents like this is far cheaper. Plus they get free help from the government and look like the victims to most people.

Eventually, configuration changes and updates are required. You would need a complete duplicate plant to really test the proposed updates; that generally isn't possible like it would be for a web server or even a banking system. Sure, you can test input and output, but you cannot see all of the complex interactions of the overall process. You cannot tune the process to real-world conditions either.

As for the GP's comment on no remote access, what exactly do you suggest for non-manned sites? Smoke signal

1. hahahahahahhahahahahah. Ok in all seriousness that is not only laughable but often actually simply illegal. The modern control world will often mandate some form of external data transfer live directly from the control system, and this is before taking into account satellite operated systems and other potentially unmanned sites. If you think that an airgap from other networks is the end of the discussion you've effectively made all your solutions unworkable in the industry.

Much debugging is done over the network looking at live data trends.Much maintenance is done over the network through the use of smart instruments and asset management systems.Much analysis and improvement to processes, reliability analysis of critical machinery, and other such activities are done in a way which require some connection to the control system.

Not to mention that airgap gives people a hell of a false sense of security.

2. This is not only a good idea, but it's actually also a requirement by many vendors.

3. Unworkable. Engineers will have your balls in a vice before you get through the commissioning phase. Mainly because you won't get through the commissioning phase as something will be wrong and there's no way to get data on or off the machine in question. The idea of locking it down to prevent autoruns is good. Providing sterilised USB keys for use is good too. Most of the problems are brought in from home, not transferred between work machines and the process network.

4. WiFi... on a process network? Dear god why! WiFi used for field devices should sit on their own isolated network with very careful and selective routing only to the aforementioned non-airgapped process network.

1. hahahahahahhahahahahah. Ok in all seriousness that is not only laughable but often actually simply illegal. The modern control world will often mandate some form of external data transfer live directly from the control system

Easy enough. Dump it over a serial port which is never read from.

and this is before taking into account satellite operated systems and other potentially unmanned sites.

Again, easy enough. Network the unmanned control system to the manned control center, but leave the manned control

You have a very simplistic view of how complex these systems can be. What you're proposing may work for very small installations like gas wells or pipeline monitoring stations but it would be impossible to do over larger systems like electricity grids. The idea underlying your proposal is what is actively used in many large control systems. Have a satellite monitoring system (SCADA without the "control") and connect to the main control system via a one-way firewall. Then let people access that system via VP

Only allow mahcines with known, registered MAC addresses, after pre-auditing and authorising them.

right. a 6 byte mac is such a strong protection measure.

Just because some people have lockpicks doesn't mean that you shouldn't put a lock on your front door. Same principle.

Which isn't to say that the devices should then allow anyone on the network to connect — sane security is always in depth — but neglecting a simple measure that keeps a lot of trouble off the network is foolish. Most people inclined to try are just looking to get free networking, and don't care which network they use. Wireless MAC filtering is how you deal with them, along with i

MAC filtering is useless. Anyone that gets that far can easily bypass the "security". The only thing it adds is a lot of manual labor to update - and hassle for users when it doesn't work correctly. (eg. typo, replaced wifi card, etc)

MAC filtering keeps the absolutely low pikers out. When I can sniff your MACs OTA and can spoof them trivially it means nothing. WiFi isn't a good answer for anything involved with SCADA- it's a disaster waiting to happen.

What you're saying is, or at least SHOULD be the standard in nuclear power plants (in Europe, dunno about USA NPP:s). The process network has no connections whatsoever to outside, or even to office network. USB-media is strictly forbidden. Mind you, only thing to make sure of this (oversights and carelesness happens) would be filling the usbports of all the computers with polyurethane.
And wireless? IT Security will get in a shitstorm-mode even if you mention wireless anywhere else than in visitor network

It used to be done like that - then middle management with MBA's in shouting wanted to show off instrument status displays to other MBA's in the comfort of their offices so that they sould win pissing contests. That meant closing the air gap and letting dedicated p0rn surfing machines onto sensitive networks.

Good, if USB's are the infection route, then it probably means they've been smart enough to not connect these systems to the internet.Good, they're not screaming 'cyber war' and conflating script kiddies with the country of the p0wned PC that sent the infection.

Bad, However, why have they left the USB ports open? And why are the ports autoexecuting this malware? I mean, even my Dad (82 years old) has the auto execute registry flag turned off. He can plug malware infected keys till his hearts content and it

Well I'm not advocating this specific agency but
a) Companies will not publish incident details, unless forced to in one way or the other. It is not in their, or their shareholders best interest to be open about mistakes. The systems used are probably not unique and are in use by several other companies as well. So if a flaw/known attack vector exists, others should be warned, so they can secure them.
b) A single incident is not a big deal, but what about ten, or a hundred? Power is a strategic resource in

I've heard the infection spreads more easily if you stick it in the port on the backside. I know for most people, its a PITA to do that. you might have to get down on your knees an so on, though there are those who prefer it and for them it's especially important to use adequate protection.

I've heard the infection spreads more easily if you stick it in the port on the backside. I know for most people, its a PITA to do that. you might have to get down on your knees an so on, though there are those who prefer it and for them it's especially important to use adequate protection.

Seen several cases of this across several different companies. I would think that the power/utility company admins are subject to the same oversights that most are. This has been seen in several different variants, and the major AV vendors have trouble identifying it accurately.

Main route of infection is via autoplay.inf. It also spreads to all available drive letters, including external drives and network shares. Easy prevention would be to disable autoplay.inf across the forest with a GPO. Window

Based on all of the other articles posted on/. regarding compromised corporate and military networks, it's amazing that these guys have limited the infection to only two computers. That's amazing! Way to go guys! Way to show up your peers! Bonuses for everyone (or at least the executives who I'm sure are the real heroes of this story)!

I was working as a developer at a nuclear power station (S.O.N.G.S.) in the early 90's. The developer across the cubicle from me had a persistent "beeeping" problem with his PC, which he ignored. I asked him about it, and he said "the damn thing just beeps every now and then". He was pretty unconcerned about it. Like "yea, it beeps, so what?"

Turns out it was a virus.

The vendor that provided the PC was always very helpful. They were so helpful, that when a new BIOS update came out for t

... would any machine running Windows be attached to or associated with anything that was critical to the operation of a power plant?!

Just in case you are scared about power plants failures - don't! There are much better things to be worried about.

For example - only a bit more that 4 years ago, the UK Navy finished retrofitting its nuclear subs with... Window XP and 2000! [tomshardware.com] For sensors and weapons control no less. At the time,/.ers coined a new meaning for the BSOD [slashdot.org].