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.
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, www.langner.com/en.
