“Zero day” attack on Siemens control system software shows alarming new level of malware sophistication
by Andrew Bond, Industrial Automation Insider (August 2010 Issue)
Last month’s cyber attack on Siemens SCADA systems and DCSs has reopened the question of how responsibility for ensuring the security of automation systems in general and those controlling potentially hazardous industrial processes and critical infrastructure in particular should be shared between users and vendors and, indeed, vendors’ suppliers.
Few people in the automation industry, and precious few more in the user community, can now be unaware of the bare bones of what has now become known as the ‘Stuxnet’ affair. According to Siemens it was on July 14th last that the company was notified of a security breach within Windows which could potentially affect its Simatic WinCC SCADA software and the PCS7 DCS which uses WinCC as its HMI. Among the first to identify the threat was Byres Security chief technology officer Eric Byres who confirmed that what Siemens and its users were experiencing was “a zero-day exploit against all versions of Windows including Windows XP SP3, Windows Server 2003 SP 2, Windows Vista SP1 and SP2, Windows Server 2008 and Windows 7.” (see Security threat to the control system world! – this also contains links to other comments on the Stuxnet affair!)
For those, including us, who are not fully familiar with the jargon, a “zero day” exploit is one which is exploiting a hitherto unidentified security breach which only becomes apparent because of and at the same time as the original attack and leaves all other users of the same system or systems at risk until such time as the vulnerability is eliminated.
Spread by USB keys
In this case the ‘malware’, variously described as a Trojan and a worm, seems to have been spread by USB keys, although it seems possible that it could also be propagated via network shares from other computers. It exploits a previously unidentified vulnerability in the way Windows displays icons for shortcuts via .lnk files with the result that, in order to become infected, the user does not even need to open any file or run any application on the USB stick; just viewing the contents via Windows Explorer is sufficient. As a result, disabling AutoRun doesn’t provide any protection either.
Given the ‘zero day’ nature of the attack, it was hardly surprising that no patch was available from Microsoft although it is hoped that one will be prepared by the next due date, for patches to be made available in early August. In the meantime Microsoft outlined a series of ‘work arounds’ which included, not surprisingly, not installing USB keys, disabling the display of icons for shortcuts and disabling the WebClient service.
It also rapidly released a tool which would disable the vulnerability in most cases but would affect the way Windows displayed shortcut icons: and a clean-up tool which would sanitize infected systems but, it warned, might adversely affect the performance of a control system.
Targetted at automation
So far, so Windows generic. Within days if not hours of the existence of the malware, by then dubbed ‘Stuxnet’, becoming known, a number of less sophisticated lookalikes had been identified, a pattern which is apparently the norm for such attacks. However what seems to set this incident apart from the general run of malicious tomfoolery is that the malware displays an unusual degree of professionalism, incorporating a seemingly authentic but fraudulently copied certificate and, even more unusually, specifically targeting industrial automation software. As Byres explained, it “uses the Siemens default password of the MSSQL account
WinCCConnect to log into the PCS7/ WinCC database and extract process data and possibly HMI screens” which it then attempts to export via an internet connection to a remote server. However, Siemens warned against what might have seemed the most obvious solution, changing the password, because of potential knock on effects elsewhere in a system.
Adding a sinister twist to the story, again according to Byres, is the fact that discovery of the malware coincided with “a concerted Denial of Service attack against a number of the SCADA information networks such as (the) SCADASEC and ScadaPerspective mailing lists, knocking at least one of these services off line”. That seems to suggest that those responsible had prepared sophisticated plans in advance, not only to release the malware targeting the Siemens systems, but to frustrate users’ and vendors’ attempts to counter the threat.
Control system infection
At the time of writing, Siemens claimed to have identified just one user, a site in Germany, where a control system had actually been infected. More-over, even in that case, while it attempted to export data, it was apparently unable to do so because the server to which it was sent either did not exist or was off-line.
Had the objective been actual sabotage, rather than what appears to have been industrial espionage, the consequences could have been very much more serious. Clearly, there is a shared responsibility here. Microsoft has a duty to ensure that its products are as secure as is reasonably possible and to act to eliminate vulnerabilities as soon as is practical after they have been identified. What they can’t reasonably be held responsible for is the consequences of their customers, or their customers’ customers, using those products in a manner which dramatically magnifies the consequences of such unknown vulnerabilities being discovered and exploited by malevolent third parties.
Clearly a Siemens user whose WinCC or PCS7 installation has become infected has at one level been extremely unlucky. Not only has an infected USB stick had to find its way onto the site, presumably via one of its own, a contractor’s or a vendor’s employee, but that stick has to find an unprotected USB slot on or with access to the control system. The fact that, thus far, this has only happened once suggests either that, at least initially, the number of copies ‘in the wild’ was relatively small, or that users’ basic security precautions, including locking down or eliminating USB slots, are in general reasonably effective.
Dangerous software error
Nevertheless, while Siemens enjoyed some initial sympathy for being targeted and even a degree of admiration for the speed with which they have responded, fingers are now beginning to be pointed both at them for the vulnerability of their systems and at the users themselves for adopting such systems without apparently questioning their security. Chris Wysopal, CTO of cyber security specialist Veracode, is particularly critical of Siemens’ use of a hard-coded password which, he says, comes eleventh in what he calls the industry standard ‘CWE/SANS Top 25 Most Dangerous Software Errors.’ Writing on his ZeroDay Labs Blog and alleging that Siemens was aware of the issue as much as two years ago, he asks, “Why didn’t Siemens fix the hard coded password vulnerability when it was first publicly disclosed?”
Wysopal has no doubt where the ultimate responsibility lies. “Software customers that are operating SCADA systems on critical infrastructure on their factories with the WinCC Software had a duty to their customers and shareholders to not purchase this software without proper security testing,” he says. Although the incident will once again raise the bigger issue of whether Windows is in fact a suitable vehicle for mission critical industrial and infrastructure applications, more immediately other vendors and their customers will be examining not just their systems’ susceptibility to this particular vulnerability but whether they provide a similar
‘Open Sesame’ to their applications. Software, argues Wysopal, should be subjected to independent security testing before it is deployed if users are to rely on anything more than the hope that someone else falls victim to the next piece of malware and that a patch is released before their own system is attacked. “With the sophistication shown through this multi-stage USB attack, it is clear that hope is not a viable option,” he concludes.