Intro to Common Industrial Protocol Exploitation

Intro to Common Industrial Protocol Exploitation

Speakers: Trevor Flynn

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=S7mPcEPaKHU

Overview

Trevor Flynn's DEF CON talk, "Intro to Common Industrial Protocol Exploitation," provides a foundational yet detailed exploration into the Common Industrial Protocol (CIP), a cornerstone communication standard for industrial control systems (ICS). The presentation demystifies CIP, explaining its architecture, object-oriented nature, and unique networking capabilities, particularly its routing mechanisms that can traverse disparate network types. Beyond the theoretical, Flynn delves into practical methodologies for discovering vulnerabilities in CIP-enabled devices, primarily through fuzzing.

This talk is crucial for anyone involved in the security of operational technology (OT) environments. It highlights the inherent security challenges within legacy industrial protocols, such as the lack of authentication for critical configuration changes and the ease with which operational disruption can be caused. By demonstrating how to identify and understand these vulnerabilities in a lab setting, Flynn empowers security professionals to develop more robust defensive strategies, ensuring the safety and reliability of critical infrastructure.

Background

▶ Watch: Introduction to Common Industrial Protocol (CIP) (0:00)

Common Industrial Protocol (CIP) is a robust communications protocol integral to a wide array of industrial devices, including Programmable Logic Controllers (PLCs), Variable Frequency Drives (VFDs), motor starters, power monitoring systems, and smart sensors. It enables these devices to exchange data and coordinate operations within an industrial plant. Unlike typical network protocols confined to a single physical layer, CIP extends across various industrial network technologies.

CIP's lineage traces back to Allen-Bradley, a prominent industrial hardware manufacturer. Its first implementation, DeviceNet, was unveiled in Chicago in 1994, revolutionizing plant floor data exchange with a CAN-bus based system. This allowed for more flexible installations and smarter devices compared to the primitive, independent PLC systems and slow serial communications that preceded it. In 1997, ControlNet emerged, a coaxial-based network adhering to the 802.3B specification for its physical layer, utilizing Manchester signaling. The year 2000 saw the introduction of EtherNet/IP, the Ethernet adaptation of CIP. It leverages both UDP and TCP for transport, supporting unicast and multicast communications, and is distinct from the general TCP/IP suite.

The CIP stack is layered, sitting atop TCP and UDP. It incorporates its own encapsulation protocol (EtherNet/IP itself) and supports two primary messaging types: implicit messaging, which involves continuous data streams, and explicit messaging, characterized by single request-response transactions. A unique aspect of CIP is its network and transport layer, which predates widespread Ethernet adoption in industrial settings. Consequently, CIP developed its own mechanisms for functionalities typically handled by Ethernet, such as routing and CRC checks. This means that even when operating over Ethernet, CIP can utilize its internal routing capabilities, often in conjunction with TCP routing. The uppermost layer consists of application objects and device profiles, which are essentially C++ objects embedded in device firmware, providing the core functionality that CIP interacts with.

CIP operates much like a remote procedure call (RPC) protocol, where functionality is exposed through a structured object model. Each CIP object in a device's firmware is identified by a unique Class ID, which references its C++ class. Specific instances of these classes are denoted by Instance IDs. Within these instances, attributes represent variables, and services are the functions that can be invoked over the network. All these components—class, instance, attribute, and service—are addressed using integer-based identifiers, not human-readable strings. When a CIP request is sent (e.g., to activate a pump), it specifies the service to be executed, the class and instance it operates on, and potentially the attribute it modifies.

A fundamental example is the Identity Class, which always has Class ID 1 and a default Instance ID of 1. It supports Service 1, "Get All Attributes," often referred to as the "WHO" message. This simple request retrieves essential device information such as vendor, product type, firmware revision, device status (running, faulted, configuration mode), serial number, and product name. This demonstrates how CIP objects, with their defined services, provide access to device data and control functions. While a core specification outlines mandatory and optional objects, vendors often implement custom objects, making discovery challenging without detailed documentation.

To interact with these CIP objects, three forms of explicit communication are used:

1. UCMM (Unconnected Message Manager): This is the simplest form, akin to a UDP request. It sends a CIP request without establishing a dedicated CIP session or utilizing CIP routing mechanisms.
2. Unconnected Messaging: This involves creating a temporary CIP session and leveraging CIP's full routing capabilities for a single request. After the request and response, the session is automatically torn down.
3. Connected Sessions: Similar to unconnected messaging, but the CIP session remains open and persistent, allowing for multiple requests to reuse the established routed path and network infrastructure. Crucially, a CIP session is independent of its underlying TCP session; the CIP session can persist even if the TCP connection is temporarily broken and re-established.

CIP routing is a particularly fascinating and critical aspect. It enables commands to traverse complex, multi-network topologies, effectively bridging what might appear as air-gapped networks from a traditional IP perspective. A CIP path can specify routing through different Ethernet IP addresses, backplanes, module slots, and even entirely different network types like ControlNet. For example, a request could originate on one Ethernet/IP network, route through an Ethernet card to its backplane, target a specific slot, then transition to a ControlNet network via a module's ControlNet port, pass through an HMI, switch to a redundant Ethernet connection, and finally reach another PLC on a completely different Ethernet segment. This capability highlights significant security implications, as devices can communicate and be controlled across seemingly isolated network boundaries without traditional network segmentation being an effective barrier.

Key Findings

▶ Watch: History and Architecture of Ethernet/IP (2:00)

Trevor Flynn's talk reveals several critical findings regarding the security posture of Common Industrial Protocol (CIP) devices, particularly concerning their susceptibility to unauthenticated access and operational disruption.

Firstly, a core finding is that CIP devices expose their internal C++ objects and associated functions over the network. These objects, which govern device functionality and data storage, are often undocumented by vendors, necessitating discovery through adversarial techniques. This lack of transparency forces security researchers to reverse-engineer device capabilities.

Secondly, fuzzing emerges as a primary and highly effective method for discovering these hidden objects, their attributes, and the services they support. By systematically sending targeted random values for Class IDs, Instance IDs, Attribute IDs, and Service Codes, researchers can map out the device's internal object model. The talk demonstrates how even basic fuzzing, like querying Service 3 (Get Attribute List) on various Class IDs, can reveal the existence of objects and their supported services.

A significant vulnerability uncovered through such discovery is the unauthenticated remote modification of critical device parameters. The Ethernet TCP/IP object (Class 0xA), which stores network configurations like IP address, MAC address, and diagnostic counters, is often exposed via CIP. Flynn highlights that the CIP specification for this object allows for services that can remotely change a device's IP address, gateway, and subnet mask without any authentication mechanism. This means an attacker on the network can unilaterally reconfigure a device's network identity, causing denial of service or redirecting traffic.

Perhaps the most immediately impactful finding is the ease with which Major Non-Recoverable Faults (Manurfs) can be triggered in Rockwell Allen-Bradley controllers. A Manurf causes the device to halt execution, dump its entire configuration from memory, and essentially become a "dumb dead box." This is dangerous because it stops critical industrial processes, potentially leading to catastrophic consequences for human safety, the environment, or physical infrastructure. Flynn notes that these faults often result from integrity checks failing after a device receives unexpected input, such as a malformed CIP request or an unsupported service ID during fuzzing. He states that he can "find on average three manurfs a day" when fuzzing, underscoring the prevalence and ease of triggering these critical failures.

In summary, the key findings illustrate that CIP's architectural design, coupled with common vendor implementations, creates a landscape where internal device logic is discoverable, critical configurations are modifiable without authentication, and operational stability is easily compromised, posing severe risks to industrial operations.

Technical Deep Dive

▶ Watch: Understanding CIP Objects: Classes, Instances, Services (4:00)

The technical foundation of CIP exploitation lies in understanding its object-oriented architecture and unique networking capabilities. As discussed, CIP objects are the building blocks, each defined by a Class ID, representing a C++ class in the device firmware. Each class can have multiple Instance IDs, which are specific instantiations of that class. Within an instance, attributes are variables that store data, and services are functions that can be invoked remotely to perform actions or retrieve information. All these identifiers are integer-based, making them ideal targets for systematic enumeration and fuzzing.

A practical example is the Identity Class (Class ID 1), which has a default Instance ID 1. Its most common service is Service 1, "Get All Attributes," forming the essential "WHO" message. Sending this 1-1-1 request to a CIP device yields a wealth of information, as demonstrated in the talk with a JSON payload output:

• vendor: e.g., "Rockwell Automation"
• product_type: e.g., "PLC"
• firmware_revision: e.g., "20.01"
• device_status: e.g., "Running," "Faulted," "Configuration Mode"
• serial_number: Unique identifier
• product_name: e.g., "CompactLogix L32E"

This initial "WHO" message is often the first step in device reconnaissance, providing crucial context for further exploitation.

The talk highlights three forms of explicit communication used to interact with CIP objects:

1. UCMM (Unconnected Message Manager): This is for simple, sessionless requests, akin to UDP. It's used when no CIP routing or persistent session is needed, making it the most straightforward method for single transactions.
2. Unconnected Messaging: This establishes a temporary CIP session and utilizes CIP's internal routing mechanisms for a single request. Once the response is received, the session is terminated. This is suitable for requests that require routing but don't warrant an ongoing connection.
3. Connected Sessions: This maintains a persistent CIP session, allowing multiple requests to leverage the same established route and network infrastructure. A key technical detail is that a CIP session is entirely independent of its underlying TCP session. If the TCP connection drops and re-establishes, the CIP session can persist, showcasing an additional layer of abstraction and state management within the protocol.

The most technically profound aspect of CIP, from a security perspective, is its routing capability. CIP paths allow commands to traverse highly complex, multi-segment industrial networks. Consider the example provided:

IP:10.0.1.10,1,10,2,4,3,IP:192.168.1.1,1,5

This path describes a journey:

1. Target 10.0.1.10 (an Ethernet/IP device).
2. Go out port 1 (to the device's backplane).
3. Go to slot 10 (a specific module in the chassis).
4. Go out port 2 (a ControlNet port on that module).
5. On the ControlNet network, go to node 4 (an HMI).
6. Go out port 3 (a redundant Ethernet connection on the HMI).
7. On the new Ethernet network, target 192.168.1.1 (another PLC's Ethernet card).
8. Go out port 1 (to its backplane).
9. Go to slot 5 (a specific module in that PLC's chassis).

This single CIP request effectively traverses two distinct Ethernet networks, a ControlNet network, and three intermediary devices, bypassing what might appear as air-gapped or logically segmented network boundaries. This is possible because all these devices understand and forward CIP routing instructions, treating them as part of the application layer logic rather than network layer segmentation.

Fuzzing is presented as the go-to technique for discovering hidden objects and vulnerabilities. The methodology involves sending targeted random values for Class IDs, Instance IDs, Attribute IDs, and Service Codes. A Python script example demonstrates fuzzing Service 03 ("Get Attribute List") against Class IDs from 1 to 1000, Instance 0 (singleton instance), and Attribute 0 (null attribute).

The output of such a script might show:

• "Destination unknown," "Class unsupported," "Instance unsupported": These indicate no object exists at that address.
• "Service not supported": This is a significant finding. It means an object does exist (e.g., Class 0xA1 in the example), but it doesn't support the queried service. This knowledge allows an attacker to pivot, trying other service codes against this known object to map its capabilities.
• A successful response: Indicates a valid object and service, providing valuable data.

A critical example from fuzzing is the discovery of the Ethernet TCP/IP object (Class 0xA). While it might return "service not supported" for "Get Attribute List," knowing its existence allows a researcher to consult the CIP specification for Class 0xA. This reveals services that, for instance, allow remote modification of the device's IP address, subnet mask, and gateway. Crucially, these services often lack any authentication requirement, meaning a malicious actor can reconfigure a critical device's network settings with a simple, unauthenticated CIP command.

Finally, the concept of a Major Non-Recoverable Fault (Manurf) is technically explained. These faults often occur when a device's internal integrity checks fail, typically due to unexpected input that causes a buffer overflow or an invalid code execution path. When fuzzing, sending malformed or out-of-spec CIP requests can trigger these conditions, causing the PLC to halt execution and wipe its configuration. This is not a typical software crash but a safety mechanism, albeit one that can be weaponized to cause severe operational disruption. The high frequency of finding Manurfs during fuzzing (three per day, according to Flynn) underscores the fragility of these devices when subjected to unexpected inputs.

Demo / Proof of Concept

▶ Watch: Identity Class Example: The 'Who' Message (6:00)

While Trevor Flynn's talk did not feature a live, real-time demonstration of exploiting critical infrastructure due to the inherent dangers, it effectively served as a detailed proof-of-concept through code examples, output snippets, and thorough explanations of the methodologies. The core "demo" was the presentation of a Python fuzzing script designed to discover CIP objects and their services.

The speaker displayed a snippet of this Python script, illustrating how it iterates through a range of Class IDs (e.g., 1 to 1000) and attempts to invoke a specific service (Service 03, "Get Attribute List") on the singleton instance (Instance 0) with a null attribute (Attribute 0). This code clearly outlined the systematic approach to probing devices for exposed functionality.

Following the script, Flynn presented an output snippet from its execution. This output visually demonstrated the typical responses encountered during fuzzing: numerous "Destination unknown," "Class unsupported," or "Instance unsupported" messages, indicating non-existent objects, alongside critical "Service not supported" messages. These "Service not supported" responses, highlighted in red boxes in the presentation, were crucial as they confirmed the presence of an object, even if the specific queried service wasn't supported. This effectively demonstrated how initial fuzzing helps identify potential targets for further investigation.

Beyond the fuzzing output, Flynn verbally walked through the implications of discovering specific objects, such as the Ethernet TCP/IP object (Class 0xA). He explained that once this object is identified, its specification can be consulted to reveal services that allow unauthenticated remote modification of network parameters like IP address, subnet mask, and gateway. Although not executed live, he explicitly stated, "You can modify this script right here to go change the IP address of this device. Just like that and the device would have a new IP address," serving as a powerful verbal proof-of-concept for a critical vulnerability.

Similarly, the concept of triggering a Major Non-Recoverable Fault (Manurf) was detailed as a consequence of fuzzing. While no Manurf was intentionally triggered during the live presentation for safety reasons, the mechanism (input validation failures leading to integrity checks failing) and its severe operational impact (halting execution, wiping configuration) were thoroughly explained, serving as a conceptual demonstration of a critical denial-of-service vulnerability.

In essence, the talk provided a highly practical and actionable "how-to" guide, using code, example outputs, and clear technical explanations to illustrate the proof-of-concept for discovering and understanding CIP vulnerabilities, all while adhering to the critical safety guidelines for industrial systems.

Defensive Implications

▶ Watch: Explicit Communication: Unconnected Message Manager (UCMM) (8:00)

The revelations from Trevor Flynn's talk underscore the urgent need for a robust and multi-layered defense strategy within industrial control system (ICS) and operational technology (OT) environments. The inherent design of CIP, particularly its routing capabilities and lack of pervasive authentication, presents significant challenges for defenders.

Firstly, the ability of CIP routing to traverse disparate network types and devices effectively bypasses traditional network segmentation strategies that rely solely on IP-level separation or "air-gapping." Defenders must understand that logical air gaps are often permeable to CIP. This necessitates a shift towards deep packet inspection (DPI) for CIP traffic, not just IP addresses and ports. Industrial firewalls and intrusion detection systems (IDS) should be configured to analyze CIP commands and object interactions, identifying unusual or unauthorized service calls and routing paths.

The demonstrated vulnerability of unauthenticated remote configuration changes (e.g., IP address modification via the Ethernet TCP/IP object) is a critical concern. Defenders must assess their CIP-enabled devices for this specific vulnerability. Where possible, disable unnecessary CIP objects or services that allow unauthenticated configuration. If disabling is not an option, implement compensating controls such as strict network access controls (NAC) to limit who can communicate with these devices, and continuous monitoring for any changes to critical device parameters. Any change to a device's IP address or network configuration should trigger an immediate alert and investigation.

The ease with which Major Non-Recoverable Faults (Manurfs) can be triggered highlights a critical denial-of-service (DoS) vector. While preventing all fuzzing attempts might be challenging, defenders should prioritize patching and firmware updates to address known vulnerabilities that lead to Manurfs. Furthermore, robust input validation at the device level is essential, though often outside the direct control of the end-user. From an architectural standpoint, redundancy and fail-safe designs are paramount. PLCs controlling critical processes should be paired with redundant systems, and mechanical/electrical fail-safes (e.g., pressure relief valves, emergency stops) must be in place and regularly tested to ensure that a controller failure does not lead to catastrophic physical outcomes.

Vulnerability management for OT assets needs to be proactive. Organizations should establish dedicated cyber ranges or lab environments to safely fuzz and test their specific models of CIP devices. This allows for discovery of device-specific vulnerabilities without risking live production systems. Findings should be responsibly disclosed to vendors, often facilitated by organizations like CISA, to ensure patches are developed and distributed.

Finally, situational awareness and continuous monitoring are crucial. Tools like Wireshark, with its excellent CIP plugin, are indispensable for network visibility, allowing defenders to inspect CIP traffic, understand normal behavior, and detect anomalies. Any unexpected or unauthorized CIP requests, especially those targeting configuration objects or attempting to invoke a wide range of services, should be flagged as suspicious. Training for OT engineers and security personnel on the intricacies of CIP and its security implications is also vital to build internal expertise and improve incident response capabilities.

Key Takeaways

• CIP is a complex, object-oriented protocol extending beyond traditional Ethernet networks, incorporating its own routing and session management mechanisms independent of TCP/IP.
• CIP's unique routing capabilities enable commands to traverse multiple network types and devices, effectively bypassing perceived "air-gapped" or segmented networks from a traditional IT perspective.
• Fuzzing is a highly effective methodology for discovering undocumented CIP objects, attributes, and services within industrial devices, revealing hidden functionalities and potential vulnerabilities.
• Many CIP-enabled devices allow unauthenticated remote modification of critical network parameters (e.g., IP address, subnet mask) via standard objects like the Ethernet TCP/IP object (Class 0xA), posing a significant configuration tampering risk.
• Major Non-Recoverable Faults (Manurfs) are easily triggered vulnerabilities in many CIP devices, causing them to halt execution and wipe their configuration, leading to severe operational disruption and potential safety/environmental hazards.
• Defensive strategies must include deep packet inspection, strict access controls, robust vulnerability management through lab testing, and responsible disclosure to mitigate the unique security challenges posed by CIP.

About the Speaker(s)

Trevor Flynn is an expert in industrial control system (ICS) and operational technology (OT) security, with a deep understanding of common industrial protocols like CIP. His presentation at DEF CON demonstrates his practical experience in identifying and exploiting vulnerabilities in critical infrastructure devices. Flynn's insights are geared towards educating the security community on the unique challenges and methodologies involved in securing these vital systems, emphasizing responsible research and the importance of protecting human life, the environment, and physical infrastructure. His work contributes to enhancing the defensive posture of industrial environments against cyber threats.