How to Hijack a Controller

By Ralph Langner

So many speculations and hot air surround Stuxnet that it can't hurt to check for some hard evidence in order not to get lost in fiction and FUD. The best source for information is Stuxnet itself and the attack code that is loaded to the controllers.

Stuxnet's controller attack code is loaded on target controllers by the rogue DLL s7otbxdx.dll, which wraps the legitimate vendor DLL. It contains three 64-bit-encrypted Step7 code sets. These code sets are decrypted and loaded by the rogue DLL when connected to matching targets, where matches are found by digital fingerprinting.

The three malicious Step7 code sets can be further subdivided into two code sets that load on S7-315 controllers and one code set that loads on S7-417 controllers. For readers not familiar with the Siemens product line, the S7-315 is a small general-purpose controller with 256 KB of memory, while the S7-417 is the top-of-the-line product with 30 MB of memory. The latter is available in redundant and failsafe variants and is used, among other applications, in power plant turbine control. The two code sets for the 315 basically do the same thing and vary only in detail. Since they are so similar in structure and functions, they will be treated in this article as one routine. The 315 and 417 attack routines, however, are considerably different.

A Stealth Control System

In a nutshell, Stuxnet can be thought of as a stealth control system that resides on its target controllers along with legitimate program code. The ultimate goal of the attack is not the controller; it is what the controller controls. Attack code analysis reveals that the attackers had full knowledge of project, installation and instrumentation details. The attackers took great care to make sure that only their designated targets were hit. It was a marksmen's job. On target, the attack is surgical and takes advantage of deep process and equipment knowledge. The attack is not performed in a hit-and-run style, where it would be executed immediately after attaching to the controller or at the next best opportunity. Instead, the attack code carefully monitors the hijacked process for extended periods of time before executing the strike. Outputs are then controlled by Stuxnet, with neither legitimate program code nor any attached operator panel or SCADA system noticing. Stuxnet combines denial of control and denial of view, providing for the ultimate aggressive attack.

The hackers concieved the most aggressive cyber attack on a controller: denial of control combined with denial of view. The controller is no longer controlling I/O, but doesn't recognize that. The same is true for the HMI and for operators. In the meantime, Stuxnet writes to outputs at its discretion.

DEADFOOT

The 315 attack uses approximately 3000 lines of Step7 STL code and four small data blocks (DB 888...891).  Rogue STL code is logically structured in function calls (FC). Two of these functions, namely FC 1865 and FC 1874, are injected into OB 1 and OB 35, respectively, which also check for the infamous "Deadfoot" condition that is returned by the FCs mentioned. (The attackers actually used the term DeadF007, but this appears to be leetspeak for Deadfoot.) On any S7 controller, OB 1 is the main sweep that is continuously executed. OB 35 is the 100-msec timer.

During the Deadfoot condition, which may take up to 50 minutes, control is taken away from the legitimate controller program by simply calling a conditional block end (BEC) directive instead of passing control flow on to legitimate code. In effect, execution of legitimate controller code is simply halted during the Deadfoot condition, which must have been unrecognizable to both the legitimate code and any attached SCADA software, and also to any human operators in the proximity.

Another noteworthy attack technique in the 315 attack code that tells researchers a lot about the attackers' capabilities is an intercept of the DP_RECV system function. On an S7 controller, this function is called to read the process image of a specific Profibus network. The 315 attack code hooks this function, which few people knew is technically possible, and monitors process variables from the attached devices by calling the original DP_RECV, which is renamed by the attack code. In addition to monitoring the values from up to 31 devices in up to six Profibus networks, they are passed along unchanged to legitimate code. Changing values during the attack is not necessary because the legitimate code is no longer in control anyway. During the attack—which, remember, can take up to 50 minutes—fixed values stored in DB 888 are written to the attached actuators.

The 417 attack routine is much more complex. It consists of approximately 12000 lines of Step7 STL code and accesses a total of 10 data blocks. Two of the data blocks (DB 8062, 8063) are statically loaded from the rogue DLL; one is dynamically loaded from the rogue DLL (DB 8061); and seven are dynamically created at runtime by the rogue STL code (DB 8064…8070). Especially noteworthy is DB 8063, with a size of 26,790 bytes, containing a 16-kbyte array. Again, rogue STL code is grouped into logical FCs. The entry point to these functions is provided by a code injection in OB 1, the main sweep.

Man in the Middle

The most noteworthy technical feature of the 417 attack is a full-blown man-in-the-middle attack on the controller. Rogue code intercepts physical I/O and provides the legitimate program running on the controller with "normal" input patterns that are actually pre-recorded by Stuxnet. It's similar to what you've seen in Hollywood movies. During the heist, the observation camera is fed with unsuspicious footage, keeping the guards happy.

This is not an analogy. It is exactly how Stuxnet does it. In order to do that, Stuxnet has changed the controller program at configuration time to disable automatic updates of input process and output process images—something that is configurable on S7-400 controllers. Add to that the fact that the input process image is read/write instead of read-only. Then you can conceive the most aggressive cyber attack on a controller: denial of control, combined with denial of view. The controller is no longer controlling I/O, but doesn't recognize that. The same is true for the HMI and for operators. In the meantime, Stuxnet writes to outputs at its discretion.