SCADA/ICS systems are differentiated from traditional information systems in a number of ways. Probably the most important differentiation are the many communication protocols. Unlike traditional IT systems with their standardized TCP/IP protocols, SCADA/ICS systems are marked by significant variation in their communication protocols.
SCADA/ICS Manufacturers
There are numerous SCADA/ICS protocols sometimes different protocols within the many manufacturers of hardware. The major manufacturers of SCADA/ICS hardware include;
Seimens
Honeywell
Toshiba
Allen-Bradley
Mitsubishi
GE
Schneider Electric
Rockwell Automation
and many others.
Each of these companies makes varied products and use various protocols, some of which are proprietary. This is one of the many reasons that securing SCADA/ICS systems can be so challenging. At the same time, this industry has benefited from security through obscurity as many attackers are unfamiliar with these protocols.
ICS Communication Protocols
Among these many manufacturers of PLC and SCADA/ICS systems, there are numerous communication protocols. To pentest these systems you need at least a rudimentary understanding of these protocols.
These are the most widely used protocols.
Modbus
DNP3
ICCP
Common Industrial Protocol (CIP)
EtherNet/IP
CompoNet
ControlNet
DeviceNet
OLE for Process Control (OPC)
PROFIBUS
Foundation Fieldbus H1
Each of these protocols operates slightly differently (in some cases, VERY differently) and we will detail their inner workings in separate articles here on Hackers-Arise, but for now, let’s focus on the most widely used protocol, Modbus.
Modbus
Modbus Serial (RTU)
Modbus RTU was first developed in 1979 by Modicon (now part of Schneider Electric) for industrial automation systems and Modicom PLC’s. It has become the industry standard, if there is one. Modbus is widely-accepted, public domain protocol. It is a simple and lightweight protocol intended for serial communication. It has 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/reply” model. Because it is simple and lightweight, it requires little processing power.
Modbus was first implemented on either RS-232C (point-to-point) or RS-485 (multi-drop) physical topology. 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 initiate queries. The slaves/server supply the requested data to the master or perform the action requested by the master. A slave is any peripheral device (I/O transducer, valve, network drive, or other measuring device) which processes information and sends its output to the master via the Modbus protocol.
Masters can address individual slaves or initiate a broadcast 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 initiate messages, they can only respond to the master. A master’s query will consist of the slave address (slave ID or Unit ID), a function code, any required data and an error checking field.
Modbus communicates by Function Codes. Function code can be used to perform a wide-range of commands.
Please see the list of function codes below.
Modbus Function Codes
Function code 8 is the diagnostic function code. Within that Function code 8 we have numerous sub-function codes. Note Function Code 8, sub-function code 04, Force Listen Only Mode. This can be used to create a Denial of Service (DoS) condition on some Modbus enabled systems.
Note the Diagnostic sub-function codes below.
Diagnostic Sub-Function Codes
Modbus TCP
Modbus TCP is the Modbus protocol encapsulated for use over TCP/IP. It uses the same request/response as Modbus RTU, the same function codes and the same data limit of 253 bytes. The error checking field used in Modbus RTU is eliminated as the TCP/IP link layer uses its checksum methods, eliminating the need for the Modbus RTU checksum. Modbus TCP utilizes the reserved port 502 to communicate over TCP/IP.
Modbus TCP adds a Modbus Application Protocol (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 in length and 1 byte for the address (Unit ID).
Modbus Security
Modbus has numerous security concerns.
Lack of authentication – Modbus does not include any form of authentication. An attacker only needs to create a packet with a valid address, function code and any associated data.
No encryption – all communication over Modbus is done in cleartext. An attacker can sniff the communication between the master and slaves and discern the configuration and use.
No Checksum – although Modbus RTU uses a message checksum, when Modbus is implemented in TCP/IP, the checksum is generated in the transport layer, not the application layer, enabling the attacker to spoof Modbus packets.
No Broadcast Suppression – without broadcast suppression (all addresses receive all messages), the attacker can create a DoS condition through a flood of messages.
For a more thorough understanding of the Modbus protocol, check out my article of Modbus simulation here.
Look for my coming articles detailing each of the SCADA/ICS protocols and their security concerns and vulnerabilities in future article here at Hackers-Arise.
