The Relevance of WPA2 Vulnerabilities and KRACK Attacks to Industrial Systems

Critical vulnerabilities that have recently been identified in the WPA2 protocol enable threat actors to carry out Man-in-the-Middle (MitM) attacks and force devices connected to the network to reinstall encryption keys that protect traffic. These vulnerabilities can be used, among other things, to implement attacks on industrial automation systems.

Core of the Problem

Many industrial protocols lack mechanisms for checking the integrity and authenticity of data being transferred. This makes them vulnerable to message spoofing and/or MitM attacks.

In addition, when tools used in industrial software to maintain a connection and verify the authenticity of requests sent via that connection are implemented using non-specific transport and application layer protocols, these implementations often contain errors. The ability to predict TCP sequence numbers or one-time values used to identify web requests (nonces) can also be used in MitM attacks.

Protection against this type of attacks is usually based on restricting physical access to control-level devices and communications equipment. If an attack does not require physical access (as in the case of KRACK, according to researchers), this significantly increases the risk of equipment and industrial processes being tampered with.

Wireless Network Organization. Two Scenarios

To determine to what extent the group of WPA2 vulnerabilities exploited in KRACK attacks affects industrial environments – primarily at the industrial network’s control level – we consider two wireless network organization scenarios.

In the best-case scenario, the technologies used offer a certain basic level of security, with recommendations provided by industrial hardware and software vendors being carried out when building, maintaining and upgrading industrial hardware and software. In this case, risks associated with the WPA2 vulnerabilities discovered can be assessed by analyzing large industrial vendors’ recommendations on using wireless technologies to determine to what extent “best practices” are effective with respect to the new vulnerabilities.

The worst-case scenario involves being governed by considerations of minimal complexity of the changes made and the availability of the solutions used when building a wireless network, without regard for “best practices”. This scenario is not typical of critical infrastructure or large industrial enterprises, but rather of smaller manufacturing facilities, small solar and wind farms, warehouse facilities, building automation systems and other systems whose owners typically try to save resources on their operation. This takes the form of saving on equipment and minimizing staff involvement, which means that such solutions are often designed, implemented and operated by the same engineer within the limits of that engineer’s competence. To assess the risks associated with this scenario, we will consider some of the available industrial network control level Wi-Fi converters and their use cases.

Scenario 1. “Best Practices”

Recommendations on using wireless technologies (802.11) in industrial networks are officially published by major industrial communication equipment vendors. We look at the recommendations of two major industrial communications equipment vendors representing “best practices”.

Rockwell Automation + Cisco

The recommendations Deploying 802.11 Wireless LAN Technology within a Converged Plantwide Ethernet Architecture. Design and Implementation Guide were developed by Cisco and Rockwell Automation in 2014 as part of a joint effort to unify the process of designing and developing enterprise-scale networks (Converged Plantwide Ethernet, CPwE). These recommendations describe the use of wireless technologies on an enterprise-scale network.

The document formulates the following principles for using wireless technologies in an integrated industrial environment:

• Supervisory control, peer-to-peer control, distributed input/output control and functional safety applications are implemented in networks with multipoint access, which can be built using the 802.11a/g/n technology.
• Operator control applications can be implemented using mobile terminals with integrated wireless 802.11a/g/n adapters.
• Remote supervisory control applications for distributed systems are implemented in networks with point-to-point or multipoint access or in mesh networks based on11a/g, Cellular 3G/LTE, WiMAX or proprietary wireless broadband technologies.
• Process intrumentation, sensors and condition based monitoring hardware should preferably be connected into mesh networks using ISA-100.1 1a, WirelessHART, ZigBee, or Bluetooth.

It can be concluded from the above that using technologies vulnerable to the KRACK attack at the control level is not recommended. However, it’s not that simple.

Next, the recommendations nevertheless cover the types of clients that can be connected to wireless networks based on the 802.11 standard using different methods:

1. Via an integrated wireless adaptor. This method is applicable to any computers, tablets or smartphones. For most control-level industrial devices, integrating an adapter with an antenna is not accepted practice for several reasons (poor RF characteristics, power consumption requirements, density of wireless nodes, etc.). Nevertheless, it is noted that this option is not impossible, but the recommendations do not consider it as common practice.
2. Via a universal bridge. An external wireless adaptor for each individual controller or I/O device at the control level compensates for the absence of an integrated adapter. This is not regarded as recommended practice, either, although the authors admit that this method can be used.
3. Via a workgroup bridge (WGB) that connects several wired clients to the wireless network. This is the main method discussed in the recommendations.

In other words, although connecting individual control-level devices directly to the wireless network is not good practice, the recommendations account for this possibility. However, it is not discussed in detail, based on the premise that this approach is too expensive – which is certainly not true (see the worst-case scenario).

An example of a topology using the types of wireless clients discussed above is shown in the figure below.

Source: Cisco and Rockwell Automation

Of the three connection methods described above, the first two are based on connecting each device to the wireless network separately, independently of other devices. This means that any risks affect only individual connected devices. In this case, susceptibility to KRACK attacks depends on whether integrated adaptor or external universal bridge firmware updates are installed in a timely manner. If updates are released by the vendors and installed on the hardware in a timely manner, the threat of a KRACK attack will be neutralized. However, security updates for these types of devices are likely to be delayed or not be released at all.

The third connection method, in which all control-level devices are connected to the wireless network via a workgroup bridge (WGВ), is the one recommended. However, even in this case the connection is vulnerable to KRACK attacks; importantly, all devices connected to the access point are at risk. The decisive positive factors are higher probability of communication equipment vulnerabilities being closed quickly and a less complicated update procedure in the case of communication equipment compared to control-level devices. Naturally, all of this applies if the relevant patches are installed in a timely manner.

Siemens

For comparison, we look at the Basics of Setting up an Industrial Wireless LAN released by the industrial giant Siemens in 2016.

The document provides a detailed description of the 802.11 technology, including some proprietary Siemens expansions, possible threats and security functions included in the standards. The recommendations distinguish the following types of SIMATIC wireless products: controllers, access points, IWLAN clients, and mobile operator panels. Overall, the recommended topology is similar to that described in Cisco and Rockwell Automation recommendations. Judging by messages on the official support forum, the recommendation do not cover all end-user requests. However, they can be considered to meet security requirements provided that the vulnerabilities in the protocol will be quickly closed, with the relevant patches applied to affected industrial equipment.

From the viewpoint of risks associated with KRACK attacks, the difference between Siemens products and Rockwell Automation products is that the former have proprietary protocol expansions. One of these, PROFIsafe, is used to maintain functional safety on the industrial network. Since this is a proprietary protocol expansion, it is impossible to tell for sure whether protection from message spoofing is properly implemented in it. This means that only the developer of the protocols, i.e., the equipment vendor, can assess the risks associated with KRACK attacks. An official advisory on KRACK attack vulnerabilities in Siemens industrial products is currently available on the Siemens website.

Finally, as regards using wireless technologies other than 802.11, it should be noted that none of them is proven to be secure against attacks such as KRACK. This is why it is essential for vendors to close vulnerabilities in software based on non-specific transport and application layer protocols and phase in industrial protocols that ensure payload integrity and authenticity.

Scenario 2. Cheaper and Easier

Even though official vendor recommendations are available, 802.11 technologies were certainly not designed with critical infrastructure in mind. Even the most simple-minded and naïve ICS designers are not particularly keen on Wi-Fi. You can hardly find it on large industrial networks.

However, “best practices” are not always followed when it comes to automating smaller industrial facilities. For such facilities, the cost of maintaining the process approach, which takes into account all aspects of making changes, can be high relative to their production cost. A quick search across forums and sites devoted to discussing solutions for maintaining and upgrading automation systems produces the impression that no solution is considered completely unacceptable if it makes the engineer’s life easier when it comes to routine tasks related to maintaining the equipment and industrial processes.

This also applies to directly connecting individual control-level devices to the wireless network. While only a few years ago this was problematic from the technical viewpoint, today’s Internet of Things solution boom means that this has become much cheaper and easier. As a result, disregarding equipment vendor recommendations is becoming almost normal for small-budget industrial facilities.

We tried getting into the shoes of an engineer at one of such facilities and searched for solutions for equipment that uses industrial protocols, specifically Wi-FI adaptors and converters that convert industrial protocols to wireless network protocols and back. Contrary to the belief that such solutions are prohibitively expensive, there are plenty of suitable inexpensive devices on the market, including those supporting proprietary technologies.

For example, a Chinese-made Ethernet/MPI DP S7-300 adaptor with Wi-Fi support costs about $200 on Ebay. For only $95 you can buy a 802.11b/g/n to RS-485 converter with Modbus TCP/RTU support, which, when working in web client mode, adds the HTTP header to data received from the serial port. The same seller offers RS-232 to Wi-Fi converters at an even lower price – starting from $67.

Converters made by Moxa are more expensive: for example, one-port and two-port Moxa Modbus/DNP3 converters from the serial interface to Ethernet with Wi-Fi IEEE 802.11a/b/g/n support cost around $550 and $750, respectively. Devices produced by HMS Industrial Networks under the telling name Anybus Wireless Bolt/Anybus Wireless Bridge promise to provide a reliable wireless connection between any two points on an industrial Ethernet network (PROFINET, EtherNet/IP, Modbus TCP, BACnet/IP). These are just the kind of adaptors for individual devices that are not recommended by the major vendors and that are nevertheless used due to the need to implement solutions that can be quickly and easily reconfigured at the communication level. Their suggested use cases include wirelessly configuring machines and mechanisms (primarily via Serial RS232/485 or CAN), reducing the number of expensive HMI by using mobile applications and BYOD policies, accessing data remotely at any time, and reducing the operator hazard level when working with AGV (Automated Guided Vehicles).

Since the “best practices” do not cover the above use cases, customers have to look for solutions on their own and the solutions they find are not always designed with security in mind. Ultimately, this can lead to serious consequences: data compromised by cloud leaks instead of convenient authorized remote access, unauthorized activity on behalf of the HMI operator, or AGV getting out of control.

It should be noted, however, that not taking all the different needs into consideration and not properly allocating responsibility for maintaining secure execution of decisions is a common problem for the Internet of Things, part of which is represented by Anybus Wireless Solutions communication devices.

Speaking of the Internet of Things and coupling network technologies with input/output technologies at a low level, it is essential to mention microcontroller solutions such as WINC1500 by Atmel or EMW3162 by NXCHIP. These chips implement WiFi and network interaction via an SPI, UART or I2C interface. Power saving mode support makes them attractive for implementing custom control-level devices, such as controllers or complex sensors. Additional services supported by the firmware, such as DHCP, DNS, TCP/IP (IPv4), UDP, HTTP, and HTTPS, make the module an even more attractive choice for DIY solutions but are unlikely to have a beneficial effect on security. So far, such devices have not been widely used in automation solutions, but this may only be a matter of time.

Going back to the issue of using 802.11 technologies in industrial environments, there are currently many options for connecting devices directly to the wireless network. It should be kept in mind, however, that in these cases solution vendors bear full responsibility for maintaining and updating ready-made solutions, but many solution vendors are not sufficiently responsible when it comes to security issues.

Conclusions. Who Is at Risk

As we mentioned above, in most cases KRACK attacks present virtually no risk to those large industrial and critical infrastructure systems that do not use 802.11 technologies. Today, such systems constitute an absolute majority. Even in cases where these technologies may be used, physical restrictions on access to the controlled zone (e.g., a specific manufacturing unit) would not prevent an attack from being carried out.

The main risk zone still encompasses those industrial sectors the security of which is given a lower priority than that of critical infrastructure systems and where using wireless technologies to upgrade systems or meet industrial network maintenance needs has become necessary but where compliance with the “best practices” supported by major vendors is not possible because the changes required are too complicated or too costly.

On the other hand, the market offers many solutions for quickly and cheaply integrating industrial devices with the telecommunications environment, which may be maintained in part using consumer devices. These solutions find their customers. As a rule, industrial systems where information technologies are implemented spontaneously have a “zoo” of solutions and technologies, which has a negative effect on the security of the entire configuration.

The imbalance between the need for wireless technologies and the ability to implement such technologies in a relatively secure manner is usually due to a range of factors, including:

• small scale production;
• the need to minimize system maintenance costs (partly by using remote services);
• inability to install new physical communication channels;
• limitations of the industrial equipment used.

Risks of KRACK attacks do not affect systems where custom wireless protocols, such as Smart Metering, have been designed and implemented at the field equipment level.

It should be noted, however, that alternative wireless protocols are in most cases not immune to vulnerabilities similar to those found in Wi-Fi protocols. It is essential to ensure that exploiting these vulnerabilities cannot result in significant degradation of the overall stability of the system.

Mobile SCADA and HMI applications based on vulnerable operating systems remain the main source of risk associated with KRACK attacks for industrial environments at levels above that of industrial process control. Most such applications are designed for Android OS. Man-in-the-Middle attacks can be carried out in network segments through which data is exchanged with a vulnerable operating system.