How to Hijack a Controller

Why Stuxnet Isn't Just About Siemens' PLCs

2 of 2 1 | 2 > View on one page

Some have speculated that the attackers' goal might have been to send out a message, such as, "You are vulnerable. We can take over control if we wanted." From code analysis, this theory can be ruled out, since the attackers could have achieved this goal with far fewer man-months of effort. For example, a simple code injection in OB 1 would have been enough to make that point clear, perhaps with a string-coded message such as "gotcha." Code analysis makes it clear that Stuxnet is not about sending a message or proving a concept. It is about destroying its targets with utmost determination in military style.

A Generic Attack

Another assumption about Stuxnet that should be corrected is that it would require extreme insider knowledge to repeat a Stuxnet-like attack. For control system engineers, it is easy to understand why this does not hold true. Even though Stuxnet as such is not a generic attack on control systems, several parts of the attack in fact are generic, and these generic parts are easy to copy. With these generic attack techniques at his or her disposal, a follow-up attacker may not only implement a similar targeted and surgical strike, but may choose to create widespread, random havoc, using any vendor's controller. In order to understand how this could be done, let's look at the generic attack parts in detail.

First of all, there's the code injection. It is the major prerequisite for hijacking a controller. We would not need to care much about the other attack techniques if the code injection didn't work, because rogue code would never be called, even after having made it onto the controller. A would-be attacker who studies Stuxnet long enough will be able to determine how the code injection is done. After being able to inject code into any of the operation blocks, the attacker is in business. Injected code may now perform specific process disruptions using insider knowledge, as in Stuxnet's case. However, it may also perform a generic attack with zero insider knowledge. For example, injected code may simply delay or stop the process, for example, based on timer triggers or just randomly.

Second, there are the system function hooks. Hooking functions such as DP_RECV can be used for some very nasty attacks that can be extremely difficult to detect. For example, an attacker can simply modify values that are then passed along to the legitimate program some of the time—either triggered by a specific time of day or randomly, causing legitimate process logic to respond to false process values.

This is not done by Stuxnet, but Stuxnet demonstrates how the system functions can be abused. Before Stuxnet, few people would have even thought about illegitimate code in controller system functions.

Third, and most important, there is the full-blown, man-in-the-middle attack on the 417. It works on any S7-400. This attack alone, without any further targeted output manipulations, would cause havoc in most installations, since the legitimate program would no longer respond to sensor value changes. Alarms will not be triggered, and operators will not take action until disaster has struck. The man-in-the-middle attack should be reason enough for all asset owners to thoroughly re-check their safety instrumented architectures.

Once that these generic attack techniques are implemented in exploit tools, which are sometimes referred to as "penetration testing frameworks," all bets are off. Mitigation of any of these exploits is very difficult, and this is perhaps the worst news about Stuxnet. Protecting against Stuxnet-inspired attacks takes time, effort and money.

It has often been argued that a defense-in-depth approach would be the best mitigation. While defense-in-depth certainly doesn't hurt, it must be acknowledged that it does not help to prevent or even recognize controllers compromised by authorized engineering stations. The most effective prevention of controller hijacking would be digitally signed controller code and configuration. With today's technology, this can be implemented easily. It can be expected that controller vendors will see this as a major business opportunity because the outlook to replace millions of controllers before end-of-lifetime with upgraded product versions means a multi-million dollar market. Less efficient, but much cheaper solutions have just become available that detect and report configuration and code changes of network-attached S7 controllers.

Ralph Langner is the principal at Langner Communications,  Hamburg,Germany,

2 of 2 1 | 2 > View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments