Team82 has released a freely available ENIP stack detection tool
Researchers, engineers, and asset operators may use the tool to identify and classify OT products using the same third-party ENIP stack code
This type of visibility identifies an organization's exposure to newly disclosed vulnerabilities, and allows for update prioritization
Our detection tool breaks down the ENIP and CIP protocols to specific properties and attributes
Doing so creates a unique signature for the ENIP stack in use
Team82 is releasing today a custom, generic EtherNet/IP stack detection tool that will be free and publicly available via our GitHub repository.
The tool fulfills a number of use cases for cybersecurity researchers, OT engineers, and asset owners by helping them to identify and classify commercial and homegrown products using the same third-party ENIP stack code. By identifying the ENIP stack, users inside the enterprise as well as vendors will be able to better understand their exposure to newly disclosed vulnerabilities, and subsequently prioritize updates.
Team82 has used the EtherNet/IP & CIP Stack Detector as the centerpiece of several ENIP-related research projects, including an important November 2020 disclosure of a stack-overflow vulnerability in Real Time Automation's (RTA) 499ES ENIP stack. Using the detection tool, Team82 researchers identified 11 devices sold by six different automation vendors that were built on top of the affected stack.
Following a second Team82 report published last April detailing five vulnerabilities discovered in the popular open source OpENer EtherNet/IP stack, we understood there was a clear gap for asset owners wishing to quickly triage what devices are affected once a critical ENIP stack vulnerability is identified and publicly disclosed.
This gap was especially flagrant with open source components such as OpENer; OpENer ENIP implements ENIP and CIP and is used by leading automation vendors in numerous commercial products. Users struggled because many products don't clearly describe or list the components being used in a commercial device, and that includes which protocol stacks are implemented. Situations such as this are also adding fuel to important discussions around the need for software bills of materials (SBOM), which further close that window of exposure users face when vulnerabilities are disclosed and/or are being publicly attacked (see section below, Can SBOMs Help?).
Team82's EtherNet/IP & CIP Stack Detector can be used for security research and as part of an internal investigation to quickly scan many devices to retrieve their EtherNet/IP protocol stack.
Users can also leverage this tool for:
Researchers may quickly deploy this tool to identify connected industrial devices and the ENIP stacks implemented on those devices for network communication and data transfer between devices and workstations. The tool would allow researchers to classify groups of devices running the same ENIP stack, and understand the scale of vulnerabilities and affected devices.
Asset owners, meanwhile, could run the tool to identify devices running an ENIP stack affected by a newly identified vulnerability. Too often, users are blind to the components running in commercial products and may be unaware of their exposure to critical bugs that have been disclosed. This complicates patch management decisions and could leave them vulnerable to publicly disclosed exploits, for example.
Our tool can significantly aid ICS honeypot creators to improve the stealthiness of their work in order to keep attackers from easily identifying a honeypot.
Honeypots are lures used by researchers and blue teams to ensnare attackers' traffic to study their tactics and techniques in order to fortify network defenses. ICS honeypots mimic devices such as internet-connected programmable logic controllers (PLCs), and Team82's tool can parse the protocol in use and help researchers separate legitimate traffic from honeypot traffic.
Let's look at one example for this unique use case: Conpot is a popular industrial control system honeypot that supports the ENIP/CIP ICS protocol (using the CPPPO protocol stack implementation). If we look at conpot's source code we can clearly see that a default ENIP serial number is being used: 0x006c061a.
Serial numbers are unique to each PLC, meaning that normally multiple PLCs should not have the same serial number. Yet, a Shodan search for this particular serial number, below, reveals that more than 340 connected PLCs have the same one. One can easily deduce that this is a ICS honeypot.
Playing this scenario out further, regardless of whether the serial number is changed to a random one, since our tool parses ENIP stack signatures, it can still determine whether this is honeypot traffic. Furthermore, if we can identify a perfectly "normal" honeypot, attackers can do the same. Therefore, honeypot creators can use our tool to classify their honeypots, improve them, and make it difficult for attackers to discern whether they've landed in a honeypot.
This tool performs behavioral profiling by breaking down the EtherNet/IP and CIP protocols to specific properties and attributes, which later creates a unique signature for the ENIP stack in use based on all the collected parameters. For example, the signature 0000010110100100000 identifies the CPPPO ENIP stack used by CONPOT.
Supersetting all the unique implementation hints reveals the 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 in the same unique signature.
Based on our research, we are collecting the following boolean flags during a scan:
ENIP Register Session Number Sequential (0x1, 0x10, 0x100, 0x1000, 0x10000)
ENIP Can Register Session with Bad Options (Used value: 1)
ENIP Can Register Session with Bad Length (Used value: 3)
ENIP Is List Targets Supported
ENIP List Services Protocol Version is 1
ENIP List Services Name ('Communications' variation)
ENIP List Services Name Capability Flags Reserved Bit Are Empty
CIP Forward Open is supported
CIP Forward Open allows multiple requests for connection id 0
CIP Forward Open is O2T Sequential by 1
CIP Forward Open is T2O zero
CIP Forward Open can open with bad connection flags
This tool enables Claroty's Team82 researchers to identify various classes of ENIP stacks and group similar stack implementations.
For example, Team82's researchers identified the unique signature generated by devices running RTA's ENIP stack. With that, Team82 started to scan many ENIP-compatible devices in order to detect all potentially affected devices.
Eventually through this tool, researchers were able to scan 290 unique ENIP-compatible devices, which revealed 32 unique ENIP stacks. Of the 290 unique devices scanned, 11 devices were found to be running RTA's ENIP stack in products from six unique vendors and appropriate actions were taken accordingly (disclosure process).
Much discussion is happening about software vendors providing a software bill of materials (SBOM). Within ICS, SBOMs are not commonplace, despite their potential importance in a number of areas, including vulnerability management.
SBOMs are analogous to ingredient labels on food products, or parts lists for toys and automobiles. They are a structured list of components such as libraries and modules required to compile and link software, and even the supply chain relationships between them. With an SBOM in hand, an organization can quickly see whether a vulnerable component is running in their environment and break through the black-box nature of some ICS and OT software packages or firmware installations.
This type of visibility into the components used to build commercial firmware or software products is vital for decision makers struggling to assess their risk in the event of an incident which would hamper response or vulnerability remediation.
The U.S. government, for one, has determined there is value in SBOMs. An executive order issued last year by the Biden administration included a section on supply chain security that included SBOMs among secure development practices as mandatory for each product purchased by the federal government. This is vital for buyers of commercial products who may not understand the exposure created by the inclusion of an open source component running under the hood.
Team82's EtherNet/IP & CIP Stack Detector, in the meantime, can be used to lessen that risk. Users are encouraged to download the tool, try it in their environments, and share their feedback with Team82 and the community.
The availability of the EtherNet/IP & CIP Stack Detector is the second open source contribution Team82 has made to improve the security of ENIP stack detection. Last April's research, which included the disclosure of five vulnerabilities in the ENIP stack, also featured the public availability of the necessary infrastructure and documentation to integrate the AFL fuzzer into the OpENer ENIP stack. Vendors and researchers may now invoke a fuzzer in a much simpler fashion and test their implementation. The onboarding process is simple enough for anyone, even users without a cybersecurity background, to use the fuzzer.
Read our report: "Fuzzing and PR'ing: How We Found Bugs in a Popular Third-Party EtherNet/IP Protocol Stack"
In late 2020, Team82 published details about a critical buffer overflow vulnerability in Real Time Automation's (RTA) proprietary 499ES EtherNEt/IP stack. Attackers could leverage this vulnerability to crash devices or, in some cases, remotely execute code. The vulnerability had been present in all versions of the stack up until v2.28, released in November 2012. This is a case where legacy third-party equipment, some of it purchased in the early 2000s, could be running this stack and vulnerable in the wild. Users struggling to understand what protocols are running in their environment could remain vulnerable to this and other similar vulnerabilities.
Read our report: "Lingering RTA ENIP Stack Vulnerability Poses Risk to ICS Devices"
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, a local attacker can escalate their privileges in the system which could allow for arbitrary code execution with root permissions.
Update to Access Commander version 3.2.
CVSS v3: 4.7
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, an Insufficient Verification of Data Authenticity vulnerability could allow an attacker to escalate their privileges and gain root access to the system.
Update to Access Commander version 3.2.
CVSS v3: 6.3
CWE-22 IMPROPER LIMITATION OF A PATHNAME TO A RESTRICTED DIRECTORY ('PATH TRAVERSAL'):
In 2N Access Commander versions 3.1.1.2 and prior, a Path Traversal vulnerability could allow an attacker to write files on the filesystem to achieve arbitrary remote code execution.
Update to Access Commander version 3.2.
CVSS v3: 7.2
CWE-290: AUTHENTICATION BYPASS BY SPOOFING
Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 7.5
CWE-306: MISSING AUTHENTICATION FOR CRITICAL FUNCTION
A vulnerability exists in Snap One OVRC cloud where an attacker can impersonate a Hub device and send requests to claim and unclaimed devices. The attacker only needs to provide the MAC address of the targeted device and can make a request to unclaim it from its original connection and make a request to claim it.
OvrC Pro: All versions prior to 7.3 are affected.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 9.1
