Despite being widely used in Industrial Control Systems (ICS), Modbus has been recognised as an insecure protocol. Securing and attacking Modbus has therefore been a topic for years, and it was first in 2018 that the Modbus Security protocol (MSP) was published, nearly 40 years after the initial introduction of Modbus. This article will introduce some common Modbus reconnaissance attacks, as well as briefly discussing the impact of MSP on those attacks.
In simple terms, Modbus is an open serial communication protocol standard used in industrial environments including Supervisory Control and Data Acquisition (SCADA) systems for communications between electronic devices. More specifically, it enables control message communication between control devices such as the Programmable Logic Controller (PLC) and a main controller. Modbus networks consists of Modbus clients, which is the one requesting information using function codes, and the Modbus server which supplies the requested information.
Due to the lack of integrity and authentication, Modbus networks have been left vulnerable to a variety of attacks including, but not limited to, Denial of Service (DoS) attacks, code injection and most relevant to this article; reconnaissance attacks.
Reconnaissance attacks are only one of several attack categories used in ICS and OT environments. Within this category, this article will focus on specifically four attacks which are used against Modbus servers; address scans, function code scans, device identification attacks and points scans. As with IT systems, reconnaissance attacks are used to identify information and details about the system which can then be used for further, more advanced attacks. The four attacks are usually conducted in a specific order:
1 – Address Scan
Address scan attacks identifies the Modbus server addresses on, and connected to, a network. These will be between 0 and 247, with 0 being used as the broadcast address for Modbus RTU. This essentially gives the adversary an overview of the attack surface. The scan works by sending Modbus queries to all the devices connected to the network, which will either respond with an error or success message – either way indicating they exist.
2 – Function Code Scan
Following the identification of the Modbus server addresses is the function code scan attack. Function codes are included in the communication and determines the request type, specifying which network actions to perform, such as writing or reading data over the network. If the function code is not supported, it will return an exception code. All other responses either in the form of success or error messages will indicate the function code requested is supported. Not all devices use all of them; some are vendor specific. Thus, in addition to identifying which function codes can be used, sending specific requests to the servers found on a network could even enable the adversary to identify the model and vendor of the equipment.
3 – Device Identification Attack
After a device and its supported function codes have been identified, more detailed fingerprinting of the server can be performed. This is achieved with a device identification attack, which collects more detailed information including its build number, ID and vendor’s name. As very briefly mentioned under the previous attack, it is mainly the read functions which are used to gather this information. Example, relevant function codes include 0x11, 0x17 and 0x2B which reports the server ID, values of registers and device identification – including the vendor’s name, model name or vendor URL – respectively. This is all valuable information which can be used to search for known vulnerabilities and exploits for further attacks such as code injection.
Nmap, for instance, has a script modbus-discover, which can be used with the IP addresses and port 502, which is the port Modbus utilises, to identify the ID of the client nodes on a network.
4 – Points Scan
Points, or programming points, are used to store input and output values written to or read from the devices. These can be accessed from within programs running on for instance PLCs, possible to due to lack of authentication from the Modbus protocol. This attack can also be used to identify implemented points on PLCs which acts as servers when they are connected to a Modbus network – granted the device’s address has previously been identified. The contents of the implemented points can also be read. Combined, this enables an adversary to create a memory map of a previously identified device.
As the points will return function codes, this scan is often performed after the function code scan to ensure the returned function codes are valid.
It was not until 2018 that Modbus Security Protocol was released, where they combined Transport Layer Security (TLS) with the original Modbus protocol. This introduced authentication and message integrity to the previously insecure protocol, helping prevent for instance Man-in-the-Middle (MitM) attacks.
Authentication measures being introduced means unauthorised individuals cannot communicate with the nodes on a Modbus network, which would help mitigate the reconnaissance attacks. Unfortunately, it being published does not necessarily mean it is implemented. In ICS security hardware and firmware tends to be developed protocol-specific, meaning they tend to be incompatible with different or newer protocols. This is especially the case with legacy hardware. Thus, it is less the issue of whether the attacks can be mitigated by securing the Modbus protocol, and more an issue of implementing the newer, securely developed protocol in the existing ICS and SCADA systems.
As a result, systems using the original Modbus protocol implements security by introducing other more general network security measures such as using VPNs, firewalls and overall layered security, such that even if an adversary manages to gather information with reconnaissance attacks, they cannot succeed with additional, more advanced attacks with greater chance of dangerous impacts on human safety.
It is important to note that the Modbus protocol has more vulnerabilities and identified attacks than those mentioned in this article. The protocol’s lack of authentication is the main vulnerability which makes the reconnaissance attacks possible, as any unauthorised adversary can communicate with the ICS devices connected to a Modbus network. To help mitigate this issue, the Modbus Security Protocol was developed and released in 2018. Unfortunately, common ICS issues such as legacy hardware being incompatible with the newer protocol resulted in the secure version of the protocol not being widely implemented in existing systems and standard security measures has therefore remained the best way to protect against the Modbus attacks. Hopefully, newer ICS devices and products compatible with the Modbus Security Protocol will be seen over the next years for improved and integrated security.
*Hedvig is a finalist in the Rising Star category in this year’s Security Serious Unsung Heroes Awards.