Industrial Safety introduction of Modbus (reprint)

The field of industrial safety is relatively closed, with little information being disclosed. I'm reading "Hacking exposed Industrial Control Systems", a 16-year-old book, selected part of the chapter for translation.

MODBUS

Modbus is a serial-based control protocol that was created in the late the 1970s by Modicon (now Schneider Electric) to be used in conjunction with its programmable logic controller (PLC). Modbus is the most common industrial control protocol, mainly because Modbus is an open, simple and powerful protocol that can be used without any royalties. Since the introduction of Modbus, the protocol has been ported to work on Ethernet. To achieve this, the serial-based protocol is encapsulated (essentially "encapsulated") in the head of the TCP data, and is transmitted over the Ethernet network via the default TCP port 502. Due to its ease of use, Modbus can be found in a variety of factories and even substations.

Modbus packet frame can be divided into two parts: Application Data Unit (ADU) and Protocol Data Unit (PDU). ADU consists of address, PDU, and error checking methods. The PDU consists of a function code and a data segment of the Modbus frame. Figure 51 is an example of the Modbus serial protocol, also known as Modbus RTU. (Translator: Note that the ADU contains a PDU, both of which contain relationships)

Figure Wuyi RTU

The Modbus RTU protocol differs from all other implementations of Modbus, including the Modbus on the Modbus+,modbus Ascii,modbus TCP/IP,TCP/IP and other less common implementations of Modbus. Our focus will be Modbus TCP/IP. One of the main differences between Modbus TCP/IP and Modbus over TCP/IP is that MODBUSTCP/IP does not have a checksum within the payload of the packet, as in Modbus RTU.

Modbus TCP/IP consists of ADU and PDU, very similar to Modbus RTU. However, in Modbus TCP/IP,

Figure Mbap and PDU

The ADU consists of the Modbus application Head (MBAP) and the PDU. The MBAP header consists of the transaction ID, the protocol ID, the length, and the unit ID. PDUs have the same structure as PDUs in Modbus RTU, with function codes and data payloads. The function code (FC) in a packet is a project that helps determine the nature of the packet. For example, the function code shown here is 0x2b (43), which identifies FC for the read device. This FC requests specific information from the device, such as the manufacturer of the PLC and the PLC model.

For different FC, the data portion of the packet represents different information. For the read device identity FC, this data tells the device which part of the identity is requested. With Nmap, you can use the Modbus-discover nmap script (https://nmap.org/nsedoc/scripts/modbus-discover.html) for blasting collection. Modbus-discover Nmap script will also attempt to collect slave ID information. The slave ID information is read through FC (0x11). The Modbus standard contains the feature codes that most devices will support. These function codes are defined in the Modbus standard, as shown in 53.

Figure The Modbus function code

As an older protocol, Modbus lacks most modern security features and cannot even protect against trivial attacks such as unauthenticated command-sending and packet replay. With each feature code, the data portion of the packet changes, so it contains the appropriate information being requested. As an example, in the read request of the Modbus coil in function code 1, the data portion of the packet contains the reference number, which is the point to start reading and the number of coils to read. Figure 54 is a sample packet in Wireshark:

Figure the Modbus Request Response Example

There are a variety of techniques for reading and writing Modebus coils and registers. You can use a programming language like Python to process the packets manually, because the packets are very simple, and there are libraries like Pymodbus to help you build, receive, and parse the packets. Another tool that makes packet operations simple is scapy (http://www.secdev.org/projects/scapy/). Of course, in most cases, the simplest and fastest way is to use a client tool that already implements the Modbus protocol. Here is a recommended tool for penetration testers, MODBUS-CLI (HTTPS://GITHUB.COM/TALLAKT/MODBUS-CLI). It allows you to read and write the coils and registers using simple commands, as shown in 55:

A difficult point in the penetration testing of modbus devices is the need to find out what each coil and register corresponds to. Unlike many protocols, the Modbus protocol does not record the meaning of read-write values. Depending on your goals, you can perform more tests to gather more information about your device's execution logic. With emulator systems such as Cybatiworks (Https://cybati.org/cybatiworks), you can try to perform tests and gather information on non-production systems. By using a human-machine interface (HMI), the effect of the change of coil and register becomes more pronounced. Below we use Cybatiworks to simulate a traffic light control Panel example, its HMI is very simple, you can see the system in automatic mode.

Figure 55 Viewing Registers

Figure 56 Register of storage mode information

Figure Cybatiworks Simulator

By modifying the settings and traversing the values of the query register, you can locate which registers are associated with the system's mode settings (this process is more like the behavior of CE during game cracking). This process will take some time and will cause errors when you query for invalid addresses in the system. As shown in 57, with the above steps, we find that the value of setting register%MW4 is 1, so that the system is in automatic mode so that the LEDs change at a given frequency.

You may want to change the mode of the system so that the device does not periodically change the traffic lights. To achieve this effect, you may want to modify the register%MW4 value to zero. In this case, however, the device is not able to turn off automatic mode by writing data once. Through testing, we believe that this phenomenon may be caused by the internal logic of the device. To turn off automatic mode, a specific light needs to be turned on first. We use the Write command to invert the values of all registers, except%MW3. %MW3 is retained because the%MW3 maps to a flashing button on the HMI, regardless of the state of the other registers, all LEDs will blink as long as the%MW3 is placed. After completing the above steps, setting the%MW4 to zero will disable the settings in the HMI. 58 shows the modified status of the value after the Write command is issued

Figure 58 Register value after the command is written

Man-in-the-middle attack of Modbus protocol

• Popularity: 10

• Difficulty: 8

• Impact Surface: 8

• Threat Rating: 9

Due to the lack of secure input in the design, the Modbus protocol is susceptible to the MIDDLE,MITM attack, including packet replay attacks. The aforementioned attack on the Cybati traffic light system can be used for man-in-the-middle attacks. In an attack, an attacker could also delay a vendor from discovering a problem by deceiving the HMI to make the traffic light system appear to be no exception. A variety of open source or commercially available tools can be used to perform a man-in-the-middle attack on the Modbus network. Modbus VCR (https://github.com/reidmefirst/modbus-vcr/) is an open source free tool that uses ETTERCAP to record Modbus traffic and then replay that traffic to make the system look like it is handling normal traffic.

Schneider plc High-risk command word

• Popularity: 10

• Difficulty: 8

• Impact Surface: 8

• Threat Rating: 9

The implementation of Modbus protocol often contains non-standard function code implemented by some vendors. A typical example is the 0X5A (90) function code in the Schneider plc. Like most proprietary protocols, you must use engineering software to analyze how the protocol works. Industrial Safety research and consultancy Digital Bond was first in a Metasploit module in a well-known project Projectbasecamp (https://www.rapid7.com/db/modules/auxiliary/admin /scada/modicon_command), the problem of function code 0x5a is pointed out. This function code implements the functionality that the Modbus standard does not allow, such as terminating the CPU's work. This high-risk function code is discovered by recording the communication flow between the engineering software (Unity Pro) and the Modicon PLC.

Figure The Unity Pro menu item

With packet replay, you can see that this command word terminates all of the Modicon PLC's operating logic. For systems that require real-time control, such attacks can lead to catastrophic consequences.

Recording communication between the engineering software and the PLC can provide some information available from the protocol. In the case of function code 90, the PLC leaks the surprising information, 510, including the last loader to the machine hostname of the device. When checking the capture of traffic from the PLC and engineering software, Modbus is often an encoded string that is easily parsed from the device's response.

In the example, the project name is "project" and the hexadecimal value is "\x50\x72\x6f\x6a\x65\x63\x74". To further check the packet, the hexadecimal "\x08\x00\x00" is the small end sequence that appears to be the item revision number, which is interpreted by the program and is displayed as 0.0.8. "\x0c\x3b\x0c\x0e\x01\xde\x07" is the date the project file was last modified. The date and time stamps shown below are in hours, minutes, seconds, days, months, and years, and are also small-endian.

Figure 511 Time stamp

Schneider plc Identification

• Popularity: 10

• Difficulty: 8

• Impact Surface: 3

• Threat Rating: 7

Still using the same technology, Digital Bond projects Project Redpoint (https://github.com/digitalbond/Redpoint/blob/master/ Modicon-info.nse) can collect more information from the PLC, including the location of the PLC deployed inside the industrial facility. The use of Modbus nmap scripts to gather information helps build device portraits that communicate with Modbus via function code 43 and function code 90. We can use the protocol built-in commands (function code 43 and function code 90) to securely obtain information from the device.

Industrial Safety introduction of Modbus (reprint)