Post-Stuxnet industrial security

By now, Stuxnet has become well known as the computer malware worm that allegedly infected Iranian organisations in 2010, most notably those plants alleged to be used for uranium enrichment. Theories abound as to its clandestine origins but, regardless of its original purpose, Stuxnet now proves that insufficient IT security opens automation networks to a clear and present threat.

Following its discovery in June 2010, the Stuxnet worm caused a worldwide sensation. It is the first publicly known rootkit attack targeted at industrial plants. It has infected tens of thousands of PCs and abused and manipulated automation software running on Windows operating systems. Its ultimate purpose: to infiltrate malicious code into the controllers of specific real-world industrial installations.

Experts have long warned that malware and insufficient IT security pose a threat to automation networks, but Stuxnet offers concrete proof that these threats can no longer be ignored. The actual hazard, however, no longer originates from Stuxnet itself, but rather comes from mutations that copycats can now create with the same basic techniques. And while Stuxnet focused on products from the Siemens Simatic family and on Step 7 PLC projects with very specific properties, such mutations could also affect components from other vendors, ultimately producing malware a lot less selective in its damaging impact.

Apart from the fact that industrial PCs are often not (and cannot be) equipped with antivirus software, Stuxnet has also made it clear that conventional virus scanners do not provide protection against this calibre of attack. The analysis of Stuxnet has shown that the worm had been around in the wild unnoticed for at least 12 months before its discovery. Because Stuxnet did not use any of the known malware signatures, existing antivirus programs did not detect it during that time.

Damaging impact in four steps

To plan protective measures against future Stuxnet-like attacks, a basic understanding of the worm’s activities is essential. It unfolds its damaging impact in four steps on different layers.

Step 1 - Infection of Windows PCs:

The worm uses an aggressive mix of mechanisms to spread onto and contaminate both networked and non-networked Windows PCs via USB flash drives. To do this, it utilises four previously unknown vulnerabilities (by so-called zero-day exploits). These weaknesses have existed in several generations of Windows operating systems. To date, security patches have only partially fixed them. Besides a number of encrypted files that the worm stores in the %SystemRoot%\\inf\\ directory, Stuxnet installs two device drivers - %SystemRoot%\\system32\\drivers\\MrxNet.sys and %SystemRoot%\\system32\\drivers\\MrxCLS.sys.

These drivers have been signed with private digital keys stolen from Realtek and JMicron. Therefore, they contain certificates rated as trustworthy by Windows operating systems.

Step 2 - Abuse and manipulation of automation software

If Stuxnet comes across installations of WinCC visualisation or Step 7 engineering components on an infected PC, it abuses and manipulates any found WinCC databases and Step 7 projects. This will further proliferation and persistency on the PC and help it to locate the controllers referenced in those projects as potential targets for step 3. Stuxnet also renames the dynamic link library s7otbxdx.dll in %SystemRoot%\\system32\\ (the DLL responsible for the communication between the Simatic Manager and the S7 controllers) to s7otbxdsx.dll, and replaces it with a wrapper DLL of its own under the name of s7otbxdx.dll in the same directory.

Step 3 - Injection of malicious code into controllers

The manipulated wrapper DLL enables Stuxnet to infiltrate arbitrary malicious code into the compromised PLCs, hide those malicious code changes from the programming engineer, and safeguard them from later overwriting. Stuxnet injects this precise malicious code selectively, only into controllers and projects with very specific properties, which is a remarkably sophisticated capability. According to the latest expert findings, the worm is supposed to permanently manipulate frequency converters and turbine controls as inconspicuously as possible. The goal is to disrupt the controlled processes and ultimately destroy the affected equipment.

The malicious code, targeted at the S7-417 series of controllers, combines denial-of-control and denial-of-view techniques into a so-called man-in-the-middle attack in ways hardly considered feasible up to now. Under the attack, the legitimate PLC program completely loses control of the process without the PLC or the operating staff in front of their HMIs in the control room even noticing. The attack vector as such is generic. It could be packaged into and provided by exploit tools such as Metasploit, and then - contrary to common belief - even persons without comprehensive insider knowledge could use the information for attacks.

Step 4 - Communication with control and command servers on the internet

From infected PCs, the worm attempts to contact several command and control servers on the internet. Once it establishes a connection, information collected from the target and its environment can be uploaded to those servers. In addition, the worm can receive updates and execute its malicious payload. This adds an extra portion of dynamics to the worm’s potential for espionage and sabotage. Combined with the worm’s capabilities to spread and update itself via peer-to-peer connections and USB flash disks, all of this can have collateral effects even on systems without a network connection, let alone internet access.

Early discovery mitigates risks

An ideal network security appliance should comprise a set of preventive and diagnostic functions that can boost security against Stuxnet-like attacks and reduce their associated risks. While such a device may not actively prevent 100% of infections with malware, due to the diversity of proliferation paths, fast and reliable discovery of such infections is a particularly important aspect of protection. Quick detection will keep the worm from slipping through unnoticed and affecting plants for a long period, as Stuxnet did.

Discover malware on day zero: Integrity Monitoring

Due to the general problems with the deployment of antivirus software on industrial PCs and the timely provision of malware signatures, alternative techniques of integrity assurance are gaining relevance for the protection of industrial systems.

One solution is the CIFS Integrity Monitoring feature offered on Phoenix Contact’s FL mGuard security devices. CIFS, or Common Internet File System, is a file-sharing protocol used by Windows and other operating systems. Viewing files on network file servers and using shared network drives are common activities that utilise CIFS. With integrity monitoring, the user can monitor configurable sets of files for unexpected modifications of executable code. When initialised, integrity monitoring computes a baseline of signatures for all monitored objects and then periodically checks them for any deviations. This process works without any external supply of virus signatures, without the risk of disrupting operations through false positives, without installation of software, and with only a moderate load on the monitored PCs. The mGuard thus discovers suspect file modifications promptly, and reports them via SNMP and email to network management systems or responsible administrators.

In a test study performed at the University of Ostwestfalen-Lippe in Lemgo, Germany, researchers from the independent Institute of Industrial Information Technologies (inIT) (www.hs-owl.de/init/en/) have been able to verify that this type of CIFS Integrity Monitoring would have recognised infections with Stuxnet on day zero as unexpected manipulations and warned asset operators against it long before any antivirus product. The device drivers installed by Stuxnet, as well as the modifications performed by the worm on the pivotal Simatic Manager DLL would have been discovered in the process.

Contain proliferation, prevent command and control: Firewall

When spreading across networks and respective vulnerabilities in operating systems, malware often takes advantage of network connections that are not necessary for the productive operation of a plant. By installing a firewall on industrial PCs and controllers, or groups of such devices, the plant can reliably block these unnecessary and unsolicited outbound connections and contain the proliferation of malware to a large extent.

Many plant managers however, install firewall protection only on incoming connections and neglect outgoing connections. Stuxnet demonstrates that both incoming and outgoing connections can potentially spread infection among healthy systems. Therefore, firewalls not only must protect incoming connections, but should also filter the often-neglected outgoing connections as much as possible. This will prevent contacts via outgoing connections to command and control servers on the internet, reducing the associated potential for espionage and dynamic or evolving threats.

Authenticated and authorised PLC programming: User firewall

Most PLCs on the market today barely offer authentication and authorisation functions to protect the process of their own programming. Contrary to popular belief, programming and other manipulations of such controllers do not require a specific or officially vendor-authorised engineering software package. Whoever has network access to the programming port and adheres to the correct protocol will be in the driver’s seat and rule the PLC. Protective measures are typically limited to an access control list (ACL), which restricts programming access to a number of IP addresses. So long as users and programs access the PLC from one of the assigned IP addresses, there is often no further checking or authorisation.

Insidiously, Stuxnet uses those exact programming and visualisation PCs for its attack on the PLCs. The malware’s access to the controllers originates from allegedly authorised nodes. This makes both the ACLs and any static firewall rules useless here.

A user firewall can prevent manipulation of controllers by unauthorised programming access. When in place, the user firewall requires an authorised user to unlock the programming port through an authentication process. The malware cannot provide this authentication on its own. After a specified time, re-authentication can be required, preventing an ‘always open door’ to the PLC.

Conclusion

Bearing in mind the manipulations performed by Stuxnet on the engineering software, it becomes apparent just how important it is to combine the techniques described above. Authorised users should, of course, unlock access through the user firewall only after having assured themselves of the programming environment’s integrity. In turn, the integrity monitoring technology can support this action because it can detect whether or not the programming PC has been compromised.

More advanced security technologies, such as application whitelisting or intrusion prevention, will be restricted to future generations of automation equipment. But all of the methods presented in this paper lend themselves perfectly for retrofitting into existing installations and providing protection now, rather than later.

Key concepts Although the Stuxnet worm has received a great deal of media attention, the greater threat to most control systems is that copycats could use Stuxnet as a blueprint for future attacks. An ideal network security appliance with both preventive and diagnostic functions can boost security against Stuxnet-like attacks and reduce their associated risks. While such a device will not completely prevent malware infections, fast and reliable discovery of such infections is a key aspect of protection.