Why PLCpwn Is Important for ICS Cyber Weapons

adversaryAfter hearing about PLCpwn, S4 vet Jake Brodsky over on SCADA Perspective wrote “Only problem: If you have physical access to the network of a PLC or to the PLC itself, you own it. End of story. That’s very unlikely to change.”

While the ICS community still is stuck in the mud dealing with insecure by design protocols, applications and devices, the offensive effort on ICS cyber weapons is ramping up. And we need to start thinking about how these ICS cyber weapons will be created, deployed, used, defended against and detected. This was what ICSage on Friday of S4x14 Week was all about.

A large portion of the threat actors to critical infrastructure ICS will simply attack the system as soon as they can get access and launch an attack. For those threat actors, I agree with Jake that the concept behind PLCpwn is a non-factor.

Now imagine you work for a government that is all excited by Stuxnet. The order comes down that you need to develop the capability to take out selected parts of numerous potential adversaries critical infrastructure via a cyber attack. But they only want the capability to do it whenever they give the order. They have no immediate plan to use it, and they may never use it. Many weapons that are developed and staged are never used, so why wouldn’t this be true of ICS cyber weapons?

In this case preparation and persistence are key.

Preparation is necessary to develop the attack code not only to compromise the SCADA or DCS, but also to change the process in the desired manner. Maybe only a short term outage is required to be timed with a kinetic attack. Perhaps they want hard to replace equipment in the process to be damaged to take the system out for months. The team responsible for the ICS cyber weapon needs to develop and deploy the weapon to be ready when the order comes.

You also will want your own communication channel to the ICS cyber weapon. If you rely on the adversary’s network to send the GO signal to launch the attack it may not be available. Pulling all external connections is in many organizations’ plans to an increased threat environment. Your tasking on what needs to be done to the process might change causing you to modify the attack code. The ICS engineers may change the process in a way that requires the attack to change.

There are many reasons why an attacker wants his own communication channel to the ICS network. This second communication channel is the purpose of PLCpwn proof of concept. Sure it can attack the PLC it is inserted in, but it is also a rogue computer under the adversary’s control on your network.

Stephen’s demonstration that it took less than 80 hours and a few thousand dollars gets some attention, but this is a non-issue. A true offensive effort is going to develop a slick board that will be much more difficult to distinguish from the real thing. This is a small amount of money and effort for a well funded and motivated group. It was fortuitous that the NY Times published an article the week of S4x14 on an NSA program on developing their own communication channel to targeted computers.

Now the interesting question is what happens when organizations and governments stumble across one of these deployed attack systems and covert channels?

4 comments to Why PLCpwn Is Important for ICS Cyber Weapons

  • If a nefarious actor has access to the PLC or its network, he has access to the I/O wiring and all the switches, adjustments and everything the process has. Forget about the automation equipment, the PROCESS is compromised. Game Over.

    Next, need to look at where most PLC equipment is mounted. Like many others, ours are mounted in large steel cabinets. RF has a hard time getting in or out of these cabinets. This is by design so that hand-held radios, phones, and powerful low band VHF radios in company trucks (100 Watts Simplex, no infrastructure required) can not affect the process. The attacker would have to know when the cabinet doors would be open. Company practice is to keep them closed when nobody is working in them. You never know when someone is going to accidentally hose down the control cabinet (yes, it has happened).

    That said, there is a certain level of auto-discovery in most controllers that I do not like. In many controllers, you plug a card in, (or on to a network) and it is automatically recognized and inserted in to the scan of the controller. Nevertheless, anyone fiddling around with PLC gear is should already know the I/O that is supposed to be there. Those who do not know such things have no business fooling around with this stuff. I don’t see the utility of auto-discovery on a PLC except as a marketing tool.

    Dale’s proposal to have I/O cards, protocols, and application software with some sort of signatures on them is where you start treading the fine line between security and maintainability. This is where you ask if a sleep deprived, stressed out, engineer who usually works somewhere else could be reasonably able to recall/locate the keys and install them on the replacement card following damage by flood or fire. Some will look at this sort of problem and say “No, we’re not going there.”

    The primary goal of a control system is to help maintain availability and product consistency. Complex security features are welcome to the extent that they help achieve that goal. I am not denying that cryptographic signature features might be useful to some, but they’re clearly not for everyone. Quite often, physical security is pretty much the only practical option.

    All that said, I think the scenario of discovering such a device in a PLC would be an interesting table-top exercise between ICS-CERT, various intelligence fusion centers, the FBI, and a utility. I have some pretty good notions of how to deal with the incident, but I’m not sure there is enough experience or understanding available. An exercise like that would highlight some areas where improvement is needed.

  • From a defender’s perspective, I don’t see what would be so difficult about detecting RF signals once that you bother to scan for them

  • Ralph, there are some RF signals that, unless you know to look for them in advance, can be very difficult to detect. If you modify a spread spectrum signal to something less standard, they can be very difficult to spot.

    Conversely, if you don’t mind a very slow data rate, one can hide a narrowband signal in the noise.

    Furthermore, in most countries, even the US, it is illegal to monitor cell phone traffic on the air. Obtaining a receiver or surveillance test equipment usually requires a license or permit of some sort. Even if these issues weren’t much of an obstacle, finding people who know enough about RF to use a system like that effectively is not trivial.

    But, I’ll bet it would be really fun to build one…

  • No need to build one, such systems are commercially available.

Leave a Reply