Critical Bugs in EtherNet/IP stack expose Industrial systems to DoS, data leaks, and RCE Attacks
The OpENer EtherNet/IP stack implements the ENIP and CIP protocols that run in many commercial products. This is very popular among the significant SCADA vendors that use it to find security vulnerabilities before threat actors can exploit them. The Claroty Research Team has researched this as below:
Fuzz testing code:
Fuzz-testing code is the easiest and automated way to find coding errors and potentially critical flaws. However, integrating a fuzzer can be a challenge in an open-source implementation requiring substantial development efforts. Still, the Claroty Research team announces that it has added the necessary infrastructure to incorporate the popular AFL fuzzer into the OpENer EtherNet/IP stack.
What is Fuzz?
A Fuzz-testing tool is an automated program that uses invalid or random data as structured software inputs and monitors outputs for crashes or exploitable vulnerabilities.
Here, the OpENer is modified. All the necessary boilerplate code is added to help integrate the popular AFL (American Fuzzy Lop) fuzzer into the OpENer stack. AFL uses runtime guided techniques to create input for the tested program. Anyone today who wants to run it, can compile the updated OpENer EtherNet/IP stack code and immediately start fuzzing it without any changes.
There are five disclosed vulnerabilities depending on the architecture of the targeted device, which could lead to denial-of-service conditions, memory leaks from the stack, and remote code execution. An attacker would only need to send crafted ENIP/CIP packets to the device to exploit these vulnerabilities.
CVE-2021-27478: Incorrect Conversion between Numeric Types (CWE-681)
A forward-open request is a CIP request 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. When sending a forward-open request, the client must specify the connection CIP path to establish communication.
A bug is seen here during the forward-open CIP connection path parsing mechanism. The ParesConnectionPath function extracts the length of the connection path from the packet and then parses all the following bytes of the connection path. However, the connection path length is removed from the packet using the GetSintFromMessage function, even though lengths should always be treated as unsigned integers.
CVE-2020-13556: Out-of-Bounds Write (CWE-787) (Disclosed by Cisco Talos in December 2020)
ENIP packets contain a list of items. Upon receiving an ENIP packet, OpENer will extract the number of items (item count) embedded in the packet. However, besides an assert statement, there are no checks on the amount of supplied ENIP item count. so, on production systems where an OpENer is compiled in release mode, attackers will be able to provide a large item count number that will later cause a stack buffer overflow.
CVE-2021-27482: Out-of-bounds Read (CWE-125)
The common_packet_format_data variable points to a buffer of 512 bytes in length. In addition, there are no checks on the bytes read from the provided packet. This means that if we send a packet of 512 bytes, and force OpENer to process 3 items count, the reading bytes will be out-of-bound and we will be able to read random bytes from the stack.
CVE-2021-27500: Reachable Assertion
CWE-617 Reachable Assertion
CVSS v3 score: 7.5
An attacker sending crafted packets to vulnerable devices may result in denial-of-service conditions.