Hacking: Modbus

One of the challenges of pentesting in the OT/ICS environment is given by the protocols used which can also be very different from those of IT. ICS installations use a wide variety of protocols that often have little in common with standard Ethernet and TCP/IP.

This difference has been the strong point of OT installations for years, protecting them through the mechanism of “security by obscurity”. Now that these protocols are becoming more known and understood, security concerns in these facilities have been heightened.

In this article we see the main characteristics of one of these protocols: the Modbus.

The Modbus standard

The Modbus protocol is mainly characterized by the physical connection medium, which can be on a serial port or on Ethernet. There are several variants of the protocol:

• Modbus RTU
• Modbus ASCII
• Modbus-TCP
• Modbus over TCP/IP or Modbus RTU/IP
• Modbus over UDP
• Modbus Plus (Modbus+)
• Secure Modbus

In this article, I will cover the most popular ones: Modbus RTU and Modbus TCP. I will also mention Secure Modbus, a security-oriented version of the protocol that incorporates a data encryption layer.

Modbus RTU

Modbus RTU was first developed in 1979 by Modicon (now part of Schneider Electric) for their PLC and industrial automation systems. It has become the de facto industry standard. Modbus is a widely accepted public domain protocol, it is a simple and lightweight protocol intended for serial communication. It has a data limit of 253 bytes.

Modbus operates at layer 7 of the OSI model. It is an efficient communication methodology between interconnected devices using a “request/response” model. Because it’s simple and lightweight, it requires little processing power. Suffice it to say that there are communication libraries available for practically any embedded device, starting from a simple Arduino board up to the more sophisticated Raspberry.

Modbus was initially implemented on the physical topology RS-232C (point-to-point) or RS-485 (multi-drop). It can have up to 32 devices communicating over a serial link with each device having a unique ID.

Modbus uses a master/slave (client/server) architecture where only one device can send requests. The slaves/servers provide the requested data to the master or perform the action requested by the master itself. A slave is any peripheral device (transducer, valve, network unit, etc.) that processes information and sends its output to the master via the Modbus protocol.

Masters can address individual slaves or broadcast a message to all slaves. Slaves return a response to all queries addressed to them individually, but do not respond to broadcast queries. Slaves do not generate messages, they can only reply to the master. A master’s query will consist of the slave address (slave ID or unit ID), a function code, all required data, and a CRC error checking field.

Modbus communicates using Function Codes, function codes that identify a wide range of commands.

Modbus TCP

Modbus TCP is the encapsulated Modbus protocol for use over TCP/IP using port 502. It uses the same request/response as Modbus RTU, the same function codes, and the same 253-byte data limit. The error checking field used in Modbus RTU is eliminated as the TCP/IP link layer uses its checksum methods.

Modbus TCP adds an application layer (MBAP) to the Modbus RTU frame. It is 7 bytes long with 2 bytes for the header, 2 bytes for the protocol identifier, 2 bytes for the length and 1 byte for the address (unit ID).

The use of Ethernet allows the creation of more complex architectures, even of the hybrid type, making use of special gateways.

Data packet format

A Modbus frame consists of an Application Data Unit (ADU) encapsulating a Protocol Data Unit (PDU), according to this scheme:

• ADU = Address + PDU + Error check
• PDU = Function code + Data

The byte order for values in Modbus data frames is the most significant byte of a multi-byte value sent first. All Modbus variants use one of the following frame formats.

Modbus RTU frame format

Notes on calculating the CRC:

• Polynomial: x16 + x15 + x2 + 1 (CRC-16-ANSI also known as CRC-16-IBM, normal hexadecimal algebraic polynomial being 8005 and reversed A001).
• Initial value: 65,535.
• Example of frame in hexadecimal: 01 04 02 FF FF B8 80 (CRC-16-ANSI computed from 01 to FF generates 80B8, first the byte is transmitted** least** significant).

Modbus ASCII frame format

| Name | Length (bytes)| Function | | ——– | ————- | —————————————————————————————————- —– | | Start | 1 | Start with : (ASCII value 3A) | | Address | 2 | Station address | | function | 2 | Function code, e.g. read coils | | Date | n × 2 | Data + length will be filled according to message type | | LRC | 2 | Checksum (Longitudinal redundancy check) | | End | 2 | <CR><LF> set (ASCII values 0D, 0A) |

Modbus TCP frame format

Modbus protocol security

Modbus owes its widespread diffusion to the simplicity of the protocol and to its by now historic presence on the market. But precisely for these two factors it offers the side to different possibilities of attack, with numerous known vulnerabilities. Here’s how some attacks could be performed by exploiting the simple functions that the protocol itself provides, without dedicated enumeration tools like nmap.

A hacker can initiate his reconnaissance attack by scanning the network for Modbus devices using the protocol diagnostic commands: Clear Counter and Diagnostic Register. A request sent to the PLC, with function code 8 (0x08) and sub-function code 10 (0x0A), will cause the target server to clear its counters and diagnostic register. This feature is typically only implemented in serial devices.

Another diagnostic command that can be used is Read Device Identification as an attempt to gather Modbus device information: a request with Read Device Identification function code 43 will cause a Modbus server to return the vendor name , the product name and version number. Further information can also be provided in optional fields. An attacker sends the Modbus request packet with function code 43 to all systems on the network and collects information that could be useful for subsequent attacks.

Modbus protocol vulnerability

The Modbus TCP protocol implementation contains several vulnerabilities that could allow an attacker to perform enumeration tasks or send arbitrary commands.

1. Lack of Confidentiality: All Modbus messages are transmitted in the clear over the transmission medium.
2. Lack of Integrity: There are no integrity checks within the protocol, and as a result, it depends on lower-level protocols to preserve data integrity.
3. Lack of Authentication: There is no authentication at any level of the protocol, with the possible exception of some undocumented programming commands.
4. Simplistic Framing: Modbus TCP frames are sent over established TCP connections. While such connections are generally reliable, they have a significant drawback because of the next point.
5. Lack of session structure: Like many request/response protocols (e.g. SNMP, HTTP, etc.) Modbus TCP consists of short-lived transactions where the master sends a request to the slave which results in in a single action. When combined with the lack of authentication and poor TCP Initial Sequence Number (ISN) generation in many embedded devices, it becomes possible for attackers to issue commands without knowing the existing session.

“Illegal Function Exception” Vulnerability
These vulnerabilities allow an attacker to perform reconnaissance on the target network. The first vulnerability exists because a Modbus slave device can return an Illegal Function Exception for queries that contain unsupported function code. An unauthenticated remote user could exploit this vulnerability by sending crafted short codes to perform reconnaissance on the target network.

“Illegal Address Exception” Vulnerability
An additional reconnaissance vulnerability is due to the multiple Illegal Address Exception responses generated for queries that contain an illegal slave address. An unauthenticated attacker could exploit this vulnerability by sending queries that contain invalid addresses to the target network and gleaning information about network hosts from the returned messages.

Authentication Vulnerability
Another vulnerability is due to the lack of security controls in the implementation of the Modbus TCP protocol. The protocol specification does not include an authentication mechanism for validating communication between master and slave devices. This flaw could allow an unauthenticated user to send arbitrary commands to any slave device via an attack master.

DoS Vulnerability
The Modbus TCP protocol also contains vulnerabilities that could allow an attacker to cause a Denial of Service (DoS) condition on a target system. The vulnerability is due to an implementation error in the protocol itself when processing discrete input request and response messages.

Buffer overflow vulnerability
Another attack on Modbus can be the data packet exceeding the maximum length. The protocol limits the PDU size to 253 bytes to allow the packet to be sent over a serial line, e.g. RS-485 interface. Modbus TCP prepends a 7 byte Modbus Application Protocol (MBAP) header to the PDU and the whole, MBAP+PDU, is encapsulated in a TCP packet. This puts an upper limit on the packet size.

An attacker creates a specially crafted packet longer than 260 bytes and sends it to a client and server. If the client or server has been programmed incorrectly this could lead to a buffer overflow or denial-of-service attack.

Protocol Sniffing
The simplest attack to use against Modbus is to sniff network traffic, find connected devices, and then send malicious commands to the devices.

Having no security or encryption features, it’s easy to use Wireshark to gather information from data packets going over the network to and from a Modbus port on a device and read the contents of those packets. Wireshark makes it easy to see what’s in these packets, examine IP addresses, see request short codes, and alter devices to function properly.

Secure Modbus

The most common approach to securing OT protocols is to encapsulate them within a Transport Layer Security (TLS) protocol and use mutual authentication. Many standardization bodies publish guidelines for doing this depending on the protocol, for example:

• ODVA specifies how to apply TLS encryption to the EtherNet/IP protocol.
• Schneider Electric has recently worked to create a Secure Modbus version, which also includes the addition of the X.509 extension for defining permissions (read-only or read-write).
• IEC 62351-3 defines how to use TLS for the energy industry sector over TCP-based protocols.

Important note

This article is intended for educational and informational purposes only. Any unauthorized action towards any control system present on a public or private network is illegal! The information contained in this and other articles are intended to make people understand how necessary it is to improve defense systems, and not to provide tools for attacking them. Violating a computer system is punishable by law and can cause serious damage to property and people, especially when it comes to ICS. All the tests that are illustrated in the tutorials have been carried out in isolated, safe, or manufacturer-authorized laboratories.

Stay safe, stay free.