I am not a Siemens user – why should I worry?
Stuxnet has irrevocably changed the future of automation practitioners, SIs and end users.
The target of Stuxnet happened to be certain Siemens systems. This had nothing to do with vulnerabilities that Siemens hardware and software exposed and everything to do with who was using those systems and for what they were using them.
If you use a scada system, any scada system, you are almost certainly just as vulnerable to determined attacks by suitably motivated groups. To emphasise this point, Joel Langill, CSO at TheSCADAHacker, director of Critical Infrastructure and scada representative for the Cyber Security Forum Initiative, recently blogged1, “[T]alented [hackers] do not need the specific exploits ... they probably just need to get their hands on any scada HMI product [to expose zero-day vulnerabilities] – the number of vendors with clear records is getting smaller by the day.” In his presentation, Cyber Defence: Analysing Global Threats2, Langill says that complete prevention of cyber attacks on ICS systems is not realistic.
You may have been hacked long ago
Because some aspects of virus protection software technology are reactive by nature, the first sites to be infected may not be aware of infection – especially if there are no easily observable symptoms of the infection.
In its February 2011 white paper, Global Energy Cyberattacks: Night Dragon3, McAffee describes a series of attacks that started in November 2009 against global oil, energy, and petrochemical companies. In these attacks, dubbed ‘Night Dragon’ by McAffee, the hackers gained valuable competitive operational and financial information on oil and gas fields and also collected data from scada systems. Referring to these attacks the report says, “[W]e been able to determine that a dedicated effort has been ongoing for at least two years, and likely as many as four.”
In a similar vein, while reports of Stuxnet started circulating in July 2010, Symantec subsequently confirmed that the virus was first deployed more than one year earlier.
What is Stuxnet?
Stuxnet is a self-replicating virus that exploits weaknesses in Microsoft operating systems, Siemens WinCC scada and PLC programming tools to affect industrial processes that exhibit certain specific application characteristics. At the time of its discovery it was the largest and most complex piece of malware that antivirus researchers had ever seen: approximately 15 000 lines of code – some 20 times bigger than the previous claimant to that title, the Conficker worm. Conficker is on record as having infected major infrastructural and military systems including those of the French Navy, Royal Naval warships and submarines, the German Bundeswehr and British parliamentary, police and health systems.
Amongst other mechanisms, Stuxnet exploits four previously unknown (aka zero-day) security vulnerabilities in Microsoft operating systems to target WinCC/PCS7 industrial control systems. A critical end result of the infection process involved the modification of Step 7 PLC application code in the infected PLCs.
The virus is designed to target control systems exhibiting specific characteristics for controlling centrifuges operating in a particular range of speeds (807 Hz to 1210 Hz). Such characteristics are displayed by centrifuges used in uranium enrichment. In particular the primary Stuxnet targets appear to have been systems in Iran’s nuclear weapons programme.
At the PLC level Stuxnet causes centrifuges to operate outside their design speeds, but not at such speeds that the maloperation is immediately obvious. The resulting damage is believed to have set back Iran’s nuclear programme by several years.
There were three series of attacks between June 2009 and mid 2010 and by September 2010 approximately 100 000 PCs had been infected, with 60% of those being in Iran. If we accept that Stuxnet was targeted at Iran then this means that the other 40 000 infections must be considered as collateral damage that the developers were willing to put at risk.
How can a virus fingerprint a particular manufacturing process?
Readers may be wondering, “How could Stuxnet recognise a potential target control system such as one controlling a uranium enrichment plant?” The answer is as scary as it is simple – and can be likened to using Facebook and LinkedIn to discover personal information:
1. Know the target process.
1.1 The centrifuges at the target plants use either Vacon variable speed drives (VSDs) or VSDs from Fararo Paya in Teheran, Iran.
1.2 The target plant(s) use a large number (33 or more – in some cases hundreds) of such centrifuge drives.
2. Know the control technology.
2.1 The target CPU is 6ES7-315-2 (series 300)
2.2 The communication to the drives is via Profibus, which requires a CP 342-5 Profibus network interface module in the PLC.
2.3 Each Profibus device model has a unique ID that is publicly available: 7050h for the KFC750V3 drives from Fararo Paya and 9500h for the Vacon NX drives.
See Figure 1 for a simplified flowchart of this logic.
What is the significance of Stuxnet?
Perhaps the most significant aspects of Stuxnet are not in its distribution mechanisms, but in:
* Who developed it.
* What it targets.
* The design pattern that it has made public.
Because of the massive effort involved in its creation (Symantec is reported to have estimated that up to 30 programmers worked on the development of the virus) and the target of systems operating many centrifuges (as happens in the nuclear enrichment industry) it is widely suspected that Stuxnet was developed by teams working for and probably within the US and Israeli intelligence structures. This elevates cyber-warfare from the province of hackers and phishers to that of offensive technology for use by nation-states and political blocs.
Stuxnet is the first virus targeted not just at a computer operating system, but through the computer and into the realm of PLCs (modifying the actual PLC code) and variable speed drives. Symantec label it the first rootkit for PLCs. So now we must consider that vulnerabilities exist at the computer level AND within connected purpose-specific devices. And if PLCs and Profibus are in the cross hairs of unfriendly organisations with unlimited budgets, what about other devices such as instrument transmitters and controllers, many of which are now processor-based?
The widely publicised and detailed analysis of the virus and its transport mechanisms, coupled with the modular nature of its code, separation of delivery mechanisms and payload, its target of industrial control hardware (PLCs) and the lack of anti-virus tools for the target controllers has served to alert the hacking community to the presence of vulnerable high profile targets.
How safe is safe?
For automation and control practitioners, one of the most worrying aspects of Stuxnet is that it acted as a Man-in-the-Middle in a real-time system, masking closed loop VSD control device feedback signals that were implemented for plant and personnel safety. That is to say that it circumvented safety. To the scada operator and PLC it appeared that the setpoint to the centrifuge VSD was output correctly and that the feedback from the speed control loop was within tolerance of the output setpoint, when in fact neither the setpoint output sent via Profibus nor the actual speed returned over Profibus were as programmed or as visualised. The modified code blocks in the Siemens controller injected new output values, overriding those set by the original PLC code and then falsified the measured value so that the PLC code was entirely ignorant of deviant behaviour of the VSDs. In a ‘real-world mimics Hollywood’ style, reminiscent of Oceans Eleven, the virus gathered real operating data and then stored that data to replay as falsified data when the PLC virus blocks were activated. (See Figure 2)
Identity theft
A key characteristic of Stuxnet is its ability to hide itself from detection and that elements of it carried a genuine Verisign trusted digital signature that had been stolen from Realtek Semiconductor Corporation, a well-respected Taiwanese manufacturer of ICs, network devices and computer peripherals. The day after that security certificate was revoked by Verisign a new Stuxnet variant was released with another stolen Verisign digital signature – this time belonging to JMicron, another Taiwanese manufacturer of network devices, HDD interfaces and computer peripherals.
Who and what can you trust?
The theft of trusted digital signatures and the more recent theft in April 2011 of SecureID encryption keys from security provider RSA leaves users asking the question: Who and what can you trust:
* Can you trust a digital signature in a Windows driver?
* Can you trust an RSA SecureID tag?
* Can you trust your operating system?
* Can you trust your PLC programming/monitoring system?
These incidents are non-trivial because we see in Stuxnet that trusted signatures are used for malicious purposes and the stolen RSA data was used to successfully penetrate the computer systems of US defence supplier Lockheed Martin.
One of the tricks that Stuxnet pulls is to replace operating system calls that list files (FindFirstFileW, FindNextFileW, FindFirstFileExW, NtQueryDirectoryFile and ZwQueryDirectoryFile) so that they do not list some of the virus’ files.
In order to hide the modified PLC code from the PLC engineers the virus renames the Siemens DLL (s7otbxdx.dll) that the Simatic Manager programming system uses to handle block exchange with the S7 PLC and replaces it with its own modified DLL. The substituted DLL acts as a man-in-the-middle, passing the majority of DLL exports directly to the renamed original DLL but handling certain exports with substituted methods that do not return the malicious PLC blocks that the virus inserts in the PLC application. (See Figure 3)
For any self-respecting PLC programmer, identifying the code that masks a feedback loop should be quite trivial – just start up the PLC engineering software and the problem will become quite clear. But the Stuxnet developers took that into account: the code that Stuxnet loads into the target PLC is also hidden. In Symantec’s words, “Stuxnet is not 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,”4
Transfer mechanisms and RPC
Stuxnet incorporates the ability to run and replicate from USB memory sticks and this may have been the initial attack vector.
However, transfer by USB flash drives is not the only mechanism incorporated in the virus – it employs multiple transfer mechanisms including peer-to-peer networking, SQL and Ole Automation Stored Procedures. For peer-to-peer networking Stuxnet uses Windows Remote Procedure Call (RPC). This is significant for Control and Automation engineers because this is also the mechanism that OPC Classic, WinCC, file shares and print spoolers use – it is not a transport protocol that can easily be disabled in the control environment.
Using MSSQL, Stuxnet exploited the fact that the WinCC SQL access uses a hardcoded username and password, both of which can be found on the Internet.
What Windows’ vulnerabilities does Stuxnet exploit?
Stuxnet uses multiple Microsoft vulnerabilities that have subsequently been patched by Microsoft. These include:
The air gap as a defence
Some scada users remain of the opinion that a physical separation of scada from enterprise systems is a valid approach to control system security. So let us put that to rest once and for all.
This is the response of The Subcommittee on National Security, Homeland Defense, and Foreign Operations at its May 2011 hearing5, “In our experience in conducting hundreds of vulnerability assessments in the private sector, in no case have we ever found the operations network, the scada system or energy management system separated from the enterprise network. On average, we see 11 direct connections between those networks. In some extreme cases, we have identified up to 250 connections between the actual producing network and the enterprise network.”
Even Siemens has finally acknowledged that this is not a viable approach (although they still refer to it in their best practice documentation). Stefan Woronka, Siemens’ director, Industrial Security Services recently told an audience to,“[f]orget the myth of the air gap – the control system that is completely isolated is history.”
What is Siemens’ response to Stuxnet?
At the Siemens 2011 Automation Summit held in Florida, USA, at the end of June Siemens announced the following security initiatives:
* Siemens is planning to open several Security Hubs around the world with the aim of improving the flow of security information between Siemens, SIs and end users.
* A family of new S7 communications processors and network interface cards is being developed to support secure protocols and source and destination authentication.
* Encryption of S7 project files and function block encryption in the PLC is planned for the Step7 programming language.
* A new automation firewall will be released utilising Microsoft’s Threat Management Gateway technology.
* A partnership with McAffee to implement application whitelisting in SIA systems.
* A suite of security service offerings to help SIs and end users implement best practices in Control and Automation systems. One element of this is the Security Quick Assessment tool for evaluating a site’s security status quo.
What technologies could assist in prevention/early detection?
There are both immediate and longer term actions that users can implement to improve security in their control systems and to minimise the likelihood and severity of disruption from attacks by Stuxnet style viruses. These actions include:
* Becoming au fait with ANSI/ISA-99 Security for Industrial Automation and Control Systems and implementing standards-based security solutions.
* Auditing basic account settings to ensure that default users and default passwords or blank passwords are removed.
* Requiring strong password with regular expiry.
* Removing user accounts immediately a user leaves an organisation.
* Removing all but the essential software applications from each C&I PC.
* Disabling all but the required Windows services and transport protocols.
* Disabling all but the necessary physical and logical communications ports.
* Disabling removable storage where possible.
* Where removable storage is necessary – ensure that it has a write protect tab and is write protected by default.
* Disabling Autoruns.
* Ensuring that all the identified Microsoft vulnerabilities that are associated with Stuxnet have been patched in all PCs in the Control and Automation and Enterprise networks, or which are occasionally connected to these networks.
* Keeping operating systems and applications up-to-date with patches as recommended by the C&I application vendor.
* Segregating Enterprise (business) networks from C&I networks and introducing a DMZ so that all traffic between the two must pass through the DMZ.
* Where applicable using a safety system from a different vendor to that of the PLC system.
* Segregating the C&I network into security zones, each firewalled and knowing exactly what data should be travelling along what data conduits.
* Introducing firewalls that incorporate source and destination authentication.
* Installing firewalls purpose made for C&I environments and which incorporate deep packet inspection.
* Introduce data diode where applicable to enforce one-way network traffic.
* Installing application whitelisting solutions.
* Managing software assets with the same, or more care, than hardware assets are managed.
Glossary
Defence in depth
Defence in depth is an information assurance (IA) strategy in which multiple layers of defence are placed throughout an information technology (IT) system. It addresses security vulnerabilities in personnel, technology and operations for the duration of the system’s life cycle.6
Rootkit
A rootkit is software that enables continued privileged access to a computer while actively hiding its presence from administrators by subverting standard operating system functionality or other applications.6
RPC
A remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.6
Zero-day attack
A zero-day attack or threat is a computer threat that tries to exploit computer application vulnerabilities that are unknown to others or the software developer, or for which no security fix has been released.
About the author
Andrew Ashton has electrical, mechanical and business qualifications and has been active in automation and process control since the early 1980s. Since 1991 he has headed up a company that has developed formulation management systems for the food, pharmaceutical and chemical manufacturing industries and manufacturing solutions involving the integration of various communication technologies and databases. Developed systems address issues around traceability, systems integration, manufacturing efficiency and effectiveness. Andrew is a contributing editor for SA Instrumentation and Control.
| Tel: | +27 31 764 0593 |
| Email: | [email protected] |
| www: | www.technews.co.za |
| Articles: | More information and articles about Technews Publishing (SA Instrumentation & Control) |
| Tel: | +27 11 548 9960 |
| Email: | [email protected] |
| www: | www.profiafrica.co.za |
| Articles: | More information and articles about PI SA (PROFIBUS & PROFINET SA) |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version