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.
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"
An exposure of sensitive information to an unauthorized actor vulnerability in cgi component in Synology Router Manager (SRM) before 1.3.1-9346-6 allows remote attackers to obtain sensitive information via unspecified vectors.
This vulnerability allows remote attackers to disclose sensitive information on affected installations of Synology RT6600ax routers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the info.cgi file. The issue results from the exposure of sensitive data to the WAN interface. An attacker can leverage this vulnerability to disclose certain information in the context of the current process.
CVSS V3: 5.3
An improper limitation of a pathname to a restricted directory ('Path Traversal') vulnerability in cgi component in Synology Router Manager (SRM) before 1.3.1-9346-6 allows remote attackers to read specific files via unspecified vectors.
This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of Synology RT6600ax routers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the uistrings.cgi file. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to disclose information in the context of the current process.
CVSS V3: 5.3
An improper neutralization of special elements used in an OS command ('OS Command Injection') vulnerability in Directory Domain Functionality in Synology Router Manager (SRM) before 1.3.1-9346-6 allows remote authenticated users to execute arbitrary commands via unspecified vectors.
This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Synology RT6600ax routers. Authentication is required to exploit this vulnerability.
The specific flaw exists within the WEB API endpoint. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root.
CVSS V3: 7.2
An uncontrolled resource consumption vulnerability in File Functionality in Synology Router Manager (SRM) before 1.3.1-9346-6 allows remote authenticated users to conduct denial-of-service attacks via unspecified vectors.
This vulnerability allows network-adjacent attackers to create a denial-of-service condition on affected installations of Synology RT6600ax routers. Authentication is required to exploit this vulnerability.
The specific flaw exists within the SYNO.Core file. The issue results from uncontrolled resource consumption. An attacker can leverage this vulnerability to create a denial-of-service condition on the device.
CVSS V3: 4.9
CWE-256: Plaintext Storage of a Password
The affected product stores usernames and passwords in plaintext. The plaintext storage could be abused by attackers to leak legitimate user’s credentials.
Softneta recommends users update to v22.214.171.1240 of MedDream PACS Server or patch their current system using Fix-v230712.
CVSS V3: 6.1