Stuxnet Report Updates

(This article was originally published on the Findings From the Field blog.) Last week ESET updated their Stuxnet Under the Microscope report, and Symantec updated their W32.Stuxnet Dossier. Important changes: the Symantec dossier includes a description of how to identify compromised PLC’s, and the ESET report describes the still-unpatched Task Scheduler vulnerability in enough detail to exploit it. The ESET disclosure is surprising – usually such descriptions are reserved until a patch is available for the exploit. ESET: Stuxnet Under the Microscope The ESET report is the more accessible of the two reports. The report takes a slower and more detailed look through the Windows vulnerabilities, including many screen shots of diagnostic tools picking apart the details of the worm. The report also includes a section comparing the Stuxnet worm to the Aurora advanced persistent threat. I can’t agree with all of the conclusions of the comparison, though. For example, the report suggests that: While the payload is plainly focused on SCADA systems, the malware’s propagation is promiscuous. Criminal (and nation-state funded) malware developers have generally moved away from the use of self-replicating malware towards Trojans spread by other means (spammed URLs, PDFs and Microsoft Office documents compromised with 0-day exploits, and so on). Once self-replicating code is released, it’s difficult to exercise complete control over where it goes, what it does, and how far it spreads…” In fact, Siemens indicates that only 15 sites have reported Stuxnet infections thus far, and at none of those sites did the worm compromise programming in production PLC’s. Control systems constitute a very small fraction of the world’s computers and the worm is quite specific about which PLC’s it targets. Between those two factors, it is concievable that the worm injected its code into at most one or two sets of PLC’s in the world. I would describe this as a very targeted attack. The surprising aspect of the ESET report is its detailed description of the Task Scheduler vulnerability. The description seems detailed enough to allow any third party who is “skilled in the art” to produce an exploit of the vulnerability. Descriptions this detailed are generally not published until a patch for the vulnerability is released. Microsoft has released no such patch. In addition, when such zero-day descriptions are published, there is generally a backlash in the media against the organization publishing the details of the vulnerability, because they have given the “bad guys” a recipe for creating very effective malware. I have seen no such backlash thus far. Symantec: W32.Stuxnet Dossier The Symantec dossier is the more comprehensive of the two reports. It is also the shorter of the two reports, and so takes more effort to read and understand. The dossier includes details of how the worm propagates via Siemens database connections, how it propagates via S7 project files, and how the worm manipulates data blocks and function blocks in Siemens PLC’s. The new content in the Symantec report is a description of the MS10-073 Win32k.sys vulnerability and a more detailed description of the PLC function blocks which the worm injects. Symantec reports that the function blocks decoded thus far indicate the worm waits for about 13 days at a time: reading, searching and counting Profibus messages. Every 13 days or so, the worm sends a sequence of Profibus messages to its slave PLC’s, alternating between two message sequences. The published details are complex and Symantec has issued a call for expert Siemens PLC programmers to help them analyze the function blocks. However, Symantec reports they have received no qualified responses to their call. If anyone out there can contribute to the analysis, please contact Symantec. The dossier identifies three sets of function blocks the worm injects into certain kinds of S7 PLC’s, codenamed A, B, and C. The C group of function blocks appears to be a “left over” from earlier versions of the worm and is not injected into PLC’s any more. A and B are nearly identical. If your PLC has been compromised by either the A or B set of function blocks, Symantec reports that you will see the following indicators in compromised PLC’s: One can recognize an infected PLC in a clean environment by examining blocks OB1 and OB35. The infected OB1 starts with the following instructions, meant to start the infection sequence and potentially short-circuit OB1 execution on specific conditions: UC FC1865 POP L DW#16#DEADF007 ==D BEC L DW#16#0 L DW#16#0 The infected OB35 starts with the following instructions, meant to short-circuit OB35 on specific conditions: UC FC1874 POP L DW#16#DEADF007 ==D BEC L DW#16#0 L DW#16#0 The key here is “One can recognize an infected PLC in a clean environment…” The PLC rootkit in the Stuxnet worm on compromised machines will hide the instructions above from Step7 PLC programming tools. To see these instructions, you need to examine the PLC’s with a clean workstation. Defense in Depth The Stuxnet worm has shown that advanced threats are targeting industrial control systems. Owners and operators of such control systems need to account for this new kind of advanced threat in their security programs. In particular, owners and operators need to consider changes like: alternating advanced intrusion prevention and intrusion detection technologies, to both prevent intrusions, and to detect those intrusions which evade intrusion prevention measures, and increasing network segmentation, to slow down the spread of advanced malware which does manage to evade intrusion prevention measures. No defense is perfect, but there is significant room for improvement in the state of the practice.