Cyber Threats
A Blind Spot in ICS Security: Protocol Gateway Part 2
Part two presents an overview of the verification methods and results of this research, and describes "flaws in the protocol conversion function," one of the security risks revealed through our experiments.
Save to Folio
A protocol gateway is a small network device, also called a protocol converter" or "IoT gateway." It is similar to an "interpreter" in the digital word, and acts as a communications intermediary between different protocols. As the integration of networks accelerates with IoT, protocol conversion grows increasingly important. However, the security of protocol gateways has not been fully verified so far. Focusing on potential protocol gateway security risks, Trend Micro released a white paper summarizing these risks on August 6, 2020. In this blog series, based on the results of this research, we will analyze the impacts of the serious vulnerabilities detected in the protocol gateways essential when shifting to smart factories, and we will propose the security countermeasures that security administrators in those factories must take. In the second of this series, Part 2 presents an overview of the verification methods and results of this research, and describes "flaws in the protocol conversion function," one of the security risks revealed through our experiments.
Verification method: Black box testing
The research team in Trend Micro has adopted black box testing, which compares inputs and outputs to/from protocol gateways, in order to verify the conversion processing capacity of protocol gateways. This verification method is effective for the case like this time where design information of products that were verified is not published. This verification used Fuzzer (a tool for auto-generating test packets) to generate inbound traffic to the protocol gateways to be verified and compared the results from conversion by the protocol gateways. Figure 1 shows the framework of this verification.
<Fig. 1> Schematic of Verification Framework
Result: Nine Types of Vulnerability
There are a total of nine types of vulnerability found in three of the five products verified in this research through analysis of protocol conversion processes using the black box testing described above (see Table 1). All these types of vulnerabilities have been reported to each manufacturer by the Zero Day Initiative, the vulnerability specialized organization of Trend Micro. As of August 18, 2020, security patches have been released by each manufacturer for types 5 to 7, and those of 8 and 9 are in the status of being coped with by each manufacturer. For those of 1 to 4, responses to the effect that "production of the relevant products has ended, so their patches are no longer released" have been received from each manufacturer. Here is an overview of each type of vulnerability:
<Table 1> List of Vulnerability Found in This Research
- Bypassing protocol conversion [CVSS: xx]
This is a problem where unauthorized Modbus TCP packets may pass through protocol gateways without being filtered out, so that they can flow through fieldbus as legitimate packets for Modbus RTU. Attackers can abuse this type of vulnerability to pour any instruction different from the original one into PLC.
- Unencrypted MQTT [CVSS: xx]
This is a vulnerability where encryption such as TLS and SSL is not supported. Because an option to enable encryption is not provided in products, data is always transmitted in cleartext. As a result, attackers can use sniffing to access personal information such as user names and passwords.
- Bypassing authentication [CVSS: xx]
This is a vulnerability where a gateway would always send a null user name (0x00000000) even when login user names are set in a Web console. As a result, attackers can intercept all of the traffic converted by the target gateway and violate privacy and confidentiality by configuring unauthorized MQTT brokers and enabling "anonymous login" (or disabling authentication).
- Unsanitized MQTT upstream [CVSS: XX]
This is a vulnerability where a protocol gateway does not verify data which is transferred to a cloud. In conversion from Modbus TCP to MQTT, proper processing is done by testing that messages to be sent upstream conform to modbus specifications, but the gateways with this vulnerability would send all messages upstream. Therefore attackers can send malicious payloads which would trigger vulnerabilities behind the service backend into a cloud service.
- Information theft via proprietary commands [CVSS - 6.9]
This is a vulnerability where encryption keys are included in the setting information sent from protocol gateways via Ethernet. It is possible to decrypt the encrypted setting information by using a proprietary decryption library extracted from the device's firmware which has been obtained online.
- Reusing credential information [CVSS - 6.9]
This is a vulnerability where random seeds for generating random numbers are not set, so encryption could be reproduced. Due to this vulnerability, attackers can reuse credential information of a device to login with an administrator account without knowing plain text passwords.
- Acquisition of root shell [CVSS - 8.8]
This vulnerability allows unprivileged users to execute privileged commands. This is because input values are not checked in the diagnosis function provided by the Web interface of a device. Unprivileged users can start the Telnet daemon as root users via a simple HTTP Get request. This allows unprivileged users to obtain full remote access (root shell) to a device.
- DoS by sending Modbus packets [CVSS - 7.5]
Attackers can trigger rebooting of a protocol gateway remotely by sending specially tampered malicious Modbus TCP packets. This vulnerability is due to inbound packets not being sanitized in a product.
- Memory leak [CVSS - xx]
This is a vulnerability where memory leak occurs under specific situations. Attackers access leaked data via read messages sent to a protocol gateway.
From the result that as many as nine types of vulnerability are found through only this research, it seems that sufficient security measures have not been implemented for protocol gateways.
And among the types of vulnerability mentioned above, especially "1. Bypassing protocol conversion" is a bug specific to the protocol conversion function and a serious vulnerability which allows stealth attacks within ICS environments. Nevertheless, considering a situation where no bug-fixing patch is released by each manufacturer, it might be necessary to give users of the relevant product a heads-up. So the relevant vulnerability is described in detail in the following section.
Flaw of Protocol Conversion Process: Lack of Packet Filtering Function
As an example for Bypassing protocol conversion, we shall consider the case where an instruction for "write to multiple registers" is issued from a control system device within an ICT environment to PLC. Table 2 shows briefly the successful protocol conversion from Modbus TCP to Modbus RTU, when giving the instruction "write to multiple registers". Note that the numeric values in the table are represented in hexadecimal.
The Modbus TCP protocol conducts data conversion in the application layer of a TCP/IP stack. The data of Modbus TCP is delimited in bytes as shown in Table 2. The data has headers containing a transaction ID, protocol ID, and message length from left to right, followed by Modbus payloads including function codes. The instructions in Modbus are defined with "function codes" from 0x01 to 0xFF, and here is an instruction defined as "0x10" = "write to multiple registers". The fields and numeric values after the starting address are set according to the function code.
<Table 2> Example of Message Frame Configuration for Modbus TCP
On the other hand, the Modbus RTU protocol is serial communication in the physical layer. Therefore, TCP header information is not included, and header information is dropped at the time of protocol conversion. However, the Modbus payloads to be used for key data are naturally contained, so the data following the function code is contained in the message frame (Table 3). And the Modbus RTU contains an error check code and a silent interval which shows the Start/End of the data, however, they are omitted here in order to make data transition at the time of protocol conversion easier to understand.
<Table 3> Example of Message Frame Configuration for Modbus RTU
It is the role of protocol gateways to notify PLC of the correct contents of an instruction (= a function code and data transferred along with it) and the correct destination (= unit ID) after understanding these two different protocol formats of message frame. Table 4 shows the data for successful protocol conversion.
<Table 4> Example for Successful Conversion from Modbus TCP to Modbus RTU
Now how would a protocol gateway behave if inbound packets have deficiencies? From the point of view of security, a protocol gateway must have a function to filter out invalid packets. However, as a result of using Fuzzer to send invalid Modbus TCP packets, it was found that there are products which allow unauthorized packets to "pass through". Fig. 2 shows an example of this phenomenon.
<Fig. 2> Example of a Protocol Gateway to Transmit Invalid Modbus TCP Packets as Modbus RTU Packets as They Are
The red portion in Fig. 2 represents a frame showing the message length of the packet, and while it should be 0x000B (11 bytes) originally, it has been changed to 0x0009 (9 bytes) intentionally, resulting in it being an "incorrect" packet which does not conform to protocol specifications as Modbus TCP. However, the relevant protocol gateway "replaces" the packet onto Modbus RTU as it is, resulting in it flowing through to the field network. The Modbus TCP header has also been maintained.
This simple protocol conversion error seems an insignificant phenomenon at first glance. It seems that there is no great risk when simply passing through invalid packets. However, if exploiting this vulnerability to issue unexpected instructions to field devices is possible, that will be a different matter. Trend Micro has identified a new attack method which enables stealth attacks against field network by juggling packets to be flowed into protocol gateways. In the next part, the final part, we will present the details of this stealth attack method as well as propose security measures in ICS environments which are recommended from the results of this research.