Symantec Dossier Updated: v1.4

(This article was originally published on the Findings From the Field blog.) A week ago, Symantec released the third update to their Stuxnet Dossier, adding sections on chains of infection and on the 417 PLC exploits. The new information is interesting because it suggests new things about the target site and how it was initially infected. Ralph Langner's team has also investigated the S7-417 code and disagrees with Symantec in a number of ways. Original Infection Points The Symantec team looked at the contents of encrypted log files captured from about 3000 Stuxnet-compromised machines. The log files each contain a history of machines compromised by the worm as it propagated from one machine to another. The first such entry in each file represents the machine the worm first compromised. In the more than three thousand samples, the Symantec researchers found only five distinct original targets, each infected between one and three times, for a total of ten "original" infections. The Symantec team was then able to visualize infection "paths" as different versions of the worm moved between machines, using diagrams like the one at right. They explained that the many straight-line paths without any branches arose because the worm spread very slowly and each compromised machine tended to infect only one more machine. They also mention that even though there are three thousand samples, that number may not be large enough to illustrate branches accurately. Myself, I think the second conclusion is the more likely reason for the long straight lines of infection. If you think of the log file samples, there is a history in each file of a straight-line of infections from the original site to the site where the log file was captured. Branches occur when a pair of log files is found with a set of identical initial entries. Without enough samples, there are few matches on initial entries and you see the long chains of singleton machines - log files simply were not captured from any of the branch infections. Sequence C: Symantec and Langner The dossier reports that PLC infection sequence "C" targets S7-417 CPUs, but maintains that the infection sequence is incomplete because of a failure in the Windows code which attempts to create data block DB8061. The missing data block means the nature of the sequence C sabotage is difficult to determine, because it is the missing DB8061 data which contains the faulty data sent to the frequency-converting drives by infection sequence C. Ralph Langner disagrees. He points out that Siemens concluded the S7-417 infection code relies on a pre-existing DB8061 in the unit under attack and suggests that sequence C may in fact work. He also suggests those parts of the sequence C state machine which Symantec identifies as missing may simply be un-necessary, and those cases appear to be missing because the large body of code which is infection sequence C was simply never cleaned up properly before release. But even Ralph concludes in the end that we may never be certain which is the correct interpretation of the very complex code in infection sequence C. Symantec confirms the Langner team's conclusion that sequence C includes a "man in the middle" type of attack. Symantec reports: When the peripheral output is written to, sequence C intercepts the output and ensures it is not written to the process image output. The output is the instructions the PLC sends to a device to change its operating behaviour. By intercepting the peripheral output, Stuxnet prevents an operator from noticing unauthorized commands sent to the peripheral. Another tidbit: a careful reading of the Symantec discussion of sequence C shows that Symantec has changed some of their terminology. In past versions, Symantec was careful to maintain that while there has been much speculation as to the target of the attack, nothing concrete is known about the target other it used a large number of two specific types of high-frequency, frequency-converting power supplies. Many others have pointed out that cascades of gas centrifuges for uranium enrichment at the Iranian Natanz facility are likely to use such power supplies, and Iranian officials have admitted some lost production at the facility due to Stuxnet. While the Symantec terminology in its latest description of infection sequence C does not mention "Natanz" or "uranium," it does mentions "centrifuges" and "cascades" a number of times. Other developments There were a number of other recent developments around the Stuxnet worm in addition to the dossier and the continuing Langner analysis of infection sequence C: There are reports that the retiring chief of the Israeli Armed Forces, Gabi Ashkenazi, claims that Israeli forces were the authors of the Stuxnet worm. While this is not an official admission of responsibility, it comes close. The hacker group "anonymous" released a set of source code decompiled from Stuxnet binaries. A glance through the posted code suggests it is a large fraction of the C/C++ type components from the worm, but does not appear to contain any of the PLC function blocks. The source code is the result of a decompiler tool and so is very difficult to understand. I'm thinking the code may help someone who has a lot of time figure out more about how the worm works, but this is not a code base that can easily be adapted to new purposes. Some of the code is incomplete where the decompiler was unable to properly decode the binary, and the over 100,000 lines of decompiled code are very difficult to understand and to modify intelligently. Last but not least, Eric Byres, Joel Langill and I just published a new whitepaper on the worm: How Stuxnet Spreads – A Study of Infection Paths in Best Practice Systems. The Symantec dossier and other documents like it do a great job of explaining the worm, but they spend little effort explaining what a typical Siemens installation looks like and explaining how the worm evades best-practice security systems to reach its target. The new whitepaper describes a site with a Siemens-recommended, best-practices-based security program and shows how Stuxnet moves easily through the various networks to compromise the control system. The message to take from the paper is that today's best-practice defenses are not enough to stop today's advanced threats. Defending against advanced threats takes a new kind of awareness and determination that is only just starting to emerge in critical infrastructure sectors.