SCADA Hacking Renders Vital Infrastructure Vulnerable recently had an article called “America’s Hackable Backbone” regarding the recent surge in SCADA hacking. SCADA, Supervisory Control And Data Acquisition, is a truly ancient protocol, in use for over 20 years, which was not remotely designed with security in mind. At the time, SCADA was used only on dedicated networks that lacked any connectivity to a network to which you could attach a general-purpose computer. Thus, the security it relied on was a combination of physical security — you needed to tap a line to get in — and obscurity — if you did get in, you’d need to both know SCADA and know the particular “magic names” of the devices you were trying to control.

I saw Ganesh Devarajan’s presentation on SCADA hacking at DefCon back in August. The protocol is relatively simple — simple enough to figure it out just running a sniffer for a while. And the things controlled by these systems can be utterly critical — nuclear power plants, subway systems, pipelines, manufacturing plants, etc. Some of what Devarajan demonstrated was attacking through simple fuzzing — just throwing masses of junk data into the systems and seeing what happens, since the input (presumed to come from trusted sources on a private network) is seldom validated. When fuzzing makes something fall over, that’s almost certainly a sign that a buffer overflow vulnerability lurks there — so even if you can’t stop the subway with a SCADA command, you can probably execute arbitrary code with one, and that can do anything (though it is, admittedly, significantly harder.)

However, as Forbes points out, you don’t need to really know how to control the system to extort ransom out of someone — the mere threat of controlling, say, a water treatment plant may get you what you want.

Fixing these systems normally requires replacing them — they’re so old that updating to a more modern system is seldom an option. Likewise, encryption is a decade out of reach for these systems. At the very least, they need to be completely isolated — a computer that can access a SCADA system should not be connected to a computer that can access the Internet. This creates a potential path for an attacker. Unfortunately, companies are moving in the opposite direction — rather than replacing and isolating SCADA, they’re wrapping it in XML, so that modern applications can use web services to manipulate SCADA systems. This makes sense from a usability perspective — just because your oil pipeline’s valves use 20-year-old control software doesn’t mean your engineers have to be working on 20-year old green-monochome-screened DOS boxes to operate them. However, from a security perspective it makes things even worse. The machines running these apps are on corporate LANs with Internet connectivity — and hacking SCADA wrapped in XML is every bit as easy as hacking raw SCADA. Putting something in XML doesn’t render it more secure — indeed, the accompanying metadata often makes it easier to decipher.

The real worry of these systems is that as the SCADA networks become more integrated with the Internet (SCADA over TCP/IP is already normal, and SCADA over XML is growing), we come closer to a world in which those action-movie scenarios where a hacker breaks into a computer and starts blowing up power plants, manipulating traffic lights, etc. are actually possible. Right now, “hacker terrorism” is mostly a financial threat — there’s little you can do to life safety from an Internet terminal most of the time. It would be preferable to keep it that way.

hardware, risk, SOA/XML, terrorism

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.