Stuxnet Worm Infected Industrial Control Systems

Sooner Boomer writes "ComputerWorld has an article about the Stuxnet worm, which was apparently designed to steal industrial secrets and disrupt operations at industrial plants, according to Siemens. 'Stuxnet has infected systems in the UK, North America and Korea, however the largest number of infections, by far, have been in Iran. Once installed on a PC, Stuxnet uses Siemens' default passwords to seek out and try to gain access to systems that run the WinCC and PCS 7 programs — so-called PLC (programmable logic controller) programs that are used to manage large-scale industrial systems on factory floors and in military installations and chemical and power plants.' If the worm were to be used to disrupt systems at any of those locations, the results could be devastating."

Comments

deserved

[Anonymous Coward]

If they still use default password, they deserve to be hacked and face total havoc.

Industry`s security is still so crappy.

Re:deserved

[thegarbz]

If they still use default password,

Having experience with a few of these systems from various vendors I say it would be great to have a choice in the matter. The is a lot of investment in the configuration of a large logic controller and vendors often provide themselves a back door such as a hidden admin password to come in and fix things when the system goes tits up. On top of that they often recommend not changing the default passwords of systems that are hooked directly to process control because the machines themselves are often under lock and key and behind firewalls and thus presumed to be "safe".

We were infected with the Stuxnet worm at our plant, and it spread all around the machines on the business network but never made it to the process control systems. Although it was still disruptive. The firewall was shutdown and the control network isolated for days so they could do a complete virus scan. A little network management and physical security can go a long way. Frankly if any virus gets onto the process machines, default password or not, and not even targeting the software for the control systems there's potential for a real "game over" event.

Re:deserved

[Anonymous Coward]

This.

I can confirm the existence of at least one such backdoor. I did tech support for a company that sold cellular connectivity devices through which automation systems could report to a remote server, or be remotely administered.

It was just a Busybox machine with a bunch of services, but we had an insecured telnet (as in, port 23, ALL PLAINTEXT) master login that gave root privileges, and we used it for advanced troubleshooting. It was the same user account for all products across all firmware, and even though we never shared it with the customers, anyone calling us to help them do the initial configuration over Ethernet could've set up a packet sniffer and got it.

Military and police customers tended to use private networks (thankfully) but I'd estimate 90% of those devices were directly facing the internet, including many used for the administration of governmental utilities. In the wrong hands, this not only provided access to all the transmitted data, but was a non-noticeable attack vector on all the equipment on the LAN, since those tend to not have intrusion detection systems.

Wow

[0123456]

So people not only leave the default password on their industrial controllers, they put them on the same network as Windows PCs... Wow.

Re:Wow

[Lunoria]

People are lazy. Why change the password on these machines? You'd have to write it down somewhere because remembering things is tough.

Re:Wow

[gmuslera]

Probably the network is behind a firewall, so they think they are safe from outsiders. The problem is when insiders have both windows and no clue.

Re:Wow

[Svartalf]

And they USED Windows as the OS... Brilliant!

Saying that they should airgap the SCADA is obvious- unfortunately, people tend to favor "ease of use" and that airgap is one of the first things that typically tends to get botched in the name of that. So, even if you thought you put it on a standalone, the thing's liable as not to be on the corporate net with all the other machines.

Re:Wow

[Mr. Sketch]

Having worked in that industry, it's very common for them to be on the same network as Windows PCs. As for the default passwords, that's their own fault.

The reason they have to be on the same network as PCs is both:
1) The software to program and monitor PLCs are on Windows (made by Siemens, Rockwell Software, WonderWare, were the big names when I was in the industry 10 years ago), so it makes sense to have them on the same network so they can communicate with the PLC while it's online and see the logic operations in real time.
2) The biggest reason is that PLCs communicate with visualization software that runs on Windows (also made by the same companies as above), that can be viewed from a central location. This allows the production line manager to visually see the operations of the machines in a nicer format than looking at the raw logic bits. The visualization software can display shapes, colors, diagrams, animations, etc of the production line with real-time data about what's happening.

So yes, these PLCs are usually on the same network as Windows PCs. Ideally it's a private network with just the PLCs and the visualization/programming/monitoring PCs, but many places are not that strict about the network separation.

Re:Wow

[The Master Control P]

The problem isn't that they're on the same network as Windows machines, it's that they're on any kind of network whatsoever that's not insulated from machines connected to the public Internet by an air gap.

Once again: Do not -ever- put mission-critical systems on the Internet.

Re:Wow

[jofny]

You can't change the Siemens passwords in this case (and have things keep working).

Re:Wow

[MichaelSmith]

As for the default passwords, that's their own fault.

I remember, back in the day, DEC had an account called FIELD on all the VMS systems they maintained. The DEC support guy would always grumble when we disabled that account, or changed the password. Its more trouble for them, you see.

Re:Wow

[Relic of the Future]

From TFA: "spread [...] typically via USB sticks."

Air gap will hopefully stop secrets from getting out (unless... is this thing smart enough to wait for another USB stick, copy its stolen data on to it, and wait to be plugged in to a networked PC to communicate out? That'd be snazzy!) but it won't stop a USB stick. And, since USB is how code and software updates are usually delivered to these devices (not to mention the mouse and keyboard for the PC hook up), you can't just turn USB off either. Hence this.

Re:Wow

[Sylak]

the problem lies ONLY in being on a network with Windows PCs. Simens more often than not specifically designs their products to NOT be networked OR have any default passwords changed, like on a JR Clancy Rigging System for theatres. Many of these appliances you can't change the passwords on without violating your service warranty, so complaining about passwords is really a bad assessment.

Re:Wow

[DarkKnightRadick]

Stop. The more I know the more I want to scream.

Re:Wow

[MichaelSmith]

Once again: Do not -ever- put mission-critical systems on the Internet.

You will never win that game. Google has real time traffic info from traffic signal systems these days. How do you think the information gets through? I used to run a traffic signalling system. There was an indirect internet connection, but security was taken seriously by everybody, both working with the system and in management. I would be much more concerned about a totally airgapped system with poor internal security. Because these days you can't have a 100% air gap.

Re:Wow

[hairyfeet]

The real problem is NOT the OS, since it is pretty obvious this attack has been specifically designed to hit a very small niche target, which means no matter what OS you were running the malware writers would have simply written to that target.

No the problem is something I run into all the time in my little shop, I call it magical thinking. It is the classic "we have A, therefor we never have to worry about security!" problem. in this case too many are thinking their firewall will magically make the problems go away, not realizing the user is often the weak spot. I've seen the exact same thing at a SMB where the owner had bought Macs based on magical thinking, then his kid wanting to look at pron ended up infecting the network with that DNS Changer trojan.

The problem as we are witnessing here is there is NO magic bullet, be it Windows, OSX, or Linux, be it a firewall or other piece of hardware, be it any other piece of tech. The ONLY way to secure a network is a top to bottom approach that runs everything on absolute least permissions and no network access to anything that doesn't absolutely need it. But sadly that takes real planning, real effort, and a dedication to keeping the security level up, and most companies would rather buy into "this magic box will save us!" because it is cheaper and easier. Sadly it also never works.

Re:Wow

[Jurily]

People are lazy. Why change the password on these machines? You'd have to write it down somewhere because remembering things is tough.

I blame management. With all the chaos around a factory (at least the ones I've worked in), the default password is more reliable than the people who are supposed to know them when they're needed.

Add in the fact that factory workers don't really get paid enough to care about anything, and you have to start wondering why this this kind of attack isn't more common. Hell, we've played Minesweeper on the monitoring terminal of a >$100M production line :)

Re:Wow

[DNS-and-BIND]

You do know that factories are staffed by engineers and workers, not IT pros? I doubt if they're even aware that passwords exist on their equipment. When they set up the factory, they just called some people to get all the machines to talk to the computers properly. Then, the contract is finished and the IT people only get a call if there's anything wrong or new equipment is added.

Re:Wow

[Anonymous Coward]

The OS it runs on is.

Re:Wow

[Anonymous Coward]

Often the system IS airgapped... and then they use a USB key to transfer the reports.

That's why USB keys were targeted for infection.

Re:Wow

[denobug]

Our past experience indicate the IT staff does more damage to the stability of the system than anything else could. Most IT and network personnel has zero understanding of reliability of a system. The architecture they design are simply too complex and not robust enough. So before anybody can hack in, the system itself becomes unstable, crashed, and end up causing dangerous situation.

One of the most common mistake observed is a super complicated VLAN scheme that link multiple network together under the name of "ease of management" or "security", while in fact the first thing they need to do is to completely seperate the control network with corporate network, and then flatten the control network with air-gap from the corporate network. Also make sure you have zero wireless network access to the control network would be a wise choice not only in security but also improves each component's availability in general.

Again, common sense goes a very long way.

Re:Wow

[DarwinSurvivor]

What is the point of a password if it's written in the owners manual of every person that has ever worked on a similar machine? At that point, you may as well call the communications API a "password".

Re:Wow

[networkBoy]

This is manifested in the door security where I work.
We have RFID badge readers.
My boss recently wanted to add one to a lab he controls. When he found out the bill was $10K he balked. We told him it was for the security conduit (intrusion detection conduit, I assume gas charged & detect pressure drop in a leg?).
His response? We don't need the conduit, just run the wire.

Luckily security said F off and use a key lock, we're not installing it without the conduit. But that same attitude is why these machines still have the default passwords.

-nB

Re:Wow

[thegarbz]

You clearly don't work in the process industry, nor have an idea of just how bullet proof a proper setup actually is despite there not being an airgap.

The ability to quickly and easily read values from the PLC remotely (one way only is the key) is paramount to not only the efficiency of running the plant, but sometimes the safety of the plant itself. Sometimes it goes a step further to even be a legal requirement. If a plant is levelled by a huge explosion you don't want to be the one standing in front of congress telling the people that the reason you have no idea what happened is that you didn't log every process value on a computer offsite in realtime.

Air-gaps are like the idiots guide to security. Yeah it helps, but it's impractical and there's so many other ways a competent person can secure a process network from the outside world. If you actually worked in the industry the lengths you see many companies go to will blow you away.

Re:Wow

[aggemam]

Mac OS X: http://www.apple.com/downloads/macosx/games/role_strategy/foxminesweeper.html
Debian GNU/Linux: http://packages.debian.org/lenny/xbomb
FreeBSD: ftp://ftp.internat.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/games/xdemineur-2.1.1_1.tbz
Windows Vista: http://windows.microsoft.com/en-US/windows-vista/Learn-about-Windows-games

HA!

Re:Wow

[ScrewMaster]

Our past experience indicate the IT staff does more damage to the stability of the system than anything else could

Agreed, with all your points. Over the past couple decades of doing control systems, one of the most common questions I get asked by engineering is "how can we best keep IT off our control network?" Funny ... the engineers in charge of these things just seem to intrinsically understand the risks of letting IT staff anywhere near a live process control system. Now, before you IT support people get all testy, I'm not saying that you are, as a group, necessarily incompetent within your legitimate purview. However, as Dirty Harry once said, "A man's got to know his limitations" and it's very disturbing to me how many of you are incapable of recognizing where your involvement is a liability. I've been accused of installing "rogue" systems by IT staff, simply because I recommended that a control system not be placed on a company's regular network. Thing is, a failure on an office network is an inconvenience. A failure on an engineering network can be a disaster. Keep that in mind next time you insist that engineering's systems should be under IT's thumb, and subject to whatever corporate "standards" are in force, regardless of their impact.

Re:Wow

[Anonymous Coward]

You do know that factories are staffed by engineers and workers, not IT pros?

In this particular case it doesn't matter if there's a factory full of IT pros (as, in fact, we do) or not. First of all you can't change the WinCC password. Second of all, if you don't do precisily as Siemens says Siemens raises hands and says "we can't support your non-standard environment".

As my coworker said, Siemens should burn in heck for its sins.

Posting anonymously, just in case.

Re:Wow

[Rich0]

Now, is the door more secure or less secure than it would have been if you had run a card lock without the special conduit?

Regular wire for the card lock would have been more vulnerable to sniffing or replay attacks, but that is a vulnerability the RFID cards probably have as well. On the other hand, an old fashioned key lock is vulnerable to extra keys floating around that aren't tied to a specific person so they can't be disabled as people change jobs/etc.

I've seen this problem at work - anybody can point out a problem, and when something goes wrong claim "see, I told you so." The problem with this logic is that if EVERY problem like this were completely risk-mitigated we couldn't do anything without spending a million dollars. That usually means that we end up using archaic processes (since this logic seems to only be employed when changes are made - you can keep running an old insecure or problematic process for as long as you want without complaint), and usually that means even more problems and certainly less efficiency.

Security in most corporate settings will always be a compromise. Sure, we have to do due diligence. Yes, we ought to secure things as best we can when it is practical to do so. Yes, sometimes we need to spend more and REALLY secure things. However, if you want to turn your factory into a hardened military facility be prepared to spend money more on the lines of the US defense budget. Indeed, I doubt that most munitions facilities incorporate all the security features the latest security consultant to come by would advocate.

Re:Wow

[MartinSchou]

Now, is the door more secure or less secure than it would have been if you had run a card lock without the special conduit?

That's besides the questions. The question that needs asking is:

Would a physical key entry result in security getting the blame, if something 'bad' happens in the lab?

The likely answer to that is: "No"
However, if they simply ran the wire as requested by the boss, and something bad happened, would they get the blame? Yes they would, because they installed and approved it.

If you want me to take the blame for something, then I want to be in charge of how it can happen. If you just want a scape goat, look elsewhere, as I have no need for a "responsible for break-in to lab due to botched security job" on my resume.

Re:Suxnet

[Wyatt Earp]

Israel, not American.

Israel has always been an industrial spy on the US and Western Europe, but their big focus is Iran right now, so they test it on the US, UK and Korea but the main focus is Iran.

Wouldn't be surprised to find it in Saudi systems too

What the?

[Mashiki]

Who is programming their PLC's? And why aren't they put into 'lock' mode(AKA ROM) when they're put into production machinery so the EEPROM can't be affected? I used to write programs for PLC's(generally Mitsubishi and Siemens), and you always locked the device or update when you were finished, so things like this can't happen.

Re:What the?

[luca]

Do you know that when you set a password on a siemens plc, it isn't enforced by the plc itself but by the step 7 programming software?
Use something else (e.g., libnodave) and access is wide open.

Re:What the?

[Mashiki]

Yeah it's a common issue with a bunch of different models of PLC's however there is a psychical write lock on the controller that can be engaged. Well that's as long as you're not stupid enough to buy PLC's without it, and that means you're spending an extra $4/unit. In the end it means that you have to either physically pull the PLC, memory card, or controller card to be able to allow writing to the unit.

Damn-you, skynet!

[SethJohnson]

Skynet just inched us one-step closer to the apocalypse by establishing its ability to assemble T1000 robots via CnC machines controlled by this botnet.

Seth

Re:Why is there even a default password?

[geekoid]

At the very least generate a unique default password during install.

The SCADA system where I work require a specific USB key to be plugged in. While I'm not a fan of dongles in general, for critical system they can be worth the pain.

And this is on top of physical separation and a good password scheme. And strong passwords are easy to cerate an remember.

Full ICS-CERT advisory on Stuxnet

[jofny]

is here: http://www.us-cert.gov/control_systems/pdf/ICSA-10-238-01B%20-%20Stuxnet%20Mitigation.pdf Probably a little more accurate than crappy media reporting.

Re:Suxnet

[formfeed]

Obvious American intelligence tool. Why is it in North American plants?

Because Major Carter found the worm, and last night she reformated all American PCs.
She's quite good, you know. I've seen it.

Not about "default passwords. Worse.

[Animats]

This has nothing to do with "default passwords". It's worse than that. The Windows-level part of the attack was signed code signed with a Microsoft-issued key. The signing keys involved has been revoked. US-CERT isn't saying who had them.

At the controller level, Siemens has issued a bulletin: Previously analyzed properties and the behavior of the virus in the software environment of the test system suggest that we are not dealing with the random development of one hacker, but with the product of a team of experts who must have IT expertise as well as specific know-how about industrial controls, their deployment in industrial production processes and corresponding engineering knowledge. ... The behavioral pattern of Stuxnet suggests that the virus is apparently only activated in plants with a specific configuration. It deliberately searches for a certain technical constellation with certain modules and certain program patterns which apply to a specific production process. This pattern can, for example, be localized by one specific data block and two code blocks. This means that Stuxnet is obviously targeting a specific process or a plant and not a particular brand or process technology and not the majority of industrial applications.

So this is an attack on a specific industrial plant. But whose? Neither Seimens nor US-CERT is saying.

This is cyber-warfare. Someone is trying to sabotage a specific plant somewhere.

Re:do any industrial controller have online drm?

[networkBoy]

yes.
Our CNC uses an on-line DRM.
We have it on its own network behind a proxy server that only allows it to connect to the manufacturer's URL, and at that only to the authentication server address.

Fortunately the manufacturer uses SOAP on port 80, so that makes the filtering easier.
-nB

Re:Not about "default passwords. Worse.

[sapphire wyvern]

There are indications that the target may have been the Bushehr nuclear power plant in Iran, with the Russian contractor's USB drives being the attack vector into the plant's control systems. (Which are not on the Internet, despite the smug assumptions of so many posters earlier in this comments section.) There's enough information out in the wild now that anyone with access to the target's PLC code could verify the target. Obviously this means the attack targets will be able to prove that the trojan was targeting them, but I doubt they'll be announcing the fact to the world - unless they can trace the attackers and gain political advantage through an announcement.

It seems the evidence currently leans towards a probably Israeli or possibly US cyberwarfare attack on Iran.