SCADA Systems a Target for Hackers?

superstick58 writes "As a system integrator, I am often providing control solutions that utilize sophisticated Ethernet networks and as they say in the biz 'link top floor to shop floor.' Forbes has an article about the security issues that exist in SCADA systems. When I look back at some of the systems I have put in which include direct I/O control over ethernet and distributed HMI monitoring, if I can get access from the internet, it would be easy to bring down power for a plant or at the very least make operators in the building very uncomfortable. How vulnerable are the manufacturing centers of the world?"

Re:My view..

[Doppler00]

Are you absolutely sure? Doesn't the SCADA system connect to the internal corporate network somewhere? Don't managers want to see live plant operation data from their offices? At least the SCADA systems I've worked with have had a connection to the corporate network at some point. Usually through a dedicated SCADA system. I think in the end though, hackers don't want to actually have to buy the hardware they would need to test their methods out and if your corporate network has already been compromised, you're screwed anyway.

SCADA Systems are designed to be Failsafe

[Cassini2]

Generally, SCADA systems are not trusted. All systems have failsafe hardwired I/O that is designed to shutdown on failure. Unfortunately, the shutdowns can cost money.

I just got through getting a cell working after an extensive blast of repetitive downtime. I never did work out what exactly caused the failure, however high on my list of suspects is a router that may have been dropping packets due to excessive network load. When the router shutdown, the PLCs shutdown too. I'm just not clear on what caused all the excessive error packets on the network ... I have lots of theories, but no evidence.

These SCADA networks are designed to be operated in a fairly secure environment. They can't withstand errors or high network load. Botnet attacks, virus outbreaks, or someone hacking in can cause trouble. However, mostly I worry about much more mundane causes of downtime.

Microsoft Windows updates, particularly XP SP2, are notorious causes of SCADA system problems. Automatic installation of anti-virus software that triggers system reboots causes system to shutdown unexpectedly. Employees installing CPU-intensive screen-savers also cause headaches. Unexpected system changes result in unexpected system shutdowns. These unexpected shutdowns are what cause the economic disruptions.

Personally, I wonder how much longer we can deploy Microsoft Windows as a SCADA platform. Fast, simple and straightforward are key system goals for SCADA applications. Vista, which effectively requires networking, is a step in the wrong direction. Linux is much more secure, and can easily be set up with read-only partitions. Read-only memory seems to make the systems much more stable, as every reboot always reloads a secure, known-correct program image.

Wow, what an awesome opportunity for a shameless p

[Anonymous Coward]

I happen to be a developer who is working to protect SCADA systems.

Because the systems are what they are, we are protecting them by putting protective devices in front of them -- either sitting behind a device on the phone line or sitting behind a protective router. Then, the lack of security in SCADA devices will be largely irrelevant, since you can't hack a device you can't access. It would be a matter of hacking into our devices, which are designed with a bit more security in mind.

I dread the idea of seeing our company name showing up in some hacker conference, but I'm kinda eager for some black-hat-vs-white-hat action.

Re:Hacking SCADA makes sense

[Svartalf]

Forget manufacturing plants...

What if you could easily reproduce the East Coast Blackout of 2003 at will?

Hacking SCADA systems can do that for you...

Heh... What I could tell people...

NT4? Luxury!

[Anonymous Coward]

> I know of many, many plant floor locations at some very large manufacturing facilities that still run NT4 on various devices.

We're running DOS here. Yes, DOS. Version 6.3, I think... I haven't really bothered to check.
It does make them hard to hack (or access...) remotely, though.

Re:Large scale SCADA often uses the internet

[tropicdog]

I've got a little story to share, a real world, actually happened example. Just a few years ago I was working as desktop support at a manufacturing plant. Facilities maintenance decided to place a web cam on top of the building so anyone could "check the weather." This was part of some project where environmental status of different parts of the facility was available through an internal website.
Who knows why they thought this was necessary but, they did it anyway without much consultation with the IT department. [red flag #1]
They published their little website where you could check out the air conditioner status and temperature of the various parts of the building and view the webcam. To see the webcam you had to logon with a specific username/password combination which they announced to everybody via email. [red flag #2]
Curious, I checked out the site and looked around. I found that the webcam had a different URL than the rest of the site so, being curious, I shortened the URL down one level at a time and ended up at a system administration logon page. [bad sign #1]
Surely the username/password for the webcam wouldn't work there so I tried it and promptly logged onto the facility controls console. [bad sign #2]
Surely I would only have limited or read only access so I checked out some of the features and areas of the console. I was able to access everything from heating/cooling, water, lighting and the factory waste handling system controls. [very bad sign #3]
Again, surely I had read only access so I tested one of the settings for the air system in our area of the building. I incrimented the value by 1 and clicked "save". It accepted my change. I changed the value back to it's original setting and saved it again. [VERY bad sign #4]
At this point I notified my supervisor that there may be a problem and showed him what I was able to do with the username/password that everybody in the company now had. A hasty meeting was called that day with myself and the head of facility management. I told him what I had found and we had a meeting with the vendor who installed the systems the next day.
In between the meetings, I checked out some more features of the controller system and found that I could ssh into it with the same password and username. The system ran a very stripped down Linux kernel and only had a few applications but I was able to add or remove or edit files from any directory on the system. So basically, the webcam username/password was effectively root on the whole system.
The installer was a typical heating/cooling installer type of guy. [red flag #3]
Computers obviously weren't his area of expertise. I understand that the company has people who "should" know about these sort of security measures, their developers. Why they sent a mechanical type of guy when they were told what our concerns were, I don't know. [red flag #4]
The scary and probably typical reaction I got from the vendor's installer was that there wasn't much of a problem because nobody in the factory would surely think of shortening a URL and find the main systems control login. [big red flag #5]
I finally got my point across and the vendor agreed to work with their developers to figure out a more secure setup. Fortunately the facility manager fully understood the consequences and wouldn't accept the vendors attempts at suggesting that it wasn't an issue.
Most everybody would think that simply changing the password would do the trick but apparently their setup was hard coded to only accept the one username and password for the whole system! At least that's what we were told at our meeting. To access the published webcam that was tied into this mess, you had to use the same credentials, otherwise none of this little setup of theirs would work and the administrative console would loose it's ability to monitor and control the factory systems. Brilliant! Absolutely genious.
Well, at the end of it all, apparently their developers had some sort of actual CLU

Re:My view..

[gsogeek]

I worked as an intern for a municipal government IT department a while back, and had to do a site visit to a water filtration/pumping station. While I was there, I wandered down to one of the areas where the machines were that ran the pumps, valves, and other sundry devices. I found the workstation where two computers had been installed, one on the network to allow employees access to email, the intranet, and the internet. Beside it was another computer, which controlled the SCADA system for the plant and had root access to the entire city's water and sewer SCADA system. The plant manager assured me that they were totally seperate, and never the two should mix. Well, imagine my shock and surprise when I walked past the desk and tripped over a bright yellow patch cable that ran from the second (standby) network card into a small hub, that also fed the public terminal and then went to the internet port on the wall. I made a few notes, checked a few log files, then went and told the manager that the hub had to go and went back to the main IT office and reported. The answer I got? "So what? What could someone do with that?" As a demonstration, I took my noted, typed a few commands, and put a few nice words on top of the Wunderware logo on the terminal, then told the plant manager, who was still saying this was impossible, to check the screen. Turns out, an employee in the plant decided it was too much trouble to go between the computers, took the hub from a conference room upstairs, and made the connection. I wonder what might have happened if I opened that Cl2 valve or maybe closed a high pressure sewage line at the treatment facility? The weakest link in these systems is not the SCADA systems themselves, so to speak, but the people that use them daily, and managers that don't bother to look at the equipment on a regular basis, just to make sure it still looks like that nice drawing in the office.

Easy as pie

[Anonymous Coward]

SCADA systems are incredibly vulnerable. Anyone who "Calls Bullshit" or whatever else they'd like to say just doesn't know what they're talking about. SCADA systems _have_ been compromised. Comrpromising them is _easy_ if you can get access to the network, as 99% of the protocols are clear text, snoop the wire for a while to decode the protocol, then do some simple replays to take control. Or easier yet, just take control of the HMI. If you do it right no one will even know.

Or too impatient for that? Try attacking one of the wireless SCADA networks, yes, critical infrastructure like gas pipelines running over "wireless."

So far the biggest thing that has kept them secure is people in the mainstream hacking community simply haven't known they exist. But that's changed. Keeping SCADA systems seperate from "Corporate" systems isn't easy for most utilities as they simply don't have the money to invest in dual infrastructure, or they don't know what they're doing so don't, or management (as usual) as full of nitwits so wont trump up the cash...

DHS has a Control Systems Cyber Security program which may have interesting reading for the curious, also see INL labs which do a lot of work on hacking SCADA systems, and NIST has some big put-you-to-sleep style doco on standards around SCADA security.

Cheers
e

This has been done for years

[billsf]

The right way: As simple as will get the job done. Its been used on the space shuttle since the beginning. When you hear the three computers agree, this is three 1802, a 1MHz 8-banger that was approved for this 30 years ago. The other "certified perfect" piece of hardware is the i486. Sure a few more may have been added, but nothing 'hi-tech'.

What kind of line speed does it take to say, control the dijkes. This is not the place to say _exactly_ how its done, but I'm not afraid of a break. Trains are the other extreme, you need a real computer. The embedded boxes that take the measurements are simple in design, a PIC or 1802, a world favourite in payphones.

Going on the net can't be all that bad, but as one writer noted, thoughtlessly designed systems lock out the rightful user. Of course, never run ssh on port 22 and if life is on the line, a telephone backup must be used. "Fuzzing" is over rated, sure it crashes poorly designed systems, but well designed systems would have to be flooded quite fast to prevent a 'distress signal'. (Upstream the networks are well monitored.) I will always remember the first security lesson from a German professor: Rule No.1 NO Microsoft products!

My biggest fear is the possibility (actually quite easy) of spoofing an IP of a rightful owner. These addresses must either be secrets or rotated often, preferably both. Still a dedicated network, where management can only look and then pick up the phone is almost mandatory if human life is at stake. True fast hopping radio can be most secure, stealth and 'unjamable'. Fibre is secure too.

It is rather remarkable with this publicly known for years and even popular music (figure out that yourself) telling how to do it, it hasn't been a problem. Broadcast and cable is totally vulnerable, though breaches rarely occur. It is rather commonplace to control a TV sender through a DTMF telephone: Would you know what to do if you got in? In a real war, things could go from bad to worse. Social engineering would be a primary tool. (Could anything be easier to social engineer than the military?) Loose lips do bad things. Its all about logic to do it right. Its scary to see sysadmins use Windows for stupid reasons like: "It works best on my laptop". Then don't use it for anything else!

It is so often when doing a security audit, you hear: "I let my kids play games and surf the web". On company computers that do important things. Damn. Don't use Windows and keep your computer to yourself.

BillSF

Don't hack the SCADA, hack the PLC

[Anonymous Coward]

Most automation systems have a PLC controlling the hardware. The SCADA is just the UI to the control system.

A PLC is a (generally) unprotected, unencrypted proprietary ethernet connected box. The only protection is that it is proprietary, but that protection has been diminished now that most are connected to Ethernet.

The interlocks etc that people are talking about above often actually reside in the PLC. You don't need a password to manipulate the memory in a PLC. Just a write command using the standard protocol for the PLC will do it.

SCADA PLC Hardware

The major manufacturers have not bothered to protect access to their PLC's, and with the recent Ethernet revolution in control systems, this makes them very vulnerable.

The majority of control systems I have seen are completely unprotected once you get onto the LAN. Unfortunately there is an attitude that it will never happen to us.

I have no experience in big oil or in power stations, but I have seen this problem in some airport operations, and industrial automation in general.

Hardened automation devices are just not demanded of PLC manufacturers by their customers, as they are not aware of the risks.

Disclaimer: I've been out of the industry for a couple of years, but the industry is very slow moving, so I doubt much has changed.

Re:My view..

[gnalre]

Nice idea in theory, but there's always a push to allow such systems to be accessed remotely for example performance monitoring. By saying never you are ignoring commercial imperatives. It is better by acknowledging it will happen and put in the infrastructure and practices which will make it as safe as possible.

For example we deal with ship control systems, which you may think are about as isolated as you can get. But there is a big push to allow remote access for such things as predictive maintenance, performance monitoring, fault diagnosis(difficult to send an engineer to a platform a 1000 miles from land). Therefore we have been as paranoid as possible when designing the access, but its a tough job to second guess hackers(in the evil sense of the word)

Re:My view..

[Zipster]

I am in the mining industry and yes, managers do want to see live plant data. The way we do it here is the only place that the process network and the admin network get close to each other is in a locked cabinet. Inside said cabinet there are two small industrial switches VERY clearly marked. We, like much of the oil/gas and the mining industries, use a data historian on the admin network. The data node for the historian sits between the two and only passes the data that it has been told to pass by the sys-admin. For managers to get the data the only place they can get it is from the data historian, not from the node and not from the process network. Whilst it would be possible to configure the nodes to forward packets from one network to another, our last risk assessment determined that the chance of this happening was low (we have full control over the data node, no one else has access, not even server-ops or network-ops). We review this about every 6 months and if we ever feel the risk is too high then we would take further steps.