How Stuxnet (PLC virus) spreads – Part 4

Continued from How Stuxnet (PLC virus) spreads – Part 3 » Read here

Propagation to other Perimeter Network Computers

Once the worm has a foothold in the Perimeter Network, it would attempt to infect any print servers and file servers it could discover. Next, the worm would identify the WinCC software installed on the Web Navigation and CAS Servers, and would likely infect these local databases.

It is also possible that if the Web Navigation Server is configured 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.

Propagation to Process Control Network and Control System Network

Once the worm takes over the PCS 7 servers in the Perimeter Network, it is then trivial to utilize the network connections that exist to the servers located in the Process Control Network to infect the servers within this zone.

Furthermore, once the STEP 7 project files are infected, it is only a matter of time before an authorized user copies a project file to the Process Control or Control System Networks. In addition, 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.

In addition, the WinCC Central Archive Server (CAS) on the Perimeter Network has database connections configured through the ISA server, so that 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 installed on engineering stations, while WinCC is common on both operator and engineering stations.

Some of the compromised OS Servers manage connections to the S7 PLCs that control the physical process. The worm connects to those PLCs and modifies the programming in all the PLCs that match the worm’s selection criteria. It also installs a special driver on the STEP 7 hosts effectively hiding any modified code from administrators or engineers querying the PLCs, making the worm “invisible” once it is installed on the PLC.

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

• File shares or print spoolers may be exposed 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 ISA firewall that permits RPC communications would permit connections to print spoolers and file shares, regardless of whether such connections were anticipated by personnel designing ISA firewall rules.
  
  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 may routinely be carried 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 are communicated 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.

Peer-to-Peer Networking

At this point in the scenario, the physical process may or may not immediately malfunction. The Stuxnet worm was designed to contact one of two command and control (C&C) servers over the Internet for new instructions and updates. The worm exchanges information with these servers over the HTTP protocol, on port TCP/80. The payload of communications with those servers is encrypted, but the “envelope” for the communications is plain-text HTTP. None of the contents of the HTTP traffic matches anti-spam or anti-malware rules in corporate Internet firewalls or intrusion monitoring systems (IPS/IDS), and so the traffic to the C&C servers is permitted through to the Internet.

The defense-in-depth posture of the example site however, forbids communication from any ISA protected network with any machine on the open Internet, outside of a list of specifically authorized machines. The C&C servers are not approved destinations, and direct communication between the infected hosts on the trusted internal control networks and the C&C servers is effectively blocked. Stuxnet works around this defense with a peer-to-peer (P2P) networking capability built into the worm, illustrated in Figure 6.

The P2P network uses Windows remote procedure calls (RPC) as its transport – the same protocol used by Windows file sharing, windows print spooling, OPC, and a number of Siemens proprietary data exchange protocols. RPC communications must be enabled within local area networks for the PCS 7 system to function. Thus, all of the infected equipment on the Process Control and Control System Networks are interconnected by the P2P capability.

In this scenario, we will assume that one of the machines on the Process Control Network is used routinely by a control system administrator on the Enterprise Control Network. The administrator connects to the machine through a VPN connection configured to allow only Remote Desktop (RDC) traffic encrypted within the VPN tunnel. This way, a virus or worm on the administrator’s machine has minimal opportunity to propagate into the protected network. This administrator, however, routinely prints information from the OS Client machine on the Process Control Network while using the machine remotely. The printer is mapped to the administrator’s Enterprise Control Network-connected workstation, and so an RPC connection has been allowed through the ISA firewalls from the OS Client to the administrator’s workstation.

Unfortunately, this open RPC connection allows all RPC traffic, including the P2P RPC network that Stuxnet uses. The administrator’s workstation, being on the Enterprise Control Network, has no restrictions on connectivity with new sites on the Internet. Since at the proposed time of this scenario (i.e. May 2010), no security researcher has yet discovered Stuxnet or the C&C servers; those server addresses are not included in any list of banned sites on the corporate firewall.

Stuxnet takes over the administrator’s workstation using the zero-day print spooler vulnerability, and uses the RPC connection with that workstation to extend the P2P network to the Enterprise Control Network. The P2P network now includes hosts that have contact with the C&C server, and the entire network of compromised machines is put in contact with the Stuxnet authors’ command and control servers.

It is important to point out that this path is successful because of the primary difference in philosophy between the “deny by default” policy employed in the configuration of firewalls that interface to trusted control system networks and the “allow outbound by default” policy commonly used in firewalls that connect corporate networks to the Internet.

Some of the capabilities of the C&C servers have been determined through an examination of the Stuxnet worm software, but nothing further has been published about any investigations into those servers. We know the Stuxnet worm’s C&C communications and RPC communications software are capable of receiving new versions of the worm and distributing those versions throughout the P2P network. We also know the worm is capable of receiving new executables of any type, including PLC program function blocks, over those communications channels and is capable of executing them locally.

No information is yet available as to what executables, besides new versions of the worm, may have been transmitted to infected sites. This ability to receive and run executables may have assisted in the development of new versions of the worm, and could be used to help propagate the worm through specific target networks. That said, but nothing definitive has been published about how the ability to run arbitrary files was in fact used.

Alternative pathways: Alternative paths of communications with command and control servers include:

• WinCC components on the Perimeter Network make heavy use of Windows RPC communications to interact with components on the Process Control Network. All such communications paths through the ISA firewall, including OPC Classic connections, permit RPC P2P communications as well.
  
  
• While not described in the Siemens security recommendations, at many sites administrators on the Enterprise Control Network use file shares to exchange information with servers on Perimeter Network. Paths through the ISA firewall that permit such communications also permit Stuxnet P2P traffic.
  
  
• While not described in the Siemens security recommendations, at many sites the VPN connections from Enterprise Control Network workstations to the Perimeter Network do not aggressively restrict communications to specific ports and hosts; most workstations with VPN connections to the Perimeter Network can communicate with any port on any host on the Perimeter Network. In such cases, any compromised host on the Enterprise Control Network with a VPN connection to the Perimeter Network exposes its P2P communications capability to all compromised hosts on the Perimeter Network.
  
  
• Even if communications with command and control servers are successfully blocked, any route the original infection either used or could have used can serve as a route through which updates to the worm are propagated. When new versions of the worm are installed on compromised machines, they re-propagate just as the original worm did. This kind of communication path, however, can only be used to update copies of the worm, not to interactively and remotely execute arbitrary files on compromised hosts.