WannaCry on industrial networks: error correction

• Wormholes in the network
  1. Use of computers acting as bridges between several networks
  2. Connecting remote facilities
  3. Using modems and mobile phones
• What needs to be done

During the period from 12 to 15 May 2017, numerous companies across the globe were attacked by a network cryptoworm called WannaCry. The worm’s victims include various manufacturing companies, oil refineries, city infrastructure objects and electrical distribution network facilities.

According to our data, at least several dozen computers that are part of industrial control systems were infected by the WannaCry cryptoworm as a consequence of not being properly protected (e.g., by installing and properly configuring the Kaspersky Lab product designed to protect industrial network endpoints).

Breakdown of industrial companies attacked by industry

The malware encrypted files stored on infected computers. We don’t know whether this resulted in downtime or disruption of industrial control systems at the enterprises affected or in the disruption of their production cycles. According to our experts, this is not an improbable scenario.

Note that some of the computers attacked could not be infected because the shellcode proved to be incompatible with some Windows versions used in industrial control systems. In the event of such an incompatibility, a WannaCry attack can lead to a critical error in the operating system’s kernel and, as a result, denial of service (DoS). Although in such cases the attackers do not achieve their objective and their extortion scheme fails, this situation is still extremely unpleasant for industrial enterprises, because it results in a loss of control over industrial processes. In some cases, a denial of service can lead to the loss of industrial process continuity.

Most experts specializing in industrial automation are of the opinion that infecting industrial systems from the Internet is impossible: it is true that, as a rule, industrial systems inside the perimeter of an industrial network (HMI, SCADA, Historian, operator and engineer workstations) do not have direct Internet connections.

So how can the network worm have penetrated an industrial network?

Wormholes in the network

The WаnnаCry malware spread across local networks and the Internet by exploiting the CVE-2017-0143 (MS17-010) vulnerability in components of the SMBv1 service (port TCP 445) in Windows operating systems.

Obviously, the threat of infection by a cryptoworm of this type is relevant to systems that meet the following conditions:

• the system includes vulnerable components and the Microsoft patch is not installed;
• SMBv1 support is enabled;
• the vulnerable system’s network port TCP 445 is available for connection;
• protection is either not installed or not configured properly.

As mentioned above, as a rule either the industrial network is not directly connected to the Internet or access is provided via the corporate network using NAT, a firewall and a corporate proxy server, which should make it impossible to infect such systems via the Internet.

However, there are typical industrial network configuration errors, which have led to WannaCry infections, according to our data.

1. Use of computers acting as bridges between several networks

Even on what seems to be a well-protected industrial network, we often see computers (servers and even workstations) that are connected to several subnets inside the organization’s perimeter at the same time. Such connections are dangerous, because they create points of entry from one network to another that are hard to control and are usually extremely vulnerable to attack.

The diagram below shows a scenario in which WannaCry malware penetrates from the corporate network to the industrial network via the workstation of the industrial automation system’s engineer/administrator, which is connected both to the corporate network and the industrial (Operation Technologies) network using two network adaptors.

In one of the incidents that took place after the WannaCry cryptoworm began actively spreading, an office computer connected to the corporate network (10.15.1.100) was infected. At the same time as encrypting files on the infected computer, the worm began to spread across the local network, infecting the computer of an industrial automation system engineer/administrator (10.15.1.123) shortly afterwards. Since that computer was also directly connected to the industrial network, the worm was able to spread across the industrial network, attacking industrial automation systems.

Ideally, no computers on the corporate network should be directly connected to the industrial network, because this increases the industrial network’s attack surface. One possible option for setting up more secure access and data exchange between the networks is shown on the diagram below and involves using a demilitarized zone (DMZ) inside the industrial network’s perimeter. All the servers that need to be accessed from outside the network’s perimeter should be hosted in that DMZ and all connections from DMZ to the industrial network should be blocked.

To provide remote access to computers on the industrial network, a terminal server is commonly used in the DMZ, which is allowed access to a specific network port of a specific computer on the industrial network. This arrangement is not sufficiently secure either, because in theory the ability to connect to the industrial network from a DMZ can be used to carry out an attack.

Reverse connection methods should be used to set up more secure access between the DMZ and the industrial network, i.e., a computer on the industrial network should initiate connection to servers in the DMZ, not vice versa.

2. Connecting remote facilities

Segments of an industrial network are often connected to each other via the Internet due to large distances between them or issues related to hardware locations. In such cases, the chances of a successful attack depend on the way in which the connection is set up.

Remote industrial systems are usually connected to the Internet in the same way as corporate networks – using NAT and a firewall, which should also make it impossible for these systems to be infected with the WannaCry cryptoworm directly through the Internet. However, in our experience, the perimeter of such systems is often less well protected than that of corporate networks due to the lack of continual control of the networks’ IT security status and configuration errors. This increases the risk that the perimeter of remote industrial systems can be penetrated. In fact, we often see significant network architecture errors at industrial facilities (such as the error in setting up demilitarized zones discussed above) that open windows of opportunity for connecting to the industrial network’s internal resources from the Internet.

The diagram below presents the scenario of WannaCry malware penetrating the industrial network from a remote network (dispatch center or contractor) via a VPN channel.

As in the previous scenario, a computer on a remote network (172.16.1.100) was infected, after which the worm began to spread across the local network. The infected computer was also connected to the remote industrial network via VPN; computers on the industrial network (192.168.1.0/24) were available for connection and, as a result, were attacked by the network cryptoworm.

It should be kept in mind that VPN protects data against unauthorized reading and modification (MITM attacks) in the data transfer channel, but not from attacks in which one of the channel’s ends (in this case, a computer outside the industrial network) is compromised.

The diagram below shows one possible way of setting up secure access to the industrial network from the outside using a DMZ that has a VPN concentrator in it. Reverse connection methods should be used for remote access from the DMZ to computers on the industrial network.

3. Using modems and mobile phones

We often see cases in which devices are used to set up direct mobile Internet connections for computers on the industrial network, bypassing the network perimeter. USB modems are most commonly used for these connections. Moreover, any modern smartphone can be used as a network adapter for 3G/LTE networks.

In most cases, devices connected to the Internet via mobile networks are unavailable from the Internet, because mobile network operators also use NAT. As a result, the client’s IP address is not public and network ports on the computer connected in this way are unavailable from the Internet. However, in some cases (depending on the connection settings), a mobile network operator’s customer can get a public IP address. In this case, network services that are configured to work with all of the computer’s network interfaces become available at the public IP address provided by the operator, making it possible (for hackers and malware, including WannaCry) to attack the connected computer directly from the Internet.

The diagram below provides an example of an attack against computers on the industrial network by WannaCry malware using an Internet connection that bypasses the network perimeter.

In one infection case during the mass distribution of the WannaCry cryptoworm, one of the computers on the industrial network (192.168.1.11) was connected to the Internet via a mobile connection established using a 3G USB adapter. Because the IP address provided by the mobile network operator was public and the computer’s network services (including SMBv1) were available for all network interfaces, the computer was attacked and infected by WannaCry malware from the Internet. Using the infected computer’s local connection, the worm began to spread across the industrial network, attacking and infecting all available systems on the local network.

In our experience, uncontrolled connection of devices on the industrial network to external networks, bypassing the protected network perimeter, is a serious security threat to industrial automation systems. Even in cases where the IP address provided by the mobile network operator is not public and the computer’s network services are not available for connection from the Internet, a connected computer can be attacked and infected with malware (using phishing, social engineering, vulnerabilities in browsers and other application software).

To ensure the security of the industrial network and industrial automation systems connected to it, control of mobile Internet connections should be implemented (e.g., by using device control technologies to restrict the use of USB network adapters). In addition, mobile devices connected to the industrial network and used outside the network perimeter should be separated from other systems as in the previous scenarios by setting up a demilitarized zone.

What needs to be done

According to our observations, in most cases WannaCry malware attacked industrial automation systems through enterprises’ local networks, taking advantage of direct connections between networks or VPN connections.

The immediate protection measures are obvious. They include: where possible, disabling SMBv1 services and closing port TCP 445 on all computers connected to the network and on the network perimeter; installing a patch where using network folders cannot be given up completely.

To prevent such accidental infections in the future and to provide protection from targeted attacks against industrial networks, we recommend taking a set of measures designed to ensure the security of the industrial network’s internal and external perimeters.

First of all, to provide secure remote management of automation systems and transfer of data between the industrial network and other networks, access should be restricted to the greatest extent possible between systems which are parts of different networks or which have different trust levels:

• Systems that constantly or regularly communicate to external networks (mobile devices, VPN concentrators, terminal servers, etc.) should be isolated into a separate segment of the industrial network – the demilitarized zone (DMZ);
• Systems in the demilitarized zone should be divided into subnets or virtual subnets (VLAN), with restricted access between subnets (only communications that are necessary should be allowed);
• All required information exchange between the industrial network and the outside world should be carried out via the DMZ;
• If necessary, terminal servers can be deployed in the DMZ to enable reverse connection methods (from the industrial network to the DMZ).
• Thin clients should be used whenever possible to access the industrial network (using reverse connection methods);
• Where possible, access from the demilitarized zone to the industrial network should be blocked;
• If the enterprise’s business processes are compatible with one-way communication, we recommend that you consider using data diodes.

It should be kept in mind that the threat landscape for industrial automation systems is continually changing, with new vulnerabilities found both in application software and in industrial software.

To provide protection against other unknown threats, including targeted threats, we recommend:

1. Taking an inventory of running network services; where possible, stopping vulnerable network services (unless this will jeopardize the continuity of industrial processes) and other services that are not directly required for the operation of the automation system; special emphasis should be made on services that provide remote access to file system objects, such as SMB/CIFS and/or NFS (which is relevant in the case of attacks that exploit vulnerabilities in Linux).
2. Auditing ICS component access isolation; trying to achieve maximum access granularity.
3. Auditing the network activity in the enterprise’s industrial network and at its boundaries. Eliminate any network connections with external and other adjacent information networks that are not required by industrial processes.
4. Verifying the security of remote access to the industrial network; placing a special emphasis on whether demilitarized zones are set up in compliance with IT security requirements. To the extent possible, minimizing or completely eliminating the use of remote administration tools (such as RDP or TeamViewer).
5. Ensuring that signature databases, heuristics and decision algorithms of endpoint security solutions are up-to-date. Checking that all the main protection components are enabled and running and that ICS software folders are not excluded from the scope of protection. Application startup control technologies configured in whitelisting mode and application behavior analysis technologies are particularly effective for industrial enterprises. Application startup control will prevent cryptomalware from running even if it finds its way on to the computer. Application behavior analysis technologies are helpful for detecting and blocking attempts to exploit vulnerabilities (including unknown) in legitimate software.
6. Auditing policies and practices related to using removable media and portable devices. Blocking devices that provide illegitimate access to external networks and the Internet from being connected to hosts on the industrial network. Wherever possible, disabling the relevant ports or controlling access to these ports using properly configured specialized tools.
7. Deploying tools that provide network traffic monitoring and detection of cyberattacks on industrial networks. In most cases, such measures do not require any changes to ICS components or their configuration and can be carried out without stopping their operation.

Of course, completely isolating the industrial network from adjacent networks is impossible, since transferring data between networks is required to perform a variety of important functions – controlling and maintaining remote facilities, coordinating sophisticated industrial processes, parts of which are distributed between numerous workshops, lines, plants and supporting systems. We hope, however, that our recommendations will help you to provide maximum protection for your industrial networks and automation systems against existing and future threats.