A protocol gateway is a small device that provides mission-critical command translation between machine tools, sensors, various actuators, and computers running factories, dams, power plants, and industrial plants. These gateways resemble home routers: they also have multiple interfaces connected to different networks, and are just as vulnerable to various attacks. If such a device fails, communication between control systems and machines is lost. Operators won't see what's going on. In fact, they won't even be able to tell if machines, turbines or generators are operating in a safe manner. Even if something is clearly wrong, a failure of the gateway will not allow the operator to issue a command to start or stop processes.
A similar situation had to be in December 2015 duringattacks on the Ukrainian power grid : attackers gained access to the power grid control center and disabled protocol gateways at substations by uploading damaged firmware to them. This blocked all attempts by utility engineers to restore service, as commands from control systems to close the circuit breakers could not be transmitted.
In an incident report by SANS ICS (a division of the American educational and research organization SANS Institute for the Study of Industrial Control Systems) and the Power Analysis and Information Exchange Center (E-ISAC - a structure that unites participants in the North American electricity market), the gateway firmware was damaged protocols were called "the explosion of bridges." This very accurately describes what happened, since the attackers destroyed the key link - the translators, which just act as a bridge between controllers and substations.
The structure of interaction between the control network and the execution network. Source (hereinafter, unless otherwise noted): Trend Micro
Due to its location, a protocol gateway can become the weakest link in a chain of industrial facility devices, and an attacker can attack such devices for two important reasons:
- Gateways are unlikely to end up on a critical asset inventory that would be monitored by a security agent or registration system. Hence, the attack is less likely to be noticed.
- Translation problems are difficult to diagnose, so flaws in the design of protocol gateways allow advanced attackers to conduct very covert attacks.
Types of gateways
According to the operating mode, two families of gateways can be distinguished:
- Real-time gateway (Real-time gateways) forward traffic as they become available - each incoming packet is immediately evaluated, translated and forwarded; representatives: Nexcom NIO50, Schneider Link 150, Digi One IA;
- Data Stations - work asynchronously using the interface mapping table - do not wait for a read request to receive data from the connected PLC, but regularly request state updates from the PLC and store the received data in the internal cache for issuing on demand.
The second important characteristic of protocol gateways is the type of protocols they support and translate. By this property, devices can be grouped into three categories:
- , , , Modbus TCP Modbus RTU, — , ;
- , , , Modbus RTU → Profibus, — , ;
- , , , Modbus TCP → Profibus, — , .
In the Lost in Translation: When Industrial Protocol Translation Goes Wrong study, we examined the vulnerabilities of the first group of gateways. For this, we have assembled a test bench consisting of the following components:
- fuzzer that generates incoming traffic for the tested gateway - for example, when testing the translation from Modbus TCP to Modbus RTU, fuzzer generates Modbus TCP test cases,
- gateway - studied device,
- simulator - a device that simulates a receiving station, for example, a PLC that implements the Modbus RTU of a slave device - it is necessary because some protocol gateways may not work correctly if there is no slave in the chain,
- a sniffer that collects information about outgoing traffic, i.e., about the broadcast protocol,
- analyzer of incoming and outgoing traffic.
Block diagram of a test bench for studying protocol gateway vulnerabilities
Real test bench
For modeling the main Modbus node, we used the open source software QmodMaster, and for modeling the slave device - pyModSlave, adapting it for our needs, such as receiving data from / dev / ttyUSB0.
We used Wireshark for Modbus TCP and IONinja for Modbus RTU to intercept traffic. We wrote special parsers to convert the output of these two programs into a common syntax that our parser can understand.
We implemented the fuzzer on the basis of BooFuzz, adding some modules of the Boofuzz-modbus project, which is distributed under the Apache license. We made the fuzzer portable to various ICS protocols, and used it to test several Modbus implementations.
Here are some of the types of attacks that we found while examining various protocol gateways:
- attack on the protocol translator,
- reuse of credentials and decryption of configuration,
- traffic amplification,
- escalation of privileges.
Protocol translator attack
Real-time gateways translate packets from one protocol to another, replacing the source protocol headers with the target protocol headers. Gateways from different vendors handle invalid packets differently. Some of them, for example, when receiving a packet with an incorrectly specified length, instead of adjusting the length or discarding it, broadcast it as it is. This feature allows you to carefully design a packet of the wrong length for Modbus TCP so that it remains correct after translation to Modbus RTU. However, if you read it as a Modbus RTU packet, it will have a completely different meaning compared to the Modbus TCP equivalent.
Attack packet: in Modbus TCP it contains a command to read a register, but in Modbus RTU it is already a command to write several bit cells
When parsing this packet with Modbus TCP semantics, it is interpreted as a command to read the input register (Function Code 04) from the block with ID = 3. But in the semantics of Modbus RTU, it is interpreted as writing several bit cells (Function Code 15 and 0F) to a block with ID = 1.
This vulnerability is critical because a completely innocent read request turns into a write command because the protocol gateway does not properly process the packet. An advanced attacker could exploit this vulnerability to bypass a specialized industrial firewall that blocks write commands from non-whitelisted IP addresses.
As a result, just one command is enough to, for example, disable the sensors for monitoring the health and safety of the engine (temperature sensor and tachometer), while leaving the engine on. If the engineers and operators do not notice this, the engine may already go to critical mode and fail, but no one will know about this, since the thermometer and tachometer have been deactivated.
Reusing credentials and decrypting configuration
Moxa gateways use a proprietary protocol when communicating with the MGate Manager remote control program. When MGate Manager starts up, the engineer is prompted for a username and password to access the protocol gateway, after which McGate Manager automatically resets the configuration so that the user can change the settings. When the field engineer completes the protocol gateway configuration and clicks the Exit button, the configuration is compressed, encrypted, and uploaded to the gateway.
Moxa Gateway Configuration Steps
There are two security flaws in this procedure that can be abused.
- Reuse
When an engineer logs in, a key is passed to MGate Manager to hash the password. However, in the tested firmware, the mechanism is implemented in such a way that a hacker can intercept the encrypted password of an engineer to enter the system, and then use it to log in with administrative privileges, even without knowing the password in the form of text.
- Configuration
decryption The encrypted configuration transmitted over the network contains an encryption key that allows a hacker to dump and decrypt it.
The encrypted configuration contains the AES key to decrypt it. Very handy for hacking
For decryption, we used a proprietary decryption library extracted from the device's firmware. The configuration contains configuration files, SQLite databases and a Secure Shell (SSH) key. Below is an example of the decrypted configuration of our own protocol gateway, which we managed to intercept.
Moxa MGate 5105 decrypted configuration files
Amplification of traffic
Because data stations broadcast protocols asynchronously to each other, multiple write-one-bit requests can be combined into a single request to make better use of the serial bus. For example, a hacker can call function 15 (writing several bits), at the data station it will be converted to 1 record for ID = 2, 1 for ID = 4, 1 for ID = 5, 1 for ID = 6. Thus, one Modbus TCP entry translates into four Modbus RTU entries, causing slight congestion on the serial bus.
One TCP command to write a cell turns into four RTU commands.
Note that this amplification will not cause a Denial of Service (DoS), but an overloaded RS-485 bus can still lead to abnormal behavior.
Escalation of privileges
On MGate 5105-MB-EIP, we discovered privilege escalation vulnerability CVE-2020-885 that allows a non-privileged user to execute commands with elevated privileges.
The source of the problem is the lack of filtering of user input in the web interface of the Ping utility.
Mgate Ping Utility Interface
With minimal technical knowledge, an unprivileged user can launch the Telnet daemon in the context of the root user with a simple HTTP GET request and gain full remote access with a root shell.
Our recommendations
After examining the specifics of the operation of various industrial protocol gateways, we have developed a number of recommendations for suppliers, installers or end users.
- - . . .
- — , , . ICS- . Trend Micro — TXOne Networks, OT .
- , — /, . , , , MQTT.
- OT , .