This article continues to focus on the protocol layer, with three articles planned for this layer. The next one will cover DNP3, which is widely used in power systems. Most of the referenced materials in this article are accessible, except for one write-up on reversemode.com (http://reversemode.com/downloads/logix_report_basecamp.pdf) that requires authentication to download. If anyone can download it, please share.
Ethernet/IP
Compared to Modbus, EtherNet/IP is a more modern standard protocol. It was designed in the 1990s by the ControlNet International working group in collaboration with ODVA. EtherNet/IP is based on the Common Industrial Protocol (CIP). CIP is an open industrial protocol supported by ODVA, used in serial communication protocols such as DeviceNet, ControlNet, and EtherNet/IP. The American industrial control equipment manufacturer Rockwell/Allen-Bradley has standardized around EtherNet/IP, and other manufacturers like Omron also support EtherNet/IP in their devices. EtherNet/IP has become increasingly popular, especially in the United States. Despite being more modern than Modbus, EtherNet/IP still has security issues at the protocol level. EtherNet/IP typically operates over TCP/UDP port 44818. Additionally, EtherNet/IP has another port, TCP/UDP port 2222. The reason for using this port is that EtherNet/IP implements both implicit and explicit messaging. Explicit messages are referred to as client/server messages, while implicit messages are commonly known as I/O messages.
EtherNet/IP is a packaging of the CIP protocol for use over Ethernet. The CIP frame of EtherNet/IP encapsulates information such as commands, data points, and messages. The CIP frame includes four layers: CIP device configuration profile layer, application layer, presentation layer, and session layer. The remainder of the packet is the EtherNet/IP frame, through which CIP frames are transmitted over Ethernet. The structure of EtherNet/IP packets is shown in Figure 5-12.
The CIP specification has many stipulations regarding packet structure, meaning that every device using EtherNet/IP must implement commands that comply with the specification. Below are the fields of the CIP frame encapsulated in the EtherNet/IP header:
-
Command
A two-byte integer corresponding to a CIP command. The CPI standard requires that devices must be able to receive unrecognized command fields and handle such exceptions.
-
Length
A two-byte integer representing the length of the data portion of the packet. For requests without a data portion, this field is 0.
-
Session Handle
The session handle is generated by the target device and returned to the initiator of the session. This handle will be used for subsequent communications with the target device.
-
Status
The Status field stores the status code returned by the target device after executing the command. A status code of “0” indicates successful command execution. In all request packets, the status code is set to “0”. Other status codes include:
– 0x0001 Invalid or unsupported command
– 0x0002 Insufficient resources on the target device to process the command
– 0x0003 Incorrect data format or invalid data
– 0x0065 Received invalid data length
-
Sender Context
The sender of the command generates this six-byte value, which the receiver will return unchanged.
-
Options
This value must always be 0; if it is not, the packet will be discarded.
-
Command-specific data
This field is modified based on the command being received/sent.
If the request sender is an engineering station, the first command executed in most sessions is the “List Identity” command. The packet shown below has a command field of 0x63, representing the “List Identity” command, with the context being “0x00006a0ebe64”. This command is very similar to Modbus function code 43 and can query device information such as vendor, product, serial number, product code, device type, and version number. Using the Python script ethernetip.py found in the GitHub project pyenip (https://github.com/paperwork/pyenip/blob/master/ethernetip.py), you can query information about EtherNet/IP devices. By default, this script does not parse some responses; you need to uncomment the testENIP() function at the bottom of the script for it to send and receive the “ListIdentity” command. When executing the script.
At the same time, you can use Wireshark to view the request and response packets.
We did not provide the script code in this example because it is about 1000 lines long. You can obtain the script by visiting the following GitHub link (https://github.com/paperwork/pyenip/blob/605ad6d026865e3378542d4428ec975e7c26d2e4/ethernetip.py).
Device Information Leakage
-
Popularity: 10
-
Exploitation Difficulty: 8
-
Impact Surface: 3
-
Threat Score: 7
Digital Bond implemented a script similar to pyenip in their Redpoint project, which can be used to extract information from remote devices. The Redpoint script uses the “ListIdentity” command mentioned in the previous section and employs NES scripts to parse requests. An interesting aspect of this script is that its “Command Specific Data” section contains a socket address (IP address and port number). This is the real IP address and port number of the exposed remote device, even if it is behind a NAT device.
By searching on Shodan (https://www.shodan.io/search?query=port%3A44818), we found a large number of devices where the exposed IP field differs from the actual scanned IP address. Thus, we conclude that most Ethernet/IP devices are deployed in internal networks rather than being directly exposed to the internet. The scan results shown in Figure 5-15, using nmap to scan a CompactLogix control system, indicate that the exposed device IP and scanned IP do not match, suggesting that the target system is behind a router or firewall.
The above figure displays some information, including the manufacturer of the device, “Rockwell”. The manufacturer ID in the response is a two-byte identifier that maps to a list of vendors supporting Ethernet/IP. However, this vendor list is not publicly available. After a detailed analysis of the packets captured by Wireshark, we found that the manufacturer ID is replaced with the manufacturer name after being parsed by Wireshark. This indicates that Wireshark has information on how to map manufacturer IDs to names. By searching through the Wireshark source code on GitHub, we found the following code snippet that tells us how to parse manufacturer IDs. Wireshark is often a powerful and useful resource when analyzing industrial control protocols.
Using commands like “List Identity”, you can easily replay packets with almost no modification. The session handle will be set to 0, meaning no session is generated, as the command simply sends a command and receives a system response. To further communicate with the device, a register session command (0x65) must be sent. This command will set the session handle ID, which will be used for subsequent session communications. As shown in Figure 5-16, the request for registering a session uses the standard ID “0x00000000”, and the target device returns the session handle it generated, “0x03A566BB”.
Ethernet/IP Man-in-the-Middle Attack
-
Popularity: 5
-
Exploitation Difficulty: 8
-
Impact Surface: 8
-
Threat Score: 7
Ethernet/IP has similar issues to most industrial control protocols. The consulting and training company Kenexis released examples of man-in-the-middle attacks against Ethernet/IP. These examples can be found on their GitHub project page (https://github.com/kenexis/PortableICS-MITM). Unlike Modbus, simple packet replay is ineffective for certain commands in Ethernet/IP. This makes the attacks slightly more complex. However, for most attackers, this minor difficulty will be negligible as long as they have a basic understanding of the Ethernet/IP protocol. Once the session handle is negotiated, a man-in-the-middle attack can be achieved by manually altering the sequence number, similar to the previous Modbus-vcr tool.
High-Risk Command Codes in Ethernet/IP
-
Popularity: 5
-
Exploitation Difficulty: 8
-
Impact Surface: 8
-
Threat Score: 7
Just as Modicon uses function code 90 to terminate the CPU, some Ethernet/IP devices also support similar command codes. A Metasploit module was released in Digital Bond’s Basecamp project (https://www.rapid7.com/db/modules/auxiliary/admin/scada/multi_cip_command) that can be used to terminate a large number of PLCs in an Allen-Bradley ControlLogix control system, as well as other malicious actions such as crashing Ethernet cards.
Ruben Santamarta from Digital Bond noted in the write-up for the Basecamp project, “Every packet we send must include the session handle. That’s all there is to it, and then we hacked the controller. There are no further security mechanisms at the protocol level.” [Translator’s note: I cannot download the document on reversemode.com; if anyone can download it, please share.] Ruben pointed out that as long as one understands the Session Handle, it is easy to attack Ethernet/IP. Another key to the success of this attack is a command code implemented by Allen-Bradley. Allen-Bradley has implemented CPU termination functionality in the NOP (0x00) command.
This command is not documented in the CPI or Ethernet/IP specifications and is a proprietary implementation of Allen-Bradley/Rockwell controllers. Through testing a large number of devices, we found that in some older firmware, not only does the ControlLogix CPU terminate, but the device crashes and requires a hard reboot. For current models, the PLC must be unplugged and reinserted to run again. In rare cases, the PLC needs to be reprogrammed.
We still maintain our consistent advice: if you want to test your Ethernet/IP devices, please only perform these tests on non-production devices and ensure you have permission to execute exploits on the devices, as the consequences of performing these tests on the devices are unpredictable.
This article was translated by Kanxue Forum ljcnaix .
Please indicate the source from Kanxue Forum.
If you like it, don’t forget to give it a thumbs up!
Popular Reading Articles:
-
5 Reasons to Choose Kanxue Enterprise SRC
-
Beginner’s Guide to Windows Kernel Exploitation (Part 2): Familiarizing with HEVD
-
Beginner’s Guide to Windows Kernel Exploitation (Part 1): Setting Up the Experimental Environment
-
Analyzing the Dirty Cow Principle from a Kernel Perspective
-
[Resource] Web Security Online Practice Platform
-
……
For more excellent articles, long press the QR code below, “Follow Kanxue Academy’s WeChat public account” to view!
Kanxue Forum: http://bbs.pediy.com/
WeChat Public Account ID: ikanxue
Weibo: Kanxue Security
Business Cooperation: [email protected]