Finding Rockwell Automation Allen-Bradley Communication Modules Affected by CVE-2023-3595 and CVE-2023-3596 in OT Environments

Identifying vulnerable systems in your industrial environment can be complex. Use the wrong tool and it will overlook affected devices. Find out how Tenable OT Security is designed to give you in-depth asset visibility to address these new vulnerabilities without disrupting productivity.

Rockwell Automation, in coordination with the U.S. government, announced two critical vulnerabilities today that require immediate attention, citing a novel exploit capability attributed to Advanced Persistent Threat (APT) actors known for cyberactivity involving industrial systems and suggesting possible intent to target critical infrastructure worldwide. These vulnerabilities are:

• CVE-2023-3595, a remote code execution (RCE) vulnerability in Rockwell Automation Allen-Bradley ControlLogix Communication Modules for its 1756 EN2* and 1756 EN3* product families. An attacker could exploit this vulnerability to gain RCE on a vulnerable module by sending specially crafted common industrial protocol (CIP) messages.

• CVE-2023-3596, a denial of service (DoS) vulnerability in Rockwell Automation Allen-Bradley ControlLogix Communication Modules for its 1756 EN4* product family. An attacker could exploit this vulnerability to cause a DoS condition on a target system by sending specially crafted CIP messages to a vulnerable device.

To help organizations quickly address these vulnerabilities, Tenable has published multiple plugins to detect CVE-2023–3595 and CVE-2023-3596. You can read more about these in this blog post from the Tenable Research team. These plugins are available for users of Tenable Nessus and Tenable OT Security (formerly Tenable.ot), but there are several key differences in how each operates. To understand these differences, we first have to consider two key challenges organizations face in remediating these vulnerabilities in their systems: 

1. How to rapidly detect easily accessible network assets; and
2. How to discover indirectly connected (nested) assets amidst industrial control system (ICS) sprawl.

This blog provides guidance on how operators of critical infrastructure and other operational technology environments can quickly and effectively address these flaws. 

A brief history of OT and PLCs

To understand the challenges, let’s first review a brief history of operational technology (OT) and programmable logic controllers (PLC). Since its introduction in the late 1960s, PLC technology has become more complicated — and more connected. These advances created a need for network and distributed interfaces. Rather than running signal wires across vast areas, asset owners started leveraging serial and coax communications to place these devices closer to the systems they needed to control. As network connectivity became ubiquitous, it has changed how a manufacturer or asset owner operates these devices. 

Nowadays, most have Ethernet interfaces, and often more than one. PLC systems can connect between each other, programming terminals, supervisory control and data acquisition (SCADA) systems, as well as enterprise databases.

When it comes to Rockwell Automation devices, the Allen-Bradley ControlLogix system uses connections to establish communication links between devices (you can read more in Rockwell Automation’s product documentation). These connections include the following types:

• Controller-to-local I/O modules or local communication modules Controller-to-remote I/O or remote communication modules 
• Controller-to-remote I/O (rack-optimized) modules 
• Produced and consumed tags 
• Messages 
• Controller access with the Studio 5000 environment 
• Controller access with RSLinx software for human-machine interface (HMI) or other applications

These devices are installed in different architectures for a variety of reasons, including operational/functional requirements, communication needs and segmentation. But there are challenges detecting these assets within an organization.

Challenge No. 1: Rapid detection of easily accessible networked assets

Modern PLC systems are designed to be modular — many different types of modules can be present in a chassis or “rack.” A PLC chassis can have multiple communication cards, input cards or output cards. It is common in many environments to see PLCs connected to a site-level network while also containing multiple additional network modules which provide network connectivity to smaller networks for cell/area zone segmentation.

Example: 

Source: Rockwell Automation/Cisco Converged Plantwide Ethernet Design and Implementation Guide, Fig. 3-13. 

Let’s consider the below scenario with a ControlLogix system connected to a human-machine interface (HMI) or site-level network. In our scenario, a Nessus scanner is present within the same routable supervisory/site network.

Source: This image was created by Tenable using the Rockwell Automation Integrated Architecture Builder, July 2023

The network interface attached to the site or supervisory network has been identified by Nessus and users can start investigating how this asset can be remediated with internal teams. Unfortunately, users do not have granular details to identify slot information in the ControlLogix backplane, but they have identified the affected asset’s IP address.

Identifying all of the affected assets in the enterprise is a key first step in responding to these vulnerabilities.

Challenge No. 2: Nested assets and ICS sprawl

Examining our scenario closer, there are three additional network interfaces connected downstream in our environment that would not be identified by any traditional IT vulnerability scanners. ControlLogix devices use Common Industrial Protocol (CIP) to communicate between one another. CIP encompasses a comprehensive suite of messages and services for the collection of industrial automation applications — control, safety, synchronization, motion, configuration and information. 

Diving deeper into industrial control systems and discovering additional nested devices within these PLCs and chassis requires “speaking the language” of these industrial protocols. 

There are two primary methods to identify assets within an ICS environment:

1. Passive: Passive technologies can identify active exploitation of these CVEs (You can read more about them in this blog post). Typically, these sensors are placed at critical junctions of ICS networks, such as DMZ, core switches and entry/egress points. Unfortunately, leveraging passive technologies to identify affected assets is challenging because ICS protocols such as CIP do not commonly broadcast all the information needed to match a vulnerability during their normal state of operation. During normal operation, these devices have no need to volunteer key attributes about themselves. ICS protocols are designed to run lean with only information critical to performing the industrial process. 
2. Active: To achieve full asset visibility in these environments, it is important we enumerate these assets uniquely. Identifying only devices with connections at a site-level network won’t provide a holistic view, and will keep you from getting a complete inventory of affected assets in the event of a vulnerability, leaving you at risk. 

Let’s explore further how active enumeration works in these environments. Going back to our example, there are actually a total of four network interfaces present, even though only one routable from the site network (Slot 1 of CLX_1 – and don’t worry the first slot is Slot 0!) was initially discovered.

Source: This image was created by Tenable using the Rockwell Automation Integrated Architecture Builder, July 2023

To identify the two additional network interfaces in slots 2 and 3, and the remote chassis network modules in slot 0, it is necessary to communicate to these devices in their native protocol, CIP.

Safely enumerating OT assets with Tenable OT Security

Tenable OT Security was designed specifically for industrial environments and communicates safely with OT assets using its patented active querying technology (#US-10261489-B2). This technology employs read-only queries in native device communication protocols, yielding deep details on the state of each industrial asset in a safe manner and without operational impact on queried devices. In addition to the protocol in use by Rockwell Automation’s ControlLogix products, Tenable supports an extensive list of protocols and vendors, not just for OT, but for IT systems, too (which, surprising to some, can often make up to 50% of devices in OT environments).

When querying a ControlLogix with Tenable OT Security, each module in the chassis is enumerated via EthernetIP/CIP. This data is used to build an asset inventory of connected modules and subnetworks. Each can be assessed for vulnerabilities based on the gathered information.

Through integration with Tenable Vulnerability Management (formerly Tenable.io) and Tenable Security Center (formerly Tenable.sc), users can connect Tenable OT Security to populate asset and vulnerability data into their enterprise vulnerability management tools for a holistic view (you can read more about this here.)

Next steps you can take to address CVE-2023-3595 and CVE-2023-3596

Tenable highly encourages you to update your plugins and run a scan to determine if CVE-2023-3595 and CVE-2023-3596 exist in your environment and, if they do, address them by upgrading to the latest firmware version immediately.

Deep visibility into assets and vulnerabilities across IT and OT devices in industrial environments is core to the capabilities in Tenable OT Security, but there’s a lot more that it can do. To learn more about Tenable OT Security, visit our product page and request a demo.