Team82 has privately disclosed details to Real Time Automation (RTA), informing the vendor of a critical vulnerability in its proprietary 499ES EtherNet/IP (ENIP) stack. The vulnerability could cause a denial-of-service situation, and depending on other conditions, could expose a device running older versions of the protocol to remote code execution. The Industrial Control System Computer Emergency Response Team (ICS-CERT) today released an advisory, and assessed a CVSS score of 9.8 out of 10.
A stack overflow vulnerability was discovered in RTA's 499ES ENIP stack, all versions prior to 2.28, one of the most widely used OT protocols.
Successful exploits could cause devices running older versions of the ENIP communication protocol to crash, or in a worse-case scenario, allow for remote code execution.
RTA has confirmed the vulnerable code was removed in 2012, but it's likely that many vulnerable implementations still exist in products in use today.
Users should determine which version they are running and update to current versions.
Similarly to previous disclosures, such as Ripple20 or Urgent11, this is another case of a vulnerable third-party core library putting products from ICS vendors at risk.
Team82 developed a custom generic ENIP stack-detection tool in order to identify and classify products using the same third-party ENIP stack code.
Using the detection tool, Team82 was able to identify 11 devices using RTA's ENIP stack from six different vendors, which are likely to be vulnerable.
Open standard OT protocol stacks such as EtherNet/IP (ENIP) are truly set-and-forget software implementations that enable network communication between devices. These protocols operate reliably, and some sit for years or decades without updates or code review to avoid any process interruption.
As connectivity continues to make air-gaps a thing of the past, researchers are beginning to look at these forgotten corners of the networking stack for vulnerabilities that could put the safety and reliability of industrial processes at risk. The frequency of code reviews is ramping up, like the one undertaken by Claroty researchers on a proprietary version of the ENIP stack developed by Real Time Automation (RTA), one of the oldest and widely used OT protocols in use. This ENIP stack was purchased and integrated into the firmware of many existing ICS devices in use today.
We found a serious stack overflow vulnerability that could, at a minimum, cause a denial-of-service condition on a device running this flavor of EtherNet/IP, and likely could also enable remote code execution. The vulnerability, RTA confirms, has been present in all versions of its 499ES ENIP stack up to, but not including, v2.28, which was released Nov. 21, 2012. Any version developed and released since then does not include the vulnerable code. ICS-CERT assessed the vulnerability a CVSS score of 9.8.
However, many vendors may have bought vulnerable versions of this stack prior to the 2012 update, starting in the early 2000s when it was first issued, and integrated it into their own firmware. This would leave many running in the wild still today. Though vendors can implement their own proprietary ENIP stacks based on the protocol specifications, buying an ENIP stack SDK and integrating it into their firmware saves the burden of in-house development. While avoiding re-inventing the wheel is usually a good software development practice, the tradeoff is that the discovery of a vulnerability in the core of ENIP stack would mean multiple devices are simultaneously at risk.
Stack-overflow vulnerabilities are common coding mistakes, and if triggered can cause an application to crash or allow an attacker to run code of their choice. Remote code execution in this case depends on the specific firmware and device. An exploit would require an attacker to find an exposed device online and send a specially crafted ENIP forward-open request to the device over TCP port 44818.
A forward-open request is a CIP request (Common Industrial Protocol) that opens a session to a specific CIP path and allows a client to communicate with an endpoint over the same CIP session without sending the entire CIP path again in every request. CIP is the communication protocol used to share automation data between devices.
When sending a forward-open request, the client must specify the connection CIP path to establish communication. Claroty researchers discovered a bug in the forward-open CIP path parsing mechanism; the stack buffer overflow vulnerability occurs because of an improper size check of the connection CIP path.
The improper check allows a program to write to a memory address outside a fixed-length buffer, resulting in corruption of the adjacent data on the stack. This will usually result in a crash, but a crafted request can also include code that will execute unchecked.
While researching the ENIP parsing mechanism, Claroty researchers discovered that the connection CIP path is a static integer (16 bit) array of 32 values and it is part of a struct that contains information about the forward-open connection.
We also discovered that upon opening a new forward-open connection, the user can supply a CIP path up to the size of 255 values. To trigger this bug, the attacker can supply a large (>32) connection path size which will cause the parser to write outside the bounds of the connection path property of the connection struct on the stack. This will lead to a stack buffer overflow which can be exploited even further up to a RCE.
Here is a pseudo-code which we believe is similar to what is happening:
While exploiting the vulnerability is relatively simple, finding it in the ENIP stack is more challenging. There are many different ready-to-use ENIP stacks and being able to identify the exact same vulnerable stack is key in order to identify all affected devices. Inspired by the idea behind tools such as p0f, Claroty researchers developed a generic ENIP stack detection tool that classifies the ENIP stack of a remote device. Such a tool is necessary because there is no straightforward way to ask a device which ENIP stack it's using.
Claroty's tool performs behavioral profiling by breaking down the CIP/ENIP protocols to specific properties and attributes, which later creates a unique signature for the ENIP stack in use based on all the collected parameters. Supersetting all the unique implementation hints gives the true identity of the ENIP stack being used. A parameter can be any delicate attribute of the protocol and the implementation, for example, an attribute that determines whether a certain feature of the ENIP protocol is currently supported. Scanning two different devices that use the same core ENIP stack (e.g. an SDK purchased from the same vendor) will result with the same unique signature. This enabled Claroty researchers to identify various classes of ENIP stacks and group similar implementations of different ENIP stacks.
Next, Claroty researchers identified the unique signature generated by devices running RTA's ENIP stack. With that, they started to scan many ENIP-compatible devices in order to detect all potentially affected devices. Eventually, through this tool, Claroty researchers were able to scan 290 unique ENIP-compatible devices, which identified 32 unique ENIP stacks. Eleven devices were found to be running RTA's ENIP stack in products from six unique vendors. All of them have been contacted by RTA, the company said.
Protocol stacks such as RTA's ENIP stack include numerous features, many of which are included in order to comply with an International Standards Organization (ISO) requirement, or as competitive differentiators. Many of these features, however, are not used because the vendor distributing the stack often does not expose the feature in a simple way and the client isn't given the ability to use it.
This vulnerability was found in a RTA ENIP stack feature that's not commonly used, which is likely the reason the vulnerability has lingered since the early 2000s.
RTA has identified that this vulnerability was indeed removed in a 2012 code update. However, since many times vendors make a one-time purchase of protocol stacks such as RTA ENIP via an SDK or hardware implementation without buying an additional support package, integrations prior to then may be still vulnerable since they have not been updated.
This does raise some issues that vendors in the ICS and operational technology spaces may need to consider, in particular around the security of third-party software libraries and SDKs. These components may find themselves integrated across the spectrum of ICS and OT devices, many of which may not be replaced for decades. As more independent researchers and vendors—and threat actors—begin examining these libraries for vulnerabilities, questions are going to bubble to the surface about the responsibilities of the vendors supporting them to provide security updates for firmware and software. Should these stacks, such as RTA's ENIP which has been sold since the early 2000s, for example, be updated and patched regardless of support contracts in place? As OT and ICS security continues to grow as a top-of-mind concern for national security and critical infrastructure security, these are questions that are going to have to be considered.
Another question to ponder is the responsibility of vendors once they are aware of such a vulnerability. Analyzing an entire product line to determine how it is affected by a disclosed vulnerability is an expensive process. It's not enough to know that a certain firmware is using a specific third-party library to determine that the device is affected. Usually there are some implementation nuances that affect the likelihood of the firmware being at risk. From our experience, once a vendor is aware of such a vulnerability, they immediately check their product lines manually by running the proof-of-concept exploit we provide against all the devices in their lab. This requires hours of labor from analysts and engineers. And the question then remains: should vendors publish the third-party libraries they are using to understand what devices might be vulnerable? Doing so would ease the process for asset owners to calculate the true risk, and for the vendor.
In the meantime, industrial control system vendors are advised to investigate their RTA ENIP implementations and update to current versions.
CVE-2020-25159 Related CWE-121: Stack-based buffer overflowReal Time Automation (RTA) EtherNet/IP TCP/IP stack, all versions prior to 2.28, are vulnerable to a stack-based buffer overflow, which may allow an attacker to send a specially crafted packet that may result in a denial-of-service condition or code execution. Operators should update to current versions of the ENIP stack.
In light of recent third-party vulnerabilities cases and based on our new findings, we would like to offer a few questions for readers to ponder:
Should vendors of third-party libraries offer security updates to their customers regardless of support contracts in place (think of the case with Windows XP)?
Should vendors publish the third-party libraries they are using in their software/firmware?
STACK-BASED BUFFER OVERFLOW CWE-121
The affected product is vulnerable to a stack-based buffer overflow, which may allow an attacker to send a specially crafted packet that may result in a denial-of-service condition or code execution.
Read more: Lingering RTA ENIP Stack Vulnerability Poses Risk to ICS Devices
CVSS v3: 9.8
