Team82 has discovered and disclosed a security bypass vulnerability in Rockwell Automation ControlLogix 1756 devices.
Our technique allowed us to bypass the trusted slot feature implemented by Rockwell that enforces security policies and allows the controller to deny communication via untrusted paths on the local chassis.
The vulnerability we found, before it was fixed, allowed an attacker to jump between local backplane slots within a 1756 chassis using CIP routing, traversing the security boundary meant to protect the CPU from untrusted cards.
An attacker would require network access to the device in order to attack this vulnerability. A successful exploit would allow an attacker to bypass the security restriction and send elevated commands to the PLC CPU.
Rockwell has issued a fix for CVE-2024-6242 (CVSSv3: 8.4), and users are urged to apply it immediately.
CISA has also published an advisory with mitigation advice.
According to Rockwell, ControlLogix, GuardLogix, and 1756 ControlLogix I/O Modules are affected by this vulnerability.
Also, Team82 is releasing a Snort rule that detects attempts to bypass this security protection on devices over the CIP protocol.
ControlLogix 1756 is a series of programmable automation controllers from Rockwell Automation. It is part of the ControlLogix family, which is designed for high-performance, scalable industrial automation applications. Specifically, in most cases, the 1756 is referred to as a chassis component which serves as a modular enclosure that houses various I/O modules, controllers, and communication processors. It provides the physical and electrical connections necessary for these components to operate together.
As most of Rockwell’s industrial products, the ControlLogix 1756 devices communicate over CIP (Common Industrial Protocol), a communication protocol used in industrial networks to facilitate the exchange of data between devices, such as sensors, actuators, and controllers. It is designed to support various industrial automation applications, providing a standardized way for devices to communicate within a network.
The 1756 chassis contains slots (also known as cards or modules) that are connected and communicate via the backplane. The backplane is a printed circuit board that connects the various modules within the chassis, allowing them to communicate. The backplane provides the electrical connections and data pathways that enable the exchange of information between the controller and the I/O modules.
This means that when an operator communicates via an engineering workstation with a ControlLogix 1756 PLC, in most cases, they actually communicate over the CIP protocol with the CPU card that is connected to the same backplane on the same chassis as the network card.
Team82 has uncovered a vulnerability in a local chassis security feature called the trusted slot, which is designed to deny untrusted communication from untrusted network cards on the chassis plane. When this feature is enabled, a controller denies communication through paths that are not trusted.
We found a vulnerability that allowed an attacker to bypass the trusted slot feature jumping between local backplane slots within a 1756 chassis using CIP routing, traversing the security boundary meant to protect the CPU from untrusted cards.
An attacker with this kind of access would be able to send elevated commands such as downloading logic to the PLC CPU even if the attacker is located behind an untrusted network card.
To support this architecture, CIP routing was introduced. In CIP, a path is a critical concept that defines the route or sequence of devices and communication objects through which a request or message travels. A path in CIP specifies the route from a source device (e.g., a networked device or controller) to a destination device (e.g., an I/O module or another controller). It outlines how to traverse the network and communicate with the desired device.
In a ControlLogix system, the backplane slots are identified by a unique path structure. This structure specifies how to access each slot by defining the communication route through the backplane. Each slot in the 1756 chassis has a unique slot number. The CIP protocol allows you to specify a slot number in the path to target a particular module. For instance, if you want to access data from an I/O module in slot 4, the path would include this slot number.
The CIP protocol uses the backplane addressing scheme (see OVDA document here, section 2.8. CIP Routing) to facilitate communication between the controller and the modules in different slots. By defining the correct path, you can instruct the controller to send or receive data from a specific slot on the backplane.
A path might look something like this: 1,3,1,0 - Backplane (01), Card 3 (03), Backplane (01), Card 0 (00):
A 1756 PLC in a production line might be connected to multiple sources via different network cards, for example, the HMI panel, engineering workstation, and other devices. To ensure that only specific individual devices are performing elevated operations on the PLC such as Download logic, a security mechanism was introduced called trusted slot.
The trusted-slot feature helps establish and enforce security policies within the ControlLogix chassis. It ensures that only authorized slots can communicate with each other, protecting against unauthorized access and potential tampering.
When the trusted slot feature is enabled, the controller denies communication through paths that are not trusted. This requires authentication to the module for anyone to access the controller with programming software. A specific module can be designated as a trusted slot, which means it is allowed to communicate freely with other slots within the same chassis, and especially with the CPU.
For instance, in the example above, if the security feature is enabled but our network card is not trusted, then the CPU will refuse to accept elevated operations from any CIP traffic that would originate from the untrusted network card.
We researched this mechanism and found an interesting vulnerability. Since all slots are connected via the backplane, and CIP supports path (routing), we could generate a CIP packet that will be routed through a trusted card before it reaches the CPU. Basically the method involved "jumping" between local backplane slots within a 1756 chassis using CIP routing. This technique allowed us to traverse the security boundary that was meant to protect the CPU from untrusted cards.
Per the CIP specification and how CIP message routing works, the CPU can check only the last slot and not the whole slot chain. This limitation enabled us to bypass the Trusted Slot protection and communicate with the CPU via an untrusted network card in which we were behind.
An attacker with access to the internal network could exploit this vulnerability, bypass the security restriction, and send elevated commands to the PLC CPU such as download and upload commands and updates to the controller’s CPU.
To further bolster security and aid in the detection of similar vulnerabilities in the future, we are releasing a Snort rule designed to detect this specific "jump" behavior. Snort, an open-source network intrusion detection system, will now include a rule that monitors and identifies attempts to exploit the CIP protocol in this manner. This rule will help organizations recognize and respond to potential security threats more effectively.
Our Snort rule will try to find any CIP Forward Open Request in which the requested path has 2 or more local chassis redirections on the same backplane of the PLC.
alert tcp any any -> any 44818 (content: "|6f 00|"; offset:0; pcre:"/\x54.*\xa3[^\x00-\x03](\x01[\x00-\x16]){2,}\x20\x02\$\x01/ms"; msg: " CVE-2024-6242: CIP suspicious forward open (might be used to bypass local chassis security)";
reference:url,claroty.com/team82/research/bypassing-rockwell-automation-logix-controllers-local-chassis-security-protection;reference:cve,2024-6242; classtype:misc-attack; sid:987002; rev:1;)
To sum up, we discovered a significant vulnerability in Rockwell Automation's 1756 Logix Controllers, specifically within the Local Chassis Security mechanism. This vulnerability had the potential to expose critical control systems to unauthorized access over the CIP protocol that originated from untrusted chassis slots.
In addition, we would like to thank Rockwell Automation. Upon identifying and reporting this vulnerability, Rockwell Automation acted to address the issue. The company has since released a fix that resolves the security flaw, enhancing the protection of their Logix Controllers and mitigating the risk associated with this bypass technique.
