We have often pointed out that contrary to common belief, an attacker needs zero insider information and zero programming skills at the controller level in order to perform a Stuxnet-inspired attack against control systems. How would that be possible? Here is an example of a very simple generic attack that uses less than twenty bytes of code to achieve a calendar based loss of control; a basic logical time bomb. It’s also the most basic copycat attack that a Stuxnet-inspired attacker could come up with – and yet achieve dramatic effects.

Let’s recap what anybody who technically analyzes Stuxnet can learn from the masters of PLC hijacking:

  • How to inject rogue code onto Siemens controllers
  • How to make sure that the legitimate controller program code continues to execute
  • How to execute rogue controller code condition-based
  • How to take away control from the legitimate controller program.

From all possible attack vectors against PLCs, code injection is one of the more aggressive for several reasons. Once that the controller is infected, the IT part of the attack is no longer needed. Therefore, the attack is executing standalone even if all IT connectivity is disabled. PLC access and compromise only needs to be done once, requiring network traffic that takes just seconds.

At first sight, items two and three of the bullet points above may appear like a miracle because a controller is a single-tasking system. Within such a simple environment, how could one achieve to get an additional code sequence in place that runs quasi in parallel to the legitimate code, and at some point in time disables the legitimate program for deliberate periods of time? The developers of Stuxnet figured out a very clever and effective solution for this problem. They simply injected their code at the very beginning of the main sweep (OB1), in front of the legitimate code. Thereby rogue code is called at the beginning of every cycle, and that rogue code can decide anytime to disable legitimate code by simply calling a BEC (block end conditional) directive. The BEC directive results in code execution jumping back to the beginning of the operation block, thereby skipping and effectively disabling any code beyond the BEC directive. The attacker has total freedom in defining a condition that would trigger the jump to the beginning. In Stuxnet’s case, the condition was based both on timing and on process conditions.

How much insider knowledge would an attacker need in order to write rogue code for a significant attack, and how complex would such rogue code have to be? The answer is quite simple: The most basic and still effective attack uses ZERO lines of code for manipulating outputs, therefore requiring zero insider knowledge. It simply freezes outputs by doing nothing. (IT folks could think of it like performing a NOP directive in place of legitimate program code.) Here is why that’s quite a banger for process control. The physical process that is controlled by a controller operates in realtime according to the laws of physics. Now if the controller’s electrical outputs are frozen, the mechanical, hydraulical, chemical characteristics of the process don’t freeze too – they simply run wild, out of control. So for example drives continue to rotate, pumps continue to pump through valves that continue to be open – a recipe for creating scrap product and material damage. If this occurs not only at one station (= controller), but at multiple stations simultaneously, it is easy to end up with damage that might take the victim days to recover from.

In order to explain how easy this can be done, let’s see how this translates into controller code. Here is some sample Step7 STL source code:

L     LD    12
L     DW#16#11122500
>=D
BEC

Four lines of code, that’s it. As a trigger condition, the present date and time is used in this example. For every call of OB1, the execution environment passes the present date and time as a parameter on the stack, so no system function call is needed. In our example, the trigger condition used is Christmas Day 2011, which is simply loaded into the accumulator alongside with the present date and time. Thereafter, a comparison is done. As soon as the controller’s internal clock goes to Dec 25, outputs are frozen because the BEC directive skips execution of legitimate control logic. Certainly an attacker can use any date and time he wants to, depending on the message that is going to be communicated, or he can simply use a random trigger condition that might even be reset after several seconds, thereby making the attack more stealthy and maintenance engineers going crazy.

After compiling the sample STL code shown above, the following MC7 byte sequence results:

7E 63 00 0C 38 07 11 12 25 00 39 A0 05 00

Now all the attacker has to do is to insert these fourteen bytes in front of the legitimate program code in OB1. Stuxnet is exploit code in the wild that shows how this is done. The copycat attacker just has to isolate the sequences in Stuxnet where OB1 code is downloaded from the controller, and where it is uploaded to the controller. The upload would simply prefix the downloaded image with the byte code shown. However, a lazy attacker wouldn’t even need to analyze Stuxnet’s operation in order to copy the attack vector; it’s sufficient to understand the concept. Thereafter, the required network communications can be analyzed simply by experimenting with the vendor’s engineering software.

When implementing such an attack, a Stuxnet-inspired attacker from the hacker community would most likely not even think about using the vendor’s driver DLL (s7otbxdx.dll). Anybody familiar with Wireshark (most hackers are) would simply monitor network traffic between the engineering software and the controller and implement a custom load module that does neither require the vendor’s driver DLL nor the presence of the engineering software in the victim network. As demonstrated recently and promoted at hackers’ conferences, hackers are becoming aware of these vulnerabilities and might soon have Metasploit modules with basic functionality available, freely downloadable from the Internet. We encourage asset owners to not just sit and wait until that happens.

 


 

Discover What OT-BASE Is All About.

Figuring out if OT-BASE is the right tool for you is an important task. Learn about the platform and how it enables control engineers, threat hunters, and OT maintenance to achieve more in less time.

LEARN MORE ABOUT OT-BASE