Symantec recently issued an update on their Stuxnet dossier, and many people wonder how their updated information might fit together with ours, so let’s take a look.
Symantec updated their dossier on February 11, 2011 in two essential areas. First, they published an analysis of Stuxnet’s initial spreading pattern. We have no means to verify this analysis because we don’t have access to the analyzed data. However it appears plausible and matches with our scenarios. Second, Symantec verified many of our published research results on the 417 attack code, surprisingly without giving any reference (not good style, fellows). In particular:
- Man-in-the-middle attack providing the legitimate controller code with pre-recorded fake input data, published by Langner on November 15, 2010, verified by Symantec on February 11, 2011
- 417 state machine including details on timing, published by Langner on December 8, 2010, verified by Symantec on February 11, 2011
- Associating the 417 code with the centrifuges, published by Langner on December 27, 2010, verified by Symantec on February 11, 2011
- Details on 417 data structures that match with IR-1 cascades, published by Langner on January 30, 2011, verified by Symantec on February 11, 2011 (Note: Symantec pulled out a subset of the data published by Langner but did not identify the match with IR-1 cascade structures)
There are other details where our analysis and Symantec’s do not match, for example associating the 417 code with the six Profibus networks that each of the 315s talk to. According to our analysis, the six cascades that the 417 controls are unrelated to the six Profibus networks of the 315s. The system architecture as we see it was published on December 30, 2010.
417 code disabled or not?
There is disagreement about the question whether the 417 code is disabled or not. Symantec assumes that the 417 attack code is deliberately disabled. Langner finds that implausible for the following reasons:
- The missing data block 8061 could be part of the attacked application. This is supported by the only genuine research result on Stuxnet that Siemens has provided so far.
- The few coding errors that Langner has found in the code don’t look like they would essentially prevent the attack from executing. In an application of this size (~ 12,000 LOC) which must have been developed under considerable time pressure, minor coding errors like the ones we have identified appear normal.
- Langner has identified areas of code that are never called but understands this is because pre-fabricated tools have been used in the development.
- Langner has lab proof that the rogue DLL actively probes controllers for the existence of DB 8063 (no typo), which would make little sense if the 417 attack code had never been loaded on the controllers.
All in all, we don’t say the 417 code was executed on the controllers in Natanz, we just say we don’t know. Answering this question may be as difficult as determining if the infected 315s were actually connected to Vacon FCs, or whether objects removed from the Natanz FEP as recorded on observation cameras were actually damaged centrifuges or oversize soda cans. We just don’t know. On the other hand, we are not researching Natanz, we are researching Stuxnet. While all of the above mentioned items are speculative, what we analyze in the code is hard fact. Even if we can’t say for sure what Stuxnet actually did in Natanz, we can definitely say what it intended to do.
For Stuxnet analysis with the dedicated focus on determining the impact on control system security at large, the 417 attack code is much more important than the 315 code. Compared to the 417, the 315 is a piece of cake. In the 417 attack, the attackers let down their pants and showed their full range of skills. Frankly speaking, it is terrifying. The 417 attack challenges digital safety as such. Few people have realized this. We’re afraid many more will at some point in time – the hard way.