The Siemens response to Stuxnet has been like a roller coaster. It started diving low with limited information and bit of blame shifting as most organizations facing a vulnerability for the first time do. [Siemens is huge and obviously other parts of Siemens are well versed in handling vulnerability incidents, but I’m unaware of this product line having a publicly disclosed vuln] To their credit, Siemens quickly went uphill by creating a dedicated page, frequent updates, applicable warnings about fixes and more. Now that the Microsoft patch is out and the crisis mode has abated they seem to be diving down again by sidestepping the issue of recovering an authentic and reliable Siemens build.
I credit a Jake Brodsky entry on SCADASEC for raising the issue of where is the guidance from Siemens on cleaning out the damage to the Siemens components? It is not even mentioned on the Siemens’ Stuxnet page. Patching the Microsoft vulnerability may be the easy part of the remediation and far from sufficient. The Siemens’ page does have a Simatic Security Update executable with little information about what it does. It appears to be involved with the Microsoft patch, but maybe it is updating affected DLL’s
Symantec has provided the most detailed analysis of what Stuxnet tries to do to Siemens’ software, and the more they look at it, the nastier it seems. In a recent blog entry Symantec concludes:
Thus, in addition to cleaning up the Stuxnet malware, administrators with machines infected with Stuxnet need to audit for unexpected code in their PLC devices. We are still examining some of the code blocks to determine exactly what they do and will have more information soon on how Stuxnet impacts real-world industrial control systems.
You don’t have to understand all the gory details of the Symantec blog series to see the concern. They cover the s7otbxsx.dll wrapper, the Siemens’ functions and those that are “hooked” or intercepted and modified by the wrapper, and other Siemens modifications in this entry.
As can be seen in the screenshot above the first action that the wrapper .dll takes is to decode an encoded string and call LoadLibrary with that decoded string. The decoded string is “s7otbxsx.dll”. The wrapper .dll file needs to load the real .dll file in order to pass the calls along to the real .dll file after the wrapper .dll file has changed whatever data it wants.
Siemens should start back uphill again and provide detailed and verified information on what various versions of Stuxnet have done to their software, and the steps required to fully rid a system of these changes with a high degree of confidence. This is likely to require very detailed technical information — at least that is what I would demand if I was responsible for an infected system. The rigor of the detail would help convince me Siemens understood Stuxnet and would allow me to audit my control system for infection issues. Siemens might want to keep that information closely held, customers with NDA only, but there should be a section on the Siemens page highlighting the importance of cleaning out the affected Siemens’ code and how to get this information.