November/December 2010

Web Exclusive

Stuxnet: Cybersecurity Trojan horse

What does it mean to industrial control system cybersecurity?

Fast Forward

  • Automation engineers need to take the Stuxnet cybersecurity seriously and learn from it.
  • Stuxnet is not just an IT worm but a weapon developed to attack physical processes.
  • Stuxnet uses programming software to upload its own code to PLCs.
 
By Joe Weiss

Much has been written about Stuxnet from many different sources and perspectives. However, there are still many misconceptions and lessons to be learned. The purpose of this article is to provide observations and recommendations for industrial control system (ICS) cybersecurity practitioners and standards organizations to consider. Stuxnet is not just an Information Technology (IT) worm but a weapon developed to attack physical processes.

Background

web1111Prior to Stuxnet, it was believed any cyber attack (targeted or not) would be detected by IT security technologies such as firewalls or intrusion detection systems and defense-in-depth would prevent damage to physical processes. However, previous actual control system cyber incidents (malicious and unintentional) have demonstrated that many ICS cyber incidents are not readily detectable, and they can cause physical damage even with existing defense-in-depth designs. Departments of Energy and Homeland Security (DOE and DHS)-sponsored work have continued developing ICS intrusion detection system (IDS)/intrusion prevention system (IPS) technologies and hardening supervisory control and data acquisition (SCADA) systems. It is important to note the use of the term SCADA, as these same technologies have not been employed on many legacy non-SCADA devices such as programmable logic controllers (PLCs), electronic drives, process sensors, and other field devices. Another implicit assumption in the standards being developed such as ISA99 and the North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) standards is they would be comprehensive enough to address cyber attacks against ICSs including sophisticated attacks. The inadequacy of these assumptions against a sophisticated attack such as Stuxnet requires a detailed reassessment of ICS cybersecurity assumptions.

It is my belief that whoever developed Stuxnet-I do not believe it is clear who created Stuxnet-was willing to spend a considerable amount of resources (people and capital) to develop the worm and attack. They did not want to be identified, at least in the early stages, and were targeting specific processes in a surgical manner. I do not believe that copycats will be this surgical nor care if they are discovered. This could have significant ramifications for protecting critical infrastructures, which most likely would be vulnerable to similar attacks.

Stuxnet history

Stuxnet is arguably the first cyber attack specifically targeting ICS devices. Stuxnet was unknown until mid-July 2010, when it was identified by investigators with VirusBlockAda, a security vendor based in Minsk, Belarus. (It is not clear what systems VirusBlockAda was monitoring or from which customer).

The worm is notable not only for its technical sophistication, but also because it targets ICSs designed to run power plants including nuclear plants, smart grid, water systems, off-shore oil platforms, ships, other critical infrastructure, and even critical infrastructures in Iran. Ironically, DOE had an R&D Peer review the week Stuxnet was disclosed and none of the DOE R&D projects knew of its existence.

Researchers at Symantec identified an early version of the worm created in June 2009, and that the malicious software was then made much more sophisticated in January 2010. This earlier version of Stuxnet acted in the same way as its current incarnation-it connected with Siemens PLCs-but it did not use some of the newer worm's more remarkable techniques to evade antivirus detection and install itself on Windows systems. Those features were probably added a few months before the latest worm was first detected, said Roel Schouwenberg of Kaspersky Labs. "This is without any doubt the most sophisticated targeted attack we have seen so far," he said.

After Stuxnet was created, its authors added new software, which allowed it to spread among USB devices with virtually no intervention by the victim. And they also somehow managed to obtain encryption keys belonging to chip companies Realtek and JMicron and digitally sign the malware so antivirus scanners would have a harder time detecting it. Realtek and JMicron have offices in the Hsinchu Science Park in Hsinchu, Taiwan, and Schouwenberg believes someone may have stolen the keys by physically accessing computers at the two companies. This allowed Stuxnet to defeat two-factor authentication.

Stuxnet leveraged unpatched four complimentary "zero-day" flaws in Microsoft products. A zero-day event (or zero-day virus or zero-day infection) in computer and Internet terminology is essentially a virus or some other malicious code so new that the antivirus and antispyware software makers have not yet come up with a defense and may not have even detected its existence.

Stuxnet is more technically remarkable than the Google attack, Schouwenberg said. "Aurora had a zero-day, but it was a zero-day against [Internet Explorer version 6]," he said. "Here you have a vulnerability, which is effective against every version of Windows since Windows 2000." Recall, Microsoft no longer supports Windows 2000 and other older versions still heavily used in ICS applications.

Although the first version of the worm was written in June 2009, it is unclear if that version was used in a real-world attack. Schouwenberg said he believes the first attack could have been as early as July 2009. The first confirmed attack that Symantec knows about dates from January 2010, said Vincent Weafer, Symantec's vice president of security technology and response. Most infected systems are in Iran, he added, although India, Indonesia, and Pakistan are also being hit. This in itself is highly unusual, Weaver said. "It is the first time in 20 years I can remember Iran showing up so heavily."

Many people think of Stuxnet as a data exfiltration issue. Data exfiltration refers to the unauthorized covert transfer of information out of a computer system. However, Stuxnet is more than data exfiltration-it is the first rootkit targeted at PLCs. A rootkit is a set of programs and code that is an undetectable presence of malicious software on a computer. It is essentially a weaponized attack against a process. It has the ability to take advantage of the programming software to upload its own code to the PLC. In addition, Stuxnet then hides these code blocks, so when a programmer using an infected machine tries to view all of the code blocks on a PLC, they will not see the code injected by Stuxnet. Thus, 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. In particular, Stuxnet hooks the programming software, which means when someone uses the software to view code blocks on the PLC, the injected blocks are nowhere to be found and cannot accidentally be overwritten. Stuxnet contains 70 encrypted code blocks that appear to replace some foundation routines. Before some of these blocks are uploaded to the PLC, they are customized depending on the PLC. There are reports that more than 100,000 machines have been impacted by Stuxnet. However, Stuxnet is a multi-dimensional attack. The visible aspect is the data exfiltration, which does not affect the PLC; the aspect that affects the PLC, which is the true weapon, is not visible. Based on the work by Ralph Langner presented at the Applied Control Solutions 2010 Conference in Rockville, Md., the payload is not employed until specific process conditions are met. Consequently, it is not clear how many machines were actually infected by the "weapon."

Stuxnet can use MS08-067, the same vulnerability used by Downadup (a.k.a. Conficker) to spread. MS08-067 is a critical vulnerability in the Windows Server Service on Windows 2008/Vista/2003/XP/2000 computers, which allows hackers to gain remote control of the affected computer with the same privileges as a logged on user. If this user had administrator rights, the hacker can take complete control of the system. Stuxnet appeared at the same time as Conficker. Stuxnet can use the Conficker worm to spread itself. Stuxnet has also been tied back to June 2009, which was when Conficker was first identified. That was also when the NERC Advisory on Conficker was issued because of power plant issues. I recently received an e-mail that a major oil company found Conficker in their control systems-brought in by a thumb drive. Surprise! One of the most significant issues is a sophisticated ICS cyber attack will most likely not be identified by the ICS community. Consequently, the ICS community needs to team with IT researchers like those from Symantec and Kaspersky.

Note that soon after the July disclosure, Microsoft issued a patch for the Windows vulnerability (LNK) that Stuxnet uses to spread from system to system (Microsoft LNK Vulnerability Brief Technical Analysis (CVE-2010-2568)). Additionally, several antivirus suppliers provided new anti-virus signatures. However, none addressed the malicious code written to the PLC firmware.

Implications of Stuxnet

Whether intentional or not, Stuxnet managed to exploit a number of generic weaknesses in ICS cybersecurity:

  • Stuxnet used thumb drives to physically enter the system and then exploited several Windows vulnerabilities to get access to the PLC firmware. By attacking the Windows interface, the focus was on Windows and not on the PLC attack. Additionally, much of the initial government response to industry was not even directed to ICS engineers.
  • Industry does not know what a sophisticated ICS cyber attack will look like or what control system unique attributes it will target. A sophisticated attack such as Stuxnet most likely will not be found by ICS IDS/IPS or ICS security researchers. The DOE-funded efforts to develop IDS rules and signatures were not effective.
  • The DOE-funded projects did not address older versions of Windows that are prevalent with many ICS installations and is a vector for Stuxnet. The DOE-funded Integrated Security System did not find it. Industry needs to understand the unique ICS cyber vulnerabilities that would not be discovered via a typical IT analysis.
  • There were six propagation vehicles for Stuxnet with only one having a patch. Consequently, patch management could have had at best a minor impact on stopping the attack.
  • There were no DOE or DHS efforts addressing PLCs, as the focus was on Windows-based SCADA systems, distributed control systems, and archival databases. Consequently, there were no specific IDS/IPS signatures being developed.
  • The Stuxnet code is modular, and many parts of the Stuxnet code could be applied to any ICS vendor. There is a need to be prepared for a targeted cyber attack against any ICS vendor and have recovery activities in place.
  • Antivirus solutions may not be successful. Until the actual attack is understood, IT-type solutions can provide a false sense of security and/or impact the performance of the ICS device.
  • It took very experienced IT security researchers to find the worm, but it will take knowledgeable ICS personnel to understand the payload. There needs to be an integrated team of IT security researchers, ICS experts, threat analysts, and forensic experts to address these sophisticated types of attacks.
  • There may be possible connections with previous cyber outbreaks (e.g., Conficker). It is important to connect the dots and reexamine previous ICS cyber incidents in light of these "new" attacks.
  • The Stuxnet worm represents a different form of interdependency-ICS vendors. In this case, infecting Siemens PLCs can affect multiple industries each of which can have other interdependencies. These interdependencies need to be understood.
  • The NERC CIP process is ineffective to address an event such as Stuxnet, particularly in an operational (substation or plant) environment.
  • Stuxnet places a critical aspect of smart grid in jeopardy-reliance on key management. Smart grid cybersecurity mitigation approaches need to be reexamined.

Other issues

The Washington Post reported a senior defense department official writing in Foreign Affairs magazine has declassified and disclosed a cyber attack on U.S. government (military) computers and networks propagated by a USB stick, loaded onto a U.S. military laptop in the Middle East in 2008. "That code spread undetected on both classified and unclassified systems, establishing what amounted to a digital beachhead, from which data could be transferred to servers under foreign control," he said in the article. Sounds similar to Stuxnet, doesn't it?

As for regulatory issues, the NERC CIP standards effectively exclude Stuxnet as the delivery vehicle is a thumb drive, not a routable protocol. Stuxnet uses compromised encryption keys. Since smart grid will rely on key management, what does this mean for smart grid? Moreover, PLCs are used throughout the smart grid with renewables, etc.

US CERT issued an update on 2 September 2010 on the Stuxnet Advisory (ICSA -10-238-01A - Stuxnet Malware Mitigation. However, the advisory does not discuss how to remove the infection at the PLC level or even identify how to find it.

What can be done specifically for Stuxnet is questionable, as it may not be possible to identify which controllers have been "infected." As this is an engineering attack, plant and substation engineering design and planning organizations need to work around this type of attack, as it cannot be worked around from a cyber perspective. The convergence of safety, protection, and control on the same networks will allow attacks such as Stuxnet to have devastating consequences.

Recommendations:

  • Perform a detailed gap analysis on ISA S99, the NERC CIPs, the Nuclear Regulatory Commission (NRC) Regulatory Guide 5-71, and Nuclear Energy Institute (NEI) 08-09.
  • Develop and implement ICS cybersecurity policies and procedures.
  • Understand what you actually have in all your ICSs.
  • Apply technologies appropriate to ICSs.
  • Have the engineering and planning organizations evaluate the potential impacts of a Stuxnet attack.
  • Have back-up plans ready, as ICSs will ultimately be impacted by either intentional or unintentional cyber incidents.
  • ICS cybersecurity research needs to include ICS field devices that generally have minimal security, but can have maximum consequences.

Conclusions

  • Stuxnet is an attack on physical processes, which means it is not "patchable."
  • Given a sophisticated cyber attack targeted at ICSs, there is little chance the ICS community will be able to detect it.
  • IT malware researchers have the best chance of finding it. The ICS community needs to meet them and work with them.
  • For Stuxnet, the ICS community needs to understand how to detect the infection so as to know whether to trust the control systems.
  • Do not get fixated on Siemens, this could happen to any ICS.
  • Have back-up plans ready when your system is impacted.
ABOUT THE AUTHOR

Joe Weiss, PE, CISM, works for Applied Control Solutions, LLC in Cupertino, Calif. He is the author of Protecting Industrial Control Systems From Electronic Threats (https://www.isa.org/store/protecting-industrial-control-systems-from-electronic-threats/116214). Contact him at joe.weiss@realtimeacs.com.