Bryan Owen

25-Jul-2010 Fallout from “Stuxnet”

Blog Post created by Bryan Owen on Jul 26, 2010

Plenty has been written about the "Stuxnet" malware that is targeting certain SCADA systems. As might be expected hype is out pacing the available facts, mostly due to amplification in mainstream media before proper analysis has been made public. Let's discuss some facts before speculating on potential impact on PI.


The malware can propagate via USB, network shares and Web Distributed Authoring and Versioning (see Microsoft Advisory 2286198). Simply opening a folder is enough to start execution. Windows Both Microsoft and Symantec have significant instrumentation and are sharing infection count data with a geographic break down.  Perhaps the data is reassuring if there are few infections in your region.


Security experts have been busy analyzing the malware. Much of this work is very good and has been made public to the extent allowed without fouling law enforcement. I recommend the series of blog posts from Symantec as providing the most interesting details.


In a nutshell the exploit payload installs a rootkit and then looks for the vulnerable SCADA component. On success the attacker collects information from the control system.  There is no evidence of actions that could result in "kinetic" consequence or otherwise cause a plant process disturbance. 


As "Stuxnet" is deconstructed there is plenty of speculation (or will the hype just fade per opinion at Verizon).  Some will take the view owner operators were just lucky this time which could spawn more cyber regulation and further heighten standards for critical infrastructure protection. Unfortunately standards have little impact on legacy equipment and if you need a keyboard and mouse it isn't all that practical to fill USB ports with epoxy.


A win on the law enforcement side of this event would be great result but don't hold your breath. [IMHO operators and vendors collectively as stakeholders have a long way to go in handling incidents and providing deep forensic data that is needed to really help nail cyber criminals.]


Closer to home, I am wondering if a "Stuxnet" like attack could be successful in targeting PI. After all, PI has the same data as the control system and likely much more of it. It sounds kind of silly these days but deployment patterns allowing read only access without a password were fairly common in PI versions prior to Windows integrated security.


Recent PI Systems disable blank passwords by default (the explicit login method is disabled as well). Likewise, AF installation defaults are consistent with security practices that prevent an attacker from enabling SQL extended command procedures. As such several parts of "Stuxnet" attack vector are mitigated.


Don't celebrate too soon. I expect the rootkit would load if an infected USB were attached to a PI Server without effective malware prevention procedures. Game over once malware becomes a trusted part of the operating system.


Microsoft's analysis is still in progress and it will be interesting to see if the Windows shell vulnerability is applicable on Server Core (since there is no GUI, there are no shortcuts or icon processing). On the other hand, Microsoft's patch criteria only considers if the dll is present on disk - even if there is no access vector to exploit the vulnerability. I'm also looking forward to a more complete explanation of kernel patch protection bypass and how expired certificates still seem to allow the rootkit to load.


Fortunately, in most cases good security practices have prevented "Stuxnet" from reaching the target control systems and fully executing the malicious payload. The problem is that such security vigilance is taking too much effort for our customers. Even worse, attackers are learning how to use our own applications against us. Software security initiatives need to accelerate, known vulnerabilities must be eliminated, and applications must be better instrumented to help with forensics. In turn customers must accelerate upgrades and streamline management of change procedures.


To be fair, open access to PI data is often intentional.  Simply put - it's safer to promote use of data in PI rather than allow non-essential access to the control system. However, as information grows in importance greater protections for the enabling applications and data streams makes sense. While information isn't yet a line item on the corporate ledger as predicted by Admiral Hopper, increasing the value of data is at the center of all of our work.