Stuxnet Report IV: Worm Slithers In

Wednesday, March 16, 2011 @ 09:03 PM gHale

EDITOR’S NOTE: The stage is now set for Stuxnet to infiltrate an industrial control system. Go back in time before anyone discovered the worm and see how it was able to penetrate a system. After understanding that frightening journey, it is easy to see how Stuxnet was one of the most complex and well-engineered worms ever seen. Security professionals Eric Byres, Andrew Ginter and Joel Langill teamed to publish a white paper entitled “How Stuxnet Spreads – A Study of Infection Paths in Best Practice Systems.” This is the fourth part in a series of stories detailing just how the Stuxnet worm was able to infiltrate a system, and how automation professionals can keep an eye out for the next type of attack.

By Eric Byres, Andrew Ginter and Joel Langill
Given the well-secured industrial control system, it seems very unlikely a worm like Stuxnet could ever penetrate all the way to the PLCs. Yet clearly it did.

Siemens reported 22 sites that experienced infected control systems and certainly there were other sites, such as those with other vendors’ products (and would not report infections back to Siemens). The goal here is to suggest possible answers to the vexing problem of how the worm made it through to the PLCs.

Part I: Stuxnet attacked the Siemens SIMATIC PCS 7; Why that system?
Part II: How did Stuxnet infect a system?
Part III: A “high security site” targeted by Stuxnet or the Next Gen of Stuxnet-like worms.
Part IV: How Stuxnet infected a minor computer and then got deep inside a control system.
Part V: What should this mean for security of industrial control systems in the future?
Download the complete White Paper at Tofino Security.
Talk to Me: Stuxnet: Joint Operation Nets Victim

To answer that question, let us go one year back in time, to March 1, 2010. Stuxnet has been refined to its mature form, using the shortcut vulnerability rather than common “autorun.inf” trick to propagate via USB drives. No patches exist for the zero-day vulnerabilities the worm uses. No anti-virus signatures exist for the worm. No security researchers know the worm exist. The stage is set.

Now using the following illustration as a road map, we will follow the Stuxnet as it compromises the state-of-the-art high security network we described last week, infiltrates the PLCs and destroys the target industrial process. And as a bonus, at each stage we also will look at alternative pathways the worm could have taken.

Compromising the site’s networks.

Compromising the site’s networks.

Initial Handoff of the Worm
In order to begin its infection of the intended site, Stuxnet’s creators needed to transfer the worm to an unwitting employee who would “carry” it into his or her company. We can only guess at how these handoffs might have occurred, but Stuxnet’s creators had a number of options open to them.

One possibility is that a saboteur working at contractor’s office might have given a target employee an infected USB drive containing technical documents. Or the handoff might have happened at an industry tradeshow, where free USB drives are common give-aways for the distribution of conference materials (in 2009, one of the authors received a “new” USB drive at a major vendor’s tradeshow as a gift — that USB drive was infected with a different worm).

Maybe a USB drive wasn’t used at all. Stuxnet could have been launched toward the victim company through a targeted email attack. The email would contain a special dropper program designed to install Stuxnet when an attached document was opened by the victim. The creators of the recent Night Dragon attacks used infected PDF files to seed their victims.

The initial infection could also occur by a contractor supplying PLC project files deliberately infected. Due to the nature of contractor/client relationships and the need for continuous collaboration, a variety of project files are freely exchanged between team members. These files not only include the PCS 7 project files the Stuxnet worm could piggy back on, but also other potentially vulnerable file formats including drawing, spreadsheet, database and PDF files that future worms could exploit.

Exactly how the initial handoff occurred will never be known. But what we do know (thanks to some excellent analysis by Symantec) is Stuxnet’s creators performed this handoff at least ten times between June 2009 and May 2010. We also know these handoffs were made to at least five separate target organizations. In other words, the owners of Stuxnet continued to introduce the worm until they were convinced it had reached and destroyed its target industrial process. Only Stuxnet’s very public discovery ended these repeated injections of Stuxnet into the victim’s networks.

Infection of Initial Enterprise Computer
Once an employee had an infected USB drive, it would only be a matter time before it was plugged into a workstation and viewed using Windows Explorer, starting the infection process. Since there were no signatures for the Stuxnet worm in March of 2010, the workstation’s anti-virus software would not generate any alerts. The fact the workstation is fully patched is of no help, because the LNK vulnerability on shortcut files has no patch. Nor do the escalation of privilege vulnerabilities the worm uses to gain system-level access on the workstation. The worm was also able to install “rootkit” software that hides the files used by the worm when browsing the infected flash drive. The victim has no chance.

Propagation to other Enterprise Computers
Once on a network, Stuxnet becomes aggressive. Within a few hours, the worm would likely spread to printer servers and file servers on the Enterprise Control Network connected to the compromised workstation. Just how aggressive is illustrated in graphic below which shows a graph of the machines infected from a single successful handoff that occurred on May 11, 2011.

A graph of computers infected from an initial victim (May 11th, 2010 infection). Courtesy of Symantec Corporation, W32.Stuxnet Dossier, Version 1.4.

A graph of computers infected from an initial victim (May 11th, 2010 infection). Courtesy of Symantec Corporation, W32.Stuxnet Dossier, Version 1.4.

At this point, the worm might lie dormant, infecting new USB flash drives as they are inserted into compromised computers, and waiting for someone to carry such a flash drive (and the worm) to a protected network. Alternatively, it may request new instructions from a command and control server. All personnel carrying and using infected flash drives would be unaware the worm is now on their drives, because the rootkit hides the worm’s files from the user.

Alternative pathways: Some additional alternative paths for infection of the Enterprise Control Network include:

  • The employee may have attached an “approved” external drive to an infected machine while visiting a contractor and subsequently brought this drive back into the company network.
  • The employee may have connected his or her laptop to a compromised network offsite, and thus infected the laptop and then subsequently connected it to the Enterprise Control Network on his or her return.
  • A contractor may have visited the site, bringing and using a compromised external drive on the site network.
  • A contractor may have visited the site, bringing and using a compromised laptop on the site network.
  • A contractor or employee at another facility may have used a file share at this site over the WAN and so compromised the Enterprise Control Network.

Penetrating the Perimeter Network
Very quickly a large number of the workstations on the Enterprise Control Network would be infected. Almost certainly one of these computers would belong to an employee who would interact with the person who manages the process historian server on the Perimeter Network. Now the worm has a potential path deeper into the network.

For example, as is common in the industry, the manager has a file share configured on his workstation, as do most employees in that group. The control system team uses the shares on their own workstations to exchange large files with each other over the Enterprise Control Network, rather than exchange the files via the space-limited file servers located on the Enterprise Control Network. Of course, only specific domain accounts have access these shares.

Stuxnet uses the domain credentials of the user logged into the compromised machine to send a copy of itself to the manager’s workstation and activates that copy, compromising that workstation. Stuxnet is now ready to make its move deeper into the control system.

In quite a few plants, the historian manager would routinely access the Siemens WinCC Central Archive Server (CAS) historian server from his workstation over a VPN. Typically, the administrator uses the web interface and Siemens OS Client to the historian to access the CAS server. The web interface provides a view of functionality the historian exposes to users, and the OS Client allows the administrator to access advanced features of the historian, used primarily for configuration and administration tasks.

Through the manager’s compromised workstation the Stuxnet worm contacts the local instance of the SQLServer database “client” on the compromised workstation and discovers the OS Clients’ connection to the WinCC database installed as part of all CAS servers. The worm contacts the WinCC SQLServer database on the CAS server and propagates to the CAS server on the Perimeter Network through that database connection. The worm installs itself on the CAS server by manipulating the CAS database contents and stored procedures within the database. The worm now has a foothold on the Perimeter Network.

Alternative pathways: Some alternate paths of infection of the Perimeter Network include:

  • At many “real world” sites, companies do not routinely patch Perimeter Network hosts. As a result, any VPN connection from a compromised host on the Enterprise Control Network to a host on the Perimeter Network using common Windows RPC communications is at risk.
  • While it does not follow the Siemens security recommendations, it is not unusual for the VPN connections from Enterprise Control Network workstations to the Perimeter Network to not restrict communications to specific ports and hosts. In such cases, any Enterprise Control Network workstation with a VPN connection to the Perimeter Network puts at risk every server or workstation on the Perimeter Network with file sharing enabled or a printer connected.
  • A contractor or vendor using a remote access mechanism to provide assistance with the support of hosts on the Perimeter Network may remotely access that network from a compromised laptop or workstation. If the contractor can communicate with any exposed file shares or print spoolers on the Perimeter Network that would permit compromise of those hosts. If the contractor or vendor’s workstation can communicate with any unpatched hosts exposing the MS08-067 vulnerability, that channel also permits compromise of hosts on the Perimeter Network.
  • While this does not follow the Siemens security recommendations, site administrators on the Enterprise Control Network sometimes use file shares to exchange information with servers on the Perimeter Network. Such file shares expose the Perimeter Network to compromise.

Propagation to other Perimeter Network Computers
Once the worm has a foothold in the Perimeter Network, it would start aggressively spreading on this virgin network, just like it did on the Enterprise Control Network. Certainly it would attempt to infect any print servers and file servers it could discover. The worm would also identify the WinCC software installed on the Web Navigation and CAS Servers, and would likely infect these local databases. If the Web Navigation Server configuration allows it to use Terminal Services for remote access, there could also be STEP 7 software installed on this host, offering the worm the opportunity to install itself inside the STEP 7 project files.

Closing in for the Kill: Propagation to Process Control Network and Control System Network

Now Stuxnet is only a few hops from its final target. Once the worm has infected the PCS 7 servers in the Perimeter Network, it is trivial to utilize the network connections to the servers located in the Process Control Network. Now it would start moving into the WinCC Servers that connect directly to the PLCs

To make matters worse, once there is an infection in the STEP 7 project files, it is only a matter of time before an authorized user copies a project file to the Process Control or Control System Networks. If an administrator were to copy these files to another plant at another site and use the files there, these STEP 7 project files would lead to compromise of that new site by the Stuxnet worm.

Finally, the WinCC CAS on the Perimeter Network has database connections configured through the ISA server, so the historian server can request historical data from Operator System (OS) Servers on the Process Control Network. The Stuxnet worm can propagate over these connections into these OS Servers and infect all servers on the Process Control Network which expose either print servers, file servers or which have WinCC or STEP 7 software installed on them. STEP 7 is typically on engineering stations, while WinCC is common on operator and engineering stations.

Alternative pathways: Alternative paths for infection of the Process Control and Control System Networks include:

  • File shares or print spoolers may have exposure to hosts on the Perimeter Network. Even if a site did not mean to expose such services on the Process Control Network to the Perimeter Network, WinCC components on the Perimeter Network make heavy use of Windows RPC communications to interact with components on the Process Control Network. Print spooling and file sharing use RPC communications. Any path through the Microsoft Internet Security and Acceleration (ISA) firewall that permits remote procedure calls (RPC) communication would permit connections to print spoolers and file shares, regardless if personnel designing ISA firewall rules anticipated such connections. For example, if an OPC Classic server (such as OPC Data Access) on the Process Control Network serves information to an application on the Perimeter Network, that connection exposes the RPC communications path since it is the foundation of the OPC Classic protocol.
  • Most servers on the Perimeter Network use database connections to servers on the Process Control Network to acquire data for presentation to enterprise users. If any of those servers or workstations becomes compromised, the worm can propagate over that machine’s database connection to the Process Control Network.
  • PLC programming projects routinely carry out on test beds for which security measures are weaker than those applied to production networks. Such test beds may become compromised by removable drives, remote vendors, connections to compromised enterprise hosts or other means. If those infected project files communicate to hosts on Process Control and Control System Networks, the worm compromises those new hosts.
  • A contractor or vendor using a remote access mechanism to provide assistance with the support of hosts on the Process Control Network may remotely access that network from a compromised laptop or workstation. If the contractor can communicate with any exposed file shares or print spoolers on the Process Control Network that would permit compromise of those hosts. If the contractor or vendor’s workstation can communicate with any unpatched hosts exposing the MS08-067 vulnerability, that channel also permits compromise of hosts on the Process Control Network.
  • Using an infected external drive on any single host on the Process Control Network would compromise that host and the other computers on that network.

The Final Attack
Stuxnet will now be able “smell” its victim and will begin to move in for the kill. Some of the compromised OS and WinCC Servers will manage connections to the S7 PLCs that control the physical process. When Stuxnet discovers one of these, it installs a special driver on the computer, effectively hiding any modified code from administrators or engineers later querying the PLCs. This makes the worm “invisible” once it is on the PLC.

The worm then connects from the servers to all available PLCs and looks for specific models of Siemens PLCs (namely 6ES7-315-2 and 6ES7-417). If it is able to locate one of these two models, it “fingerprints” the PLC by checking for the existence of certain process configurations and strings in the PLC.

If Stuxnet finds what it is looking for in the PLC, it starts one of three sequences to inject different STEP 7 code “payloads” into the PLC. The worm replaces the PLC’s PROFIBUS driver and then significantly modifies the main PLC program block (Organizational Block 1) and the primary watchdog block (Organizational Block 35). As well, depending on which sequence is selected, the worm will inject between 17 and 32 additional function blocks and data blocks into the PLC.

Once the modified logic is running on one PLC, it begins to attempt connection to other PLCs that are infected. These may have been infected through the same STEP 7 system or via a different Engineering Station, WinCC Server or other computer. It then synchronizes an attack sequence in all the PLCs so the attack will occur simultaneously across multiple PLCs.

This attack sequence is designed to radically change the output frequencies of specific Variable Frequency Drives (VFDs) and thus the speed of the motors connected to them, essentially sabotaging an industrial process. At the same time, it plays back previously recorded process data to the WinCC Servers, making the operators believe that all is well in their process, when in fact Stuxnet is tearing it appear.

Lesson: There are many pathways to PLCs

This analysis shows that even at an industrial site using security best practices, there are many ways that an advanced cyber threat such as Stuxnet can move from the outside world, through the various networks and reach the process controllers. In the final installment in this series we will explore what owners, designers and operators of ICS need to consider in order to prepare for the next Stuxnet.

Next: What does the future hold for security of industrial control systems?

Eric Byres, P. Eng., ISA Fellow, is the chief technology officer at Byres Security Inc. (eric@byressecurity.com); Andrew Ginter, CISSP, is the chief technology officer at Abterra Technologies (aginter@abterra.ca) and Joel Langill, CEH, CPT, CCNA, is the chief security officer at SCADAhacker.com (joel@scadahacker.com) and Dept. of Critical Infrastructure Officer with The Cyber Security Forum Initiative (csfi.us).