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?"

Comments

Hacking SCADA makes sense

[EmbeddedJanitor]

Being able to blow up physical devices is a lot more spectacular than playing with numbers in bank accounts which can be resotred from backups.

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...

My view..

[The Living Fractal]

I work in Big Oil. We have SCADA systems, we have an HMI to control the facilities, and it's all ethernet based. But the network is on a completley different wire than our internet-accessible network. You can't connect to the internet from our control network -- the wire simply doesn't exist.

And it shouldn't. They should stay separate. Period.

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.

Re:My view..

[Anonymous Coward]

Wow. Must be nice to have all your equipment on one site, or spread out along a pipeline that you own.

Some SCADA systems control diverse infrastructure scattered across areas bigger than any US state. As far as comms go, it's PSTN or nothing for places like that. Hard to keep your network scrupulously separated when you have to dial in to the remote sites!

Re:My view..

[Kadin2048]

Well, unless it's some proprietary VPN protocol, you could just use a different client program that wasn't as strict about not letting you do things like bridge it. As long as you have the key, there's not a whole lot to stop you.

But I think what the GP was getting at was the risk of somebody having a workstation in the plant, somewhere, that's connected to both networks. If you have two NICs, and have the process-control network plugged into one, and the regular internet-accessible LAN plugged into the other, it's trivial to "accidentally" bridge them together.

Alternately, they could both just get plugged into one router or switch, and suddenly there's a path between them. A lot of weird things could happen if the two networks run alongside each other and there's not constant vigilance to keep people from doing something stupid.

In my office, we have separate subnets for different work areas. It works pretty well in terms of minimizing broadcast traffic and keeping people from accidentally printing to printers at the other end of the office, etc. But every few months they'll end up getting accidentally bridged by someone in a conference room plugging a wire from each subnet (they have separate jacks in the conference rooms, so that people can access their own area's stuff) into a switch. There's not really any malice involved -- people just see an Ethernet cable running from the wall towards a switch and notice it's unplugged, and they have a tendency to just jam it right in there.

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.

Re:Pretty old news

[doug_hastings]

Yes, Frontline did a show about this a few years back.

Re:Pretty old news

[Doppler00]

Well, lets say you are able to hack in. Would a bad guy know what to do with all those buttons and knobs without actually seeing the outcome from behind his computer screen? They would also need to retrieve a copy of the plant process diagram somehow, study it, and come up with a devious scheme to make the robots do something catastrophic. And a good safety system would have so many redundant independent interlocks, both physical and electronic, that it would be difficult to do any irreparable harm.

Amazing

[dbcad7]

A "system integrator" working on his "sophisticated systems".. I was truly impressed until the lame a$$ question.

I'll answer though ... Just hide away until after Armageddon is over, I'll find you.. don't worry... really, just wait til I say it's safe to come out.

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.

I call bullshit -- Die Hard 4 is FICTION!!!

[mangu]

I have worked with SCADA systems for the last 28 years, since I left college with an EE degree.

I have worked in two industries: electric power (both hydro and nuclear) and communication satellites.

Technologies are similar to those used in consumer systems for a purely practical reason, there's cheap hardware available. But the safeguards built into any industrial system are totally unbelievable for anyone used to consumer systems, and possibly also for people in banking or other businesses.

I once counted the redundancy levels in a transformer protection system. There were 63 (yes, sixty three) different levels of protection for a humble transformer costing a mere $5 million. Imagine the protection around a $5 billion power plant.

Possible in theory, but in real life it's more likely that you would be able to drop a helicopter by ramping a car up a toll booth.

Re:NT4 On The Plant Floor

[Cassini2]

NT4 was a nice operating system for SCADA applications. It was built in a time where Microsoft cared about security. One of NT4's design goals was Military security ratings. I liked the feature where you could tell the system to only run 9 different preset executables. It made it really tough to crack (until ActiveX and Internet Explorer came out.)

Well I build them...

[Anonymous Coward]

and at some point they're all connected to an outside connection.
Every customer my company has has a main site and a backup site. With redundancy in the main site as well (hot and standby servers, sans, etc). But most have remote clients that can connect to view data (corporate users) however maybe only 1 in 50 are actually tied in to the corporate domain. they're usually separate systems.

As far as the industry I've seen this in, oil & gas, as well as the water and waste water systems for a lot of medium size cities in north america. They also have a slew of international customers as well and the designs are pretty universal. How easy is it to break in and damage stuff? The software and protocols are all proprietary, and in fact most of the packets show up as "malformed" in wireshark. My guess is to really do damage they'd have to either be intimately familiar with the product (i.e. an ex-employee) or they'd have to find a way to take down the main site and backup site completely at once. These are always in geographically different locations.

How about Martrix?

[jsse]

I once counted the redundancy levels in a transformer protection system. There were 63 (yes, sixty three) different levels of protection for a humble transformer costing a mere $5 million. Imagine the protection around a $5 billion power plant. I saw Tiffany drove a bike into the security station, blew up everything in her path then bought down the entire power-grid by with a single ssh nuke. She did it all in less than 5 minutes.

63 levels of protection doesn't give me more assurance sorry.

But since your mentioned the plant hires Transformers for protection or something, I do believe these alien robots could stand some chance.

But of course!

[WheelDweller]

SCADA systems, until recently, weren't build with security in mind; kinda like running everyting 'root' because you have a decent firewall. I used to program them; imagine blowing open a 3', 500psi natural gas pipeline?

SO MUCH MORE fun than hanging up an airport for hours, now isn't it?

Though, I'm not sure how far they'd really get...all these devices are different...kinda like Linux boxes. What works on a Vax with a communications network to controllers will be different from site to site...and they'd need to get the nomenclature from the inside. It would still be non-trivial, and the 'testing' to learn the system might tip off the Feds.

It's like the first time someone mentioned blowing up buses/trains; if there are people involved and a spectacular media coverage, it's a target. (Shouldn't be a big surprise, actually)

Re:NT4 On The Plant Floor

[Doppler00]

Naw, it would be the same problem. Just imagine being stuck on a Linux distribution 10 years old. Who's going to support you there? You'll be immediately told to upgrade to the latest and greatest fix your problems, but then your software may not function anymore. What's worse, is that I am not aware of any popular open source programs for industrial control systems.

Re:Pretty old news

[putaro]

I don't know about that. Yes, taking control of the network and making things do what you want would require a lot of knowledge. Lots of hackers just like to "mess around" though and doing something that they think is l33t, like running a Quake server on a nuclear power plant network, could cause a lot of problems. These kinds of systems are not usually designed with a lot of redundancy at the software level. The people who build those kind of things just don't understand how to manage those kinds of things in software.

Case in point. Long ago I worked for a supercomputer manufacturer. Our system had a nifty temperature sensing and power control system that was all controlled from a small front end system, a 286 running Microport Unix. We could also do things like boot the system from that console and dial in to do remote diagnostics. I was working with a customer and he needed a patch so I started uploading it to main system via the modem link and a pass-through from the console into the main system (must have been Kermit). Things are moving along and then the main system crashes. For some reason it's overheating. OK, that's weird, we reboot and I start the upload again. System crashes again. About the third time we start putting two and two together and I go off and do some sleuthing around to figure out why that might cause a problem.

Well, it turns out that the hardware guys have the whole temperature and power control system running over an RS-232 line. Using a protocol that they designed that has no checksums, no framing, no resynchronization. And, a 286 running Microport is just not fast enough to handle two 9600 baud streams of data simultaneously and it starts dropping characters. Drop a few characters out of this unframed, unchecksummed data stream and it starts getting fan speed values (or whatever) mixed up with its temperature values and the control software thinks that the machines is melting down and turns it off - fast.

Our hardware guys were not stupid. They just weren't familiar with communications protocols, didn't bother to consult with the folks on the software side who were, and it had always worked in the lab and the field. I'm quite certain there are any number of pieces of software and hardware running around out there that would be very vulnerable to an unexpected change in the environment and the cascading effects would be incalculable.

Even if you do have safety protocols and interlocks in place, just shutting things down has costs. If you shut down a nuclear power plant, how much does it cost to bring it back on line? If you shut down a factory floor, how much does it cost you to not be producing, how much product will be spoiled and how much clean up will you have to do?

The risks are non-trivial and people believe that there networks are secure when in reality, someone probably installed a wireless access point somewhere or has a router bridging things (so that managers can look at "view only" data as one poster mentioned above) that just opens everything up.

Re:Large scale SCADA often uses the internet

[ZorinLynx]

Lots of things in life "should" be, but often aren't.

Such is laziness.

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:NT4 On The Plant Floor

[masdog]

But depending on the size of the facility, a programmer might not be cost effective. Your average IT guy might not have the skill-set to right Linux kernal patches, and even if you're a small facility in a large corporation, you might not have the same software running your SCADA system as any other plant.

Script Kiddies + SCADA...

[CompMD]

im in ur power plant retractin ur control rods