Bad News for SCADA - Stuxnet gets Scarier

Over the past two weeks, there has been considerable progress in determining exactly what industrial process Stuxnet’s creators were trying to destroy. This news is not good for the industrial control system and SCADA communities.

First the Symantec team announced that one of Stuxnet’s payloads was designed to change the output frequencies of specific Variable Frequency Drives (VFDs) and thus the speed of the motors connected to them, essentially sabotaging the industrial process.

Then a few days later, Ralph Langner reported that the worm had a completely different payload for a second target, which he believes is the K-1000-60/3000-3 steam turbines in the Bushehr nuclear facility. The existence of this payload has been known for some time, but what it did was only discovered by Ralph in the past weeks.

The new code is very scary. I won’t go into all the technical details – you can find those in Ralph’s subsequent blogs, but basically the worm does what is called a Man-in-the-Middle (MITM) attack INSIDE the PLC. It takes the inputs coming from the PLC’s I/O modules and fakes them so that the ladder logic works off of incorrect information. Then it tells the PLC’s outputs to do what it wants, not what the logic says.

Why Internal PLC MITM Attacks are Scary

Now MITM attacks between a PLC and an HMI are old news and easy to do. INL showed this attack in its famous chemical plant hacking videos and my students created USB-based MITM attacks that can be seen in the Youtube video by MTL Singapore.

But an MITM inside the PLC? That is nasty. Imagine you have a tank that contains dangerous chemicals under pressure. Your PLC monitors the tank pressure through its I/O and performs actions such as starting or stopping the pumps pressurizing the tank. If the tank pressure gets beyond a certain critical level, it shuts off the whole system and sounds an alarm.

Now along comes the Son-of-Stuxnet (SoS) and it infects your PLC. It overwrites the real tank pressure and tells the PLC logic that the tank is empty. The PLC responds by turning on the pumps at full speed waiting for the tank to pressurize. But SoS tells the PLC that the tank is still empty and so the pumps stay running. And should the operator notice there is a problem and command the PLC to shut off the pumps, SoS can overwrite those commands and keep the pumps running until something goes “bang”.

What about the Safety Overrides?

Of course, in any safety critical system there are always manual overrides that bypass the PLC. But manual intervention takes time and operator attention. With the increasing use of automated systems, operator time and attention are in very short supply. Worse still, many of the systems designed today integrate the process control and safety systems to save money. The implications of this are clearly spelled out in PJ Coyles’ excellent blog article:

Process professionals typically understand the risks of these overpressure events and take appropriate precautions. Process controls are designed to prevent temperatures from approaching the runaway initiation temperature. Separate automated safety controls are designed to shut down the heat producing reactions that typically are the cause for these events. Unfortunately, it is becoming more and more common for these safety systems to utilize the same process input devices, computer systems, and often the same software as the process control system as a cost control measure. Thus the compromise of process data by the Stuxnet 417 attack code could compromise these safety systems as well as the process control system.

There are no Patches

To make matters worse (much worse) Ralph (see his post) and PJ (see his post) point out that Stuxnet is NOT taking advantage of bugs and vulnerabilities that can be addressed with patches: “Stuxnet does not exploit something like a zero-day vulnerability here. It just makes creative use of legitimate product features”. These features are not unique to the Siemens product line – they are common to all modern controllers.

What it all means

As for the implications of all this to the industrial control world and everyone that depends on something controlled by these systems (such as lights, water and transportation), I will leave the last words to Ralph:

“And this is why we have a real big problem, since copycat attacks must be expected before we get these vulnerabilities fixed in the majority of systems. Chances are such copycats won’t use project names with biblical references, such as Myrtus/Esther, but with references to the Quran.” 

Read Ralph's full blog post


RSS Feed Subscribe to the "Practical SCADA Security" news feed



One very important point to consider is that the 417 S7 CPU can be used in safety applications as a TUV-approved SIL3 SIS logic solver! Ralph has provided invaluable input regarding the target of this attack, but considering that Sequence C appears to be imcomplete/disabled, there is a much large "Fear Factor" to consider with this attack sequence.

With this particular vulnerability within an SIS logic solver, this means that Sequence C could effectively be used to negate the effect of any safety instrumented function (SIF) which is supervised by the S7 417 CPU! Considering this, the potential attack surface could be much larger than just the Bushehr facility, but in fact a far larger scale attack - which would explain why it was incomplete at the time of what I believe was a premature release of the Stuxnet code.

I couldn't agree more. Stuxnet provides a perfect proof of concept on how to write code that breaks our core assumptions on how SIS logic solvers work. Unfortunately I don't think that the safety world has realized this yet.

I also see that Ralph has changed his mind on the target for this code. He now believes the 417 was controlling the overall cascade system at Natanz. See for more details. It is not clear to me if this 417 was a true safety controller or just a supervisory controller, but I am sure Ralph will figure this out as well.

Add new comment