CVE-2023-3595: Rockwell Automation ControlLogix Vulnerability Analysis Fuels Better Risk Assessment and Threat Detection
On July 14, CISA published an industrial control system (ICS) advisory about two new critical vulnerabilities affecting Rockwell Automation ControlLogix communication modules: CVE-2023-3595 and CVE-2023-3596. CISA and Rockwell Automation recommended that asset owners patch vulnerable devices and add controls such as segmenting networks and using network intrusion detection. Two days later, passive vulnerability matching was added to Forescout® Risk and Exposure Management and pushed to Forescout® eyeInspect customers. This was followed in September with fine-grained detection rules for attempts to exploit both CVEs.
In this blog post, we use CVE-2023-3595 to show how the in-depth vulnerability analysis we routinely do at Forescout Research – Vedere Labs fuels better risk assessment and threat detection capabilities in the Forescout® Platform. The analysis also exposes how insufficient information in cybersecurity advisories causes delays for cybersecurity researchers.
Summary of CVE-2023-3595
Per the CISA advisory, Rockwell Automation ControlLogix communication modules (sample pictured below) are used in critical manufacturing, where attackers could potentially exploit them to halt production lines or establish persistence for more sophisticated and stealthy attacks, such as industrial espionage.
In its most simple application, CVE-2023-3595 can be used to disrupt communications to and from a specific ControlLogix module and the nested networks behind it, causing a denial-of-service (DoS) attack and consequently a denial of control (T0813) or denial of view (T0815). Since the vulnerability also allows for remote code execution (RCE), attackers could use the communication module as a foothold for subsequent deep lateral movement, deployment of OT payloads, persistence or counter-forensics.
Both CVEs in the advisory were reportedly discovered as part of an offensive capability held by an unnamed advanced persistent attack (APT), although supposedly not found to be exploited in the wild. Therefore, CISA and Rockwell Automation urged asset owners to update controller module firmware and take additional controls such as segmenting networks, as well as implementing network detection signatures. Scenarios like this with multiple recommended remediation or mitigation steps are common in OT networks, where patching is often difficult.
Key findings
Our analysis of this vulnerability uncovered discrepancies between detection rules and patches that were released by the vendor, as well as the potential for deep lateral movement if the vulnerability is exploited.
- There are discrepancies between the detection rules released by Rockwell and what was fixed in the affected products. Functionality related to one Common Industrial Protocol (CIP) class (the Email Object) was patched but has no corresponding detection rule available, while the vendor-specific Spy Object has detection rules but no patched functions identified in the analyzed firmware.
- Beyond persistence, CVE-2023-3595 enables deep lateral movement. Media reports focused on how CVE-2023-3595 allows for threat actor persistence. This is not uncommon in RCE vulnerabilities, especially because the firmware signing mechanism on the affected modules lacks true secure boot functionality. In this case, however, the vulnerability is exploitable over CIP routing, which enables deep lateral movement into nested factory cells, across east-west boundaries, and in some cases across firewalls or non-Ethernet links.
Reverse engineering to craft precise detection rules
Since the CISA advisory contained no public details about the nature of CVE-2023-3595, we had to perform some reverse engineering to craft detection rules for Forescout eyeInspect. This involved detailed analysis of Snort rules and firmware versions.
Snort rule analysis
As part of the vulnerability advisory, Rockwell Automation released a set of Snort rules to detect exploitation of these CVEs. We first observed two recurring patterns in the rules: cip_class:0x342; cip_service:0x4D;andcip_class:0x351; cip_service:0x50.
The manuals (1, 2, 3) for the affected communication modules specify that CIP class 0x342 corresponds to the Socket Object. Class 0x351 is undocumented, but we discovered that it belongs to the vendor-specific Spy Object. Strangely, Rockwell Automation’s description of the Snort rules also mentions the CIP Email Object (Class 0x32f), but this object is not present in any of the available rules.
Unpatched vs. patched firmware version analysis
Next, we did a differential analysis between the unpatched and patched versions of the modules’ firmware images. We performed our analysis on v11.003 and v11.004 of the 1756-EN2T/D respectively. Unfortunately, since the 1756-EN4* firmware images are encrypted, we could not perform easy triage of CVE-2023-3596.
By focusing on functions that are highly but not fully similar between firmware versions, we singled out those that might have received minor patches. For example:
The following functions seem to have received bounds-checking patches for CVE-2023-3595, which matches the report of the issues affecting the Email and Socket objects:
- _ZN16SocketObjectInst13ReadUdpSocketEjiR9UcMsgSrvrRiR9CipStatus
- _ZN16SocketObjectInst13ReadTcpSocketEjiR9UcMsgSrvrRiR9CipStatus
- _ZN11EmailObject21SendMailTransferAgentEPcPhS1_S1_S1_S1_jR9CipStatusS0_
Two observations are important here:
- Although the Email Object does not occur in Rockwell Automation’s Snort rules, related code was patched.
- The vendor-specific Spy Object occurs in the rules but does not seem to have any patched functions.
Exploitable vulnerabilities in three CIP objects
After analyzing the patched functions in detail, we concluded that CVE-2023-3595 can be broken down into three separate issues, each affecting one type of CIP object and with different nuances for impact and exploitability.
Socket Object vulnerability
The vulnerability exists in the read method of the SocketObject class both for TCP and UDP sockets, which is enabled by default. This object allows engineers access to a POSIX-style socket interface on the communications module that can be used to send and receive raw TCP and UDP. When reading from a socket, the length field is only checked to be non-zero, but since the length field is a signed integer that is later cast to an unsigned integer, this can lead to a signedness conversion error when supplying a negative length leading to an out-of-bounds write on the underlying bufferpool object later during deallocation. This vulnerability is exploitable for both denial of service (DoS) and RCE. Note that while the scope of the impact is limited to the communication module itself, subsequent deep lateral movement to other modules or across the backplane is very much feasible, as we demonstrated using a different vulnerability affecting the same Logix communication modules.
Email Object vulnerability
A second vulnerability exists in the SendMailTransferAgent method (CIP service 0x4b) of the EmailObject class, which is enabled by default but requires a valid and reachable SMTP server to be configured (though an attacker could stand up a fake server to play that role). This object allows engineers access to an SMTP client on the communications module that can be used to send emails for status updates, alarms and so on. The issue is that when sending an email, static buffers of size 1024 are allocated and insufficient bounds checks are performed on all email parameters. When these parameters are too long, it leads to an out-of-bounds write on the underlying bufferpoolobject later during deallocation.
Spy Object vulnerability
While no patch seems to have been applied to this object, we did not exhaustively investigate all methods for vulnerabilities. The Rockwell Automation Snort rules alert when its GetDataByName method (CIP service 0x50) has arguments of length greater than 64.
Mitigation for CVE-2023-3595
To mitigate the three issues we uncovered within CVE-2023-3595, we crafted detection logic for Forescout eyeInspect that raises an alert whenever it sees a CIP message that matches one of the following conditions:
- Class: 0x342 (SocketObject), Service: 0x4d. CIP command-specific data is formatted as: <timeout (UINT32 little-endian), length (UINT32 little-endian)> and length field has a negative size (value > 0x7fffffff).
- Class: 0x32f (EmailObject), Service: 0x4b. CIP command-specific data is formatted as: <length (UINT32 little-endian), data (STRING)> and the length of the data field is greater than or equal to 1024.
- Class: 0x351 (SpyObject), Service: 0x50. CIP command-specific data is formatted as: <parameter 1 length (UINT32 little-endian), data 1 (x bytes), parameter 2 length (UINT32 little-endian), data 2 (y bytes), …> and any of the parameter length values is greater than 64.
Better risk assessment – understanding the potential impact of a vulnerability
Possible risk of persistence and firmware manipulation
Coverage of the vulnerabilities specifically mentions post-exploitation impact through firmware manipulation. This is interesting because CVE-2023-3595 does not present any extra capabilities compared to similar RCE vulnerabilities on these modules, such as Urgent/11. This suggests that whoever uncovered this capability with the unnamed advanced persistent threat (APT) may have also uncovered an as-of-yet undisclosed post-exploitation payload focusing on firmware manipulation and persistence.
All hardware series of the affected communication modules (except for the 1756-EN4*) have both signed and unsigned firmware versions. These devices typically accept firmware updates without authentication, so persistence on modules without signed firmware can be achieved trivially. Persistence on modules with signed firmware is more complicated. Once signed firmware is installed, downgrades to unsigned firmware versions are disallowed, so attackers must either break the firmware signing mechanism or have RCE on the module to achieve persistence.
Rockwell Automation Logix module firmware images come with a manifest NVS file describing all components (including data and code held in PLT files), each of which is linked to a DER certificate file. We did not delve into the inner workings of the firmware signing mechanism, but an attacker with RCE on the module can simply invoke the flash writing routine from within the firmware itself to overwrite the stored firmware PLT files since they aren’t tied to a diversified hardware root of trust for true secure boot. The firmware signing mechanism seems to prevent malicious firmware updates from being pushed through the regular update mechanism. However, it doesn’t seem to prevent malicious firmware from booting. The same impact can be achieved through the Urgent/11 vulnerabilities.
If a communication module were persistently implanted, this would render it completely untrustworthy, regardless of attempts to factory reset it or perform logical forensics. It would require de-commissioning and subsequent deep-dive forensic analysis.
Impact beyond persistence
While some security vendors mentioned that the impact is like that of TRITON, this is not completely true, since RCE does not immediately allow for direct access to controller runtime logic; it requires additional inter-module lateral movement first.
Another interesting aspect of CVE-2023-3595: it is gracefully routable over CIP, unlike some TCP/IP stack vulnerabilities, which aren’t always routable. Due to the inherently deep routability of CIP networks, this presents attackers with a powerful capability to move deep into nested factory cells, laterally across east-west boundaries, among other scenarios.
One nuance is that triggering the vulnerability in the Socket Object requires direct interaction with the opened TCP/UDP port on the module’s Ethernet interface, which is not possible in a CIP-routed scenario. One way attackers can overcome this is by creating two Socket Objects, one vulnerable and another to exploit it on the same local interface.
How Forescout customers are protected
For any CISA cybersecurity advisory, the general remediation and mitigation steps provided must be translated into specific product updates and instructions. In this case, that involved the following product updates and instructions to customers.
Passive vulnerability matching
On July 14 (two days after the advisory was released) passive vulnerability matching, which allows for risk assessment and segmentation decisions, was added to the CVE database for Forescout eyeInspect and Forescout Risk and Exposure Management. Forescout eyeInspect customers were instructed to download the latest vulnerability bundle and ensure it was installed locally to detect devices on all potentially vulnerable networks. Forescout Risk and Exposure Management customers benefit from real-time deployment of content on the cloud, so they can detect vulnerable devices just by searching for specific CVEs on their dashboard.
Detection of attempts to exploit
On September 12 we released a Threat Detection Add-Ons script (v1.20) for Forescout eyeInspect that enables detection of attempts to exploit the many nuances of CVE-2023-3595. Again, customers must download and locally install the latest version of the script to help ensure they can detect exploitation attempts against devices on their network.
Discussion: cybersecurity advisory limitations
Security advisories are indispensable to cybersecurity researchers and security product vendors in two ways: (1) to aid analysis to be shared with the broader cybersecurity community, and (2) to ensure security products can detect and mitigate them. Forescout Vedere Labs relies on CVE advisories to meet both objectives. We routinely do this type of deep analysis to help ensure our customers have the best possible protection against critical vulnerabilities.
Unfortunately, security advisories and the guidance from impacted vendors – especially regarding how to patch and protect OT – often do not provide enough information for defenders to perform a solid risk assessment. And they have been providing less and less information over the years.
Our analysis of CVE-2023-3595 illustrates the issue. Yes, we were able to push out partial mitigation (passive vulnerability matching) in just days. However, the fact that we had to reverse engineer code and experiment with exploit proofs of concept to fully understand the vulnerability before we could tackle detection shows the delays caused by the short and opaque descriptions in CVE advisories. Multiply this scenario across hundreds of cybersecurity researchers and vendors and you begin to see the magnitude of the problem.
See vulnerability researchers in action. Take a tour of our Adversary Engagement Environment in Eindhoven, Netherlands, with Rik Ferguson.