Stuxnet news and opinions: end September

Recent background articles on Stuxnet are provided here on for your own review.

Stuxnet worm causes worldwide alarm: by Joseph Menn and Mary Watkins: FT (UK) 23 September.

Virus Bulletin: Last-minute paper: An indepth look into Stuxnet. (Liam O’Murchu, Symantec)

Kaspersky Lab provides its insights on Stuxnet worm. 24 Sept.

Langner commentary. 27 Sept

Stuxnet worm ‘targeted high value Iranian assets’. BBC 23 Sept.

Bruce Schneier on security. Sept 22

Wary of naked force, Israel eyes cyberwar on Iran. 7th July,7340,L-3742960,00.html

Stuxnet: Targeting Iranian enrichment centrifuges in Natanz? 22 Sept.

Serious nuclear accident may lay behind Iranian nuke chief’s mystery resignation. 17 July’s_mystery_resignation

The Amazing Mr Stuxnet: Eric Byres, Sept 23.

Stuxnet worm hits Iranian nuclear plant staff computers. BBC 26 Sept

Pentagon silent on Iranian Nuke virus: Fox news 27 Sept.


Stuxnet malware worse than expected!

The lead article from the INSIDER for September 2010 published this review of the situation with the Stuxnet worm. To get this information as soon as it is published, subscribe to the INSIDER, via

After the Stuxnet worm, all industrial control systems, PLCs and RTUs with embedded systems now have to be regarded as at risk. So says Walt Sikora of Industrial Defender Inc (ID) – but then he would say that, wouldn’t he, as vice president of security solutions at Industrial Defender? However a recent webcast by Sikora presents an excellent outline of the capabilities of the Stuxnet worm as known at present, and gives a timeline presenting the events of the past two months, as evidence for his assertion that “This is a very sophisticated, very scary piece of malware.” In his webcast, first presented on 19 August, Sikora explains that the malware attacks the control system, and can insert itself into the internal communications to the PLC, being dubbed the first rootkit for a PLC device. While the Siemens PCS7 is the target in this instance, the Stuxnet worm is not the result of a bored schoolboy prankster – it is described as a sophisticated cyber-war weapon, with a payload targeted at a specific industrial control system. The conclusion is that control systems are to be the targets for future worms: despite any future fast response from Microsoft, Siemens and AV suppliers, their actions can only slam doors shut after an attack has been successful.

Stuxnet time-line

The time-line for this story started over a year ago, when apparently the Stuxnet virus was launched. It was then discovered first June 17 by a Belarus AV development company, VirusBlockAda. July 15 Frank Boldewin, a security researcher, decrypted the worm and found it targeted Siemens WinCC and PCS7 control systems. July 22 Siemens posted a tool to identify and repair systems, followed by similar actions from AV vendors. July 27 ID hosted their first panel discussion in a webcast, hosted in order to disseminate all available knowledge about the worm. Aug 2 Microsoft issued the emergency patch. While Microsoft has acted very promptly, demonstrating their commitment to support of the industrial control systems sector by issuing an emergency patch for .lnk files on the software systems that they regard as current operating systems, older systems such as Windows 2000, NT, or XP service pack 1/2, are no longer supported, and not included. Plus inevitably it will take time, resources and commitment by operators to test, approve and install this patch on even the new systems where it is needed. August 6 however, in Sikora’s words: “Symantec found that the malware itself, the payload, was worse than what we even thought…the worm itself had the capability of being controlled from a computer outside, it would allow the attacker to take control and write values to the control system itself, and that is very very scary. All automation control systems are at risk today.”

The August 6 posting on the Symantec website by Nicolas Falliere, a senior software engineer, explains that “Stuxnet isn’t just a rootkit that hides itself on Windows, but is the first publicly known rootkit that is able to hide injected code located on a PLC.”

Beware of sleeping code blocks

Falliere continues with an unattributed example of the effects of these hidden, sleeping code blocks. He explains that by writing code to the PLC, the Stuxnet malware can potentially control or alter how the system operates. A previous historic example includes a reported case of stolen code that impacted a pipeline. Code was secretly ‘Trojanized’ to function properly, and only some time after installation, instruct the host system to increase the pipeline’s pressure beyond its capacity. This, [he asserts] resulted in a three kiloton explosion, about 1/5 the size of the Hiroshima bomb. 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.  Falliere adds “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.”

HIPS protection against Stuxnet

In the ID webcast Sikora continues with a demonstration of the Stuxnet, and then goes on to show that the new Industrial Defender HIPS [Host Intrusion Prevention System – see side panel] would stop the Stuxnet worm penetrating a protected system. HIPS is therefore offered as a valid method for in-depth protection of industrial control systems against such malware. This is a part of the ‘Defense in Depth’ strategy promoted by Industrial Defender. HIPS only allows good executables, from a “whitelist” of programmes allowed to run. It uses intrusion prevention and access management, and has no regular scanning issues, such as the scans used by AV software that tie up a computer or system for extended timescales. Sikora claims that HIPS would have prevented the Stuxnet worm accessing the known infected control systems.

Geographic spread of Stuxnet

Separately a white paper on the ID website gives further background, which also shows the major infection levels by the Stuxnet worm. On July 15 Kaspersky Labs in Russia, the AV vendor, reported 5000 compromised machines. By July 23 there were 45,000 infected machines reported, with main concentrations, according to Kaspersky, in India, Indonesia and Iran. The population infected in the USA is not known (as Kaspersky does not have much market penetration there, and other data is not available). Symantec data summarises that the major infections are in SE Asia, and that 48% of hits reported have been on Windows XP SP2 systems, for which there is no official Microsoft emergency patch.

Industrial Defender has also announced Compliance Manager, a security process automation and information management system that enables control system managers in the utility, chemical, oil, gas, water and transportation industries to cost-effectively implement and sustain best practices that assure system security, availability and compliance to corporate and industry security standards.

“Utilities are being overwhelmed by the amount of information, events and tasks that they need to manage as they continue to enhance their critical system security processes”, said Brian M. Ahern, president and ceo of Industrial Defender.

“Industrial Defender’s Compliance Manager automates data collection and analysis tasks that would otherwise require extensive manual operations, while providing the tools needed to improve system integrity and meet the extensive compliance auditing requirements of NERC CIP cyber security standards.”

Compliance Manager and the associated Industrial Defender sensor and collector technologies are specifically built to operate with both mission critical automation systems (e.g., SCADA, EMS/DMS, DCS/PCS) and industrial end-point devices without impacting system performance and availability. It automates the collection, retention, analysis and reporting of a comprehensive set of system and security management information. It consolidates and analyzes device inventories, event logs, system configurations, software/patch status and user accounts, as well as archives of log and configuration files for automation control applications, operating systems, firewalls, network devices and end-point industrial devices.

“Stuxnet” malware targetted at automation

This article by Andrew Bond is taken from the 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.