Posted on: October 12, 2024 | Reading time: 15 minutes | Word count: 3050 words | Author: Dang Duong Minh Nhat
In today’s interconnected world, the security of industrial control systems is paramount. During my time in the OPSWAT Fellowship Program, I had the opportunity to dive deep into the intricacies of a critical vulnerability, CVE-2021-22659, affecting Rockwell Automation’s MicroLogix 1400 PLC. This blog reflects my journey of researching, simulating an attack, and developing remediation strategies for this vulnerability. I would like to extend my heartfelt gratitude to my mentors, the dedicated OPSWAT team, and the leadership for their unwavering support and guidance, which made this enriching internship experience not only possible but profoundly impactful.
Table of Contents
- Table of Contents
- Securing Industrial Control Systems: The Importance of Protecting the MicroLogix 1400 PLC
- Understanding CVE-2021-22659: A Critical Vulnerability in the MicroLogix 1400
- The Phases of Attack: How Vulnerabilities Exploit the MicroLogix 1400 PLC
- Unpacking the Modbus Protocol: A Cornerstone of Industrial Communication
- Decoding Modbus Message Structure: The Backbone of Industrial Communication
- Unveiling the Vulnerability: Exploiting CVE-2021-22659
- Effective Remediation Strategies for CVE-2021-22659
- References
- Connect with Me
Securing Industrial Control Systems: The Importance of Protecting the MicroLogix 1400 PLC
In today’s digital landscape, securing industrial control systems (ICS) and operational technology (OT) environments from remote attacks is more crucial than ever. Vulnerabilities like CVE-2021-22659 pose serious risks, especially for widely used devices like Rockwell Automation’s MicroLogix 1400 Controller. A recent investigation by students from the OPSWAT Fellowship Program has shed light on this vulnerability, emphasizing the urgent need for robust security measures in these critical systems.
Understanding the MicroLogix 1400 PLC
To grasp the significance of this vulnerability, it’s essential to understand what a Programmable Logic Controller (PLC) is. A PLC is an industrial computer designed to automate processes by controlling machinery and industrial operations. Built to endure harsh environments, these devices are programmed to perform specific tasks based on sensor inputs.
The Rockwell Automation MicroLogix 1400 Controller stands out as a compact and modular PLC, widely adopted in small to medium-sized applications. Its cost-effectiveness and flexibility make it a popular choice for many industries. The MicroLogix 1400 supports various communication protocols and offers both digital and analog input/output options, allowing seamless interfacing with other devices.
Programming the MicroLogix 1400 is typically accomplished using Rockwell Automation’s software through ladder logic, a graphical programming language that enables users to create complex control sequences. Its versatility allows it to handle tasks ranging from machine control to process automation, while its modular design offers the ability to expand and customize the system based on specific application needs.
Understanding CVE-2021-22659: A Critical Vulnerability in the MicroLogix 1400
In January 2021, a significant security vulnerability was identified in Rockwell Automation’s MicroLogix 1400 controller, a widely used device in industrial control systems. This vulnerability, designated CVE-2021-22659, was reported by Parul Sindhwad and Dr. Faruk Kazi from the COE-CNDS at Veermata Jijabai Technological Institute (VJTI) in India. Their findings highlighted a critical flaw in version 21.6 and earlier, which poses serious risks for organizations relying on this technology.
What Is CVE-2021-22659?
Rockwell Automation MicroLogix 1400 Version 21.6 and below may allow a remote unauthenticated attacker to send a specially crafted Modbus packet allowing the attacker to retrieve or modify random values in the register. If successfully exploited, this may lead to a buffer overflow resulting in a denial-of-service condition. The FAULT LED will flash RED and communications may be lost. Recovery from denial-of-service condition requires the fault to be cleared by the user.
NVD evaluated this security vulnerability as High severity.
The Phases of Attack: How Vulnerabilities Exploit the MicroLogix 1400 PLC
The increasing interconnectivity of industrial control systems has unfortunately opened the door to malicious attacks. In the case of the MicroLogix 1400 PLC, vulnerabilities like CVE-2021-22659 create a pathway for remote, unauthenticated attackers to disrupt operations. Understanding the phases of such attacks is crucial for organizations to defend against them effectively.
Phase 1: Reconnaissance
The first phase of an attack typically involves reconnaissance. In this stage, an attacker seeks to gather information about the target system, including the specific version of the MicroLogix 1400 PLC in use and its network configurations. Tools like packet sniffers can help attackers identify active devices and their communication protocols. This phase lays the groundwork for the attack, as the attacker looks for weaknesses that can be exploited.
Phase 2: Exploitation
Once the attacker has gathered sufficient information, they move on to the exploitation phase. With network access to the vulnerable MicroLogix 1400 PLC, the attacker can send specially crafted Modbus packets. These packets can manipulate register values, enabling the attacker to write arbitrary data into the PLC’s memory. Since the Modbus protocol lacks authentication and encryption, the attacker can execute this step without needing any credentials.
This manipulation can lead to various adverse outcomes, such as altering critical control parameters or overriding safety functions. The impact of such changes can be catastrophic, especially in environments where safety and precision are paramount.
Phase 3: Denial of Service
The exploitation of the vulnerability can escalate into a denial-of-service (DoS) condition. If the attacker successfully sends a sufficient number of malformed packets, it can overwhelm the PLC’s processing capabilities, leading to a buffer overflow. As a result, the device may crash, and the FAULT LED will flash red, indicating that something has gone critically wrong.
This DoS condition doesn’t just cause the PLC to become unresponsive; it can halt entire manufacturing processes, leading to significant downtime. For businesses, this means interrupted operations, lost revenue, and potential damage to machinery—all of which can have long-lasting repercussions.
Phase 4: Impact and Recovery
The aftermath of such an attack can be profound. Beyond the immediate operational disruptions, organizations may face reputational damage, loss of customer trust, and potential regulatory penalties. Furthermore, recovery from a denial-of-service condition often requires manual intervention to clear faults and reset the PLC, further delaying operations.
Organizations must recognize the importance of swift response strategies in this phase. Implementing incident response plans that include monitoring systems for abnormal behavior and quickly isolating affected devices can mitigate the damage caused by such attacks.
Unpacking the Modbus Protocol: A Cornerstone of Industrial Communication
In the world of industrial automation, effective communication between devices is crucial for ensuring smooth operations. One of the most widely used communication protocols for this purpose is the Modbus protocol, developed by Modicon in 1979. Initially designed for Modicon’s PLCs, Modbus has evolved into a standard messaging structure that facilitates client-server communication among various intelligent devices in industrial settings.
What is Modbus?
At its core, Modbus is a protocol that allows different devices, such as sensors, actuators, and controllers, to communicate with one another. It defines a simple and efficient way for devices to exchange data, making it a popular choice in various industrial applications. The protocol’s ease of use and compatibility with a range of devices have contributed to its widespread adoption across the globe.
Types of Modbus Protocols
Modbus exists in several formats, primarily catering to different communication needs. The two main types are Modbus RTU and Modbus TCP, each suited for specific environments and requirements.
- Modbus RTU (Remote Terminal Unit):
- Communication Method: Modbus RTU uses serial communication to transmit data. It directly sends data in binary form, which makes it efficient for devices that communicate over serial lines.
- Use Case: This version is typically used in applications where devices are located relatively close to each other, such as in manufacturing plants or process automation systems. It operates effectively over RS-232 or RS-485 communication lines, supporting multiple devices on a single network.
- Modbus TCP (Transmission Control Protocol):
- Communication Method: Modbus TCP encapsulates Modbus protocol data into TCP packets, allowing it to be transmitted over standard Ethernet networks.
- Use Case: This version is ideal for modern industrial environments where devices are often distributed over larger distances and connected via TCP/IP networks. The use of Ethernet enables faster data transmission and greater network flexibility, making it easier to integrate with other IT infrastructure.
Decoding Modbus Message Structure: The Backbone of Industrial Communication
In the realm of industrial automation, the ability for devices to communicate effectively is paramount. At the heart of this communication lies the Modbus protocol, a robust request-response framework that allows devices to exchange vital information. Understanding how Modbus messages are structured can empower engineers and technicians to harness its full potential in their operations.
The Basics of Modbus Messaging
A Modbus communication session begins with a client device transmitting a request to a secondary Modbus device. This request contains essential information, prompting the secondary device to perform a specific action and respond accordingly. The simplicity of this request-response model is one of the reasons Modbus has become a staple in industrial environments.
Anatomy of a Modbus Message
Each Modbus message sent from a primary device to a secondary one contains several critical components:
- Address of the Secondary Device: This identifies which device the message is intended for, ensuring the correct recipient processes the request.
- Command: The command indicates the action the secondary device should perform, such as “read register” or “write register.” This functionality is crucial for the device to know how to respond.
- Data: This section holds the actual information that the command will operate on, whether it’s a value to be written or a request for data to be read.
- Checksum (LRC or CRC): To ensure data integrity, each message includes a checksum. This allows the receiving device to verify that the message has not been corrupted during transmission.
Data Types in Modbus
Modbus defines four primary data types, each serving a distinct purpose in the communication process:
- Coil: Read-write single-bit outputs, used for controlling devices like relays.
- Discrete Input: Read-only single-bit inputs, typically used for sensors that provide binary status (e.g., on/off).
- Input Register: Read-only 16-bit input registers, which hold numerical values that the PLC can read.
- Holding Register: Read-write 16-bit output registers, where numerical values can be stored and modified.
Each data type plays a vital role in the overall functionality of a Modbus network, allowing for a diverse range of applications.
Function Codes: The Key to Action
Modbus also employs function codes to specify the type of action being requested. These function codes fall into three categories:
- Public Function Codes: These range from 1 to 127 and are available for general use.
- User-Defined Function Codes: These are in two specific ranges (65-72 and 100-110) and allow users to implement custom functionalities.
- Reserved Function Codes: These are used by specific companies for legacy products and are not available for public use.
Some common function codes include:
- Read Discrete Inputs (Function Code 2): Requests the status of discrete inputs.
- Read Coils (Function Code 1): Allows the client to read the status of coils.
- Write Single Coil (Function Code 5): Enables the client to write a value to a single coil.
- Read Input Registers (Function Code 4): Requests data from input registers.
- Write Multiple Holding Registers (Function Code 16): Allows for writing values to multiple holding registers at once.
These function codes provide a structured way to request specific actions, making Modbus both versatile and efficient.
Unveiling the Vulnerability: Exploiting CVE-2021-22659
As the world becomes increasingly interconnected, the importance of securing industrial control systems has never been more critical. One glaring vulnerability, CVE-2021-22659, has put Rockwell Automation’s widely used MicroLogix 1400 PLC under scrutiny. Our analysis at OPSWAT has revealed how a lack of proper security measures can be exploited by attackers, posing serious risks to operational technology (OT) environments.
Understanding the Vulnerability
Through extensive analysis, my OPSWAT Graduate Fellowship team discovered that during Modbus TCP communication, the protocol does not implement authentication or encryption for the packets being transmitted. This oversight allows a remote attacker, armed with basic knowledge, to sniff network packets and send malicious requests to the PLC without any form of authentication.
The MicroLogix 1400 PLC further compounds this vulnerability with inadequate input validation. A malicious actor can flood the device with random values, overwhelming its capacity and potentially causing a crash. The implications of such an attack can be devastating, leading to unexpected downtime and operational disruptions.
The Process of Register Overwriting
To delve deeper into this vulnerability, we initially focused on capturing Modbus TCP packets responsible for reading and writing registers on the PLC. Utilizing an application called Modbus Poll, which facilitates interaction with the MicroLogix 1400, we analyzed the packets exchanged during typical operations.
By employing Wireshark, a powerful packet-sniffing tool, we identified the specific Modbus TCP packet format used for writing a single register.
With this knowledge, we crafted a simple Python script capable of sending TCP packets to the target PLC at IP address 192.168.93.89.
Upon executing this script, we were able to manipulate the PLC’s registers with malicious, unauthenticated packets, effectively overwriting crucial values.
In Micro Logix 1400, most math instructions use three parameters: Source A, Source B and Destination
The values for Source A and Source B can come from two 16-bit registers named N13:3 and N13:4. Furthermore, the values in these 16-bit registers, such as N13:3 and N13:4, are constrained within the range of -32,768 to +32,767. If the values of N13:3 and N13:4 are large, the result of the match instruction may exceed the data type’s maximum range, potentially causing the PLC to crash. Consequently, to induce a crash in the PLC, it is necessary to write large random values to all registers, including N13:3 and N13:4. To achieve this, we modified our Python script as follows:
Triggering a Crash: The Simulation
To simulate a real-world attack scenario, our team executed the script in the controlled environment of OPSWAT’s CIP Labs. We assumed that both the attacker and the PLC were on the same network, enabling direct communication.
Under normal circumstances, the MicroLogix 1400 PLC operates in REMOTE RUN mode, with all register values falling within their designated limits.
However, upon running our script, we bombarded the PLC with Modbus TCP packets requesting the writing of large, random values to all registers.
As anticipated, the values of the registers, including N13:3 and N13:4, were manipulated to exceed their maximum allowable range. Specifically, these registers were set to 16,990, leading to an integer overflow during an ADD operation. Since these registers are constrained to a 16-bit signed integer range of -32,768 to +32,767, the result exceeded the limit, triggering a fault condition.
The Result: System Crash
The outcome of our exploitation was successful; the MicroLogix 1400 PLC transitioned to a FAULTED state, indicating a complete interruption of its operational capabilities. This demonstration starkly illustrates the risks associated with vulnerabilities like CVE-2021-22659 and the potential for significant disruption in industrial settings.
Effective Remediation Strategies for CVE-2021-22659
In an era where vulnerabilities like CVE-2021-22659 threaten the integrity of operational technology (OT) and cyber-physical systems, implementing a robust remediation strategy is essential. Protecting these critical systems requires a proactive approach to detect, mitigate, and respond to potential attacks. Below are key strategies that organizations can employ to safeguard their MicroLogix 1400 PLCs and similar devices:
- Regular Vulnerability Scanning. The first line of defense against known vulnerabilities is to conduct regular scans of your network. By routinely checking for weaknesses like CVE-2021-22659, organizations can identify and remediate vulnerabilities before they can be exploited by malicious actors. Automated tools can help streamline this process, ensuring that no potential threats go unnoticed.
- Anomaly Detection and Behavior Monitoring. Monitoring for unusual behaviors within your network is critical. Any significant increase in communication frequency to the MicroLogix 1400 PLC could indicate an ongoing attack or unauthorized data transfer. Implementing systems that flag these anomalies allows organizations to act swiftly, potentially stopping an attack in its tracks before it escalates.
- Identifying New Device Connections. Keeping track of devices that connect to the PLC is vital for maintaining network integrity. Organizations should have mechanisms in place to detect any new connections, as unauthorized devices can serve as entry points for attackers. This proactive measure can significantly reduce the risk of external breaches.
- Network Segmentation. One of the most effective strategies for containing potential threats is network segmentation. By isolating affected devices, organizations can limit the lateral spread of attacks, minimizing the overall impact. Segmenting networks not only enhances security but also makes it easier to manage and monitor individual sections of the system.
Leveraging MetaDefender OT Security
To address these critical needs, OPSWAT’s MetaDefender OT Security offers comprehensive solutions tailored for industrial environments. This powerful toolset not only detects known CVEs but also continuously monitors network activity for unusual behaviors. By identifying unauthorized connections, it ensures that your systems remain secure.
Using advanced AI algorithms, MetaDefender learns normal traffic patterns over time, establishing a baseline of expected behavior. This intelligent system can swiftly detect anomalies, allowing for instant and informed responses to potential threats.
In the event of an attack exploiting CVE-2021-22659, MetaDefender OT Security integrates seamlessly with the MetaDefender Industrial Firewall. This partnership allows for the immediate blocking of suspicious communications based on predefined rules. The firewall, equipped with AI capabilities, adapts to regular traffic patterns and enforces policies that prevent unauthorized connections.
The Ideal Defense Mechanism
By combining detection, alerting, and network segmentation, MetaDefender OT Security emerges as the ideal defense mechanism for industrial environments. It significantly reduces the risk and impact of cyber threats, ensuring that organizations can focus on their core operations without the looming fear of vulnerabilities.
In a landscape where the stakes are high, adopting a multi-faceted approach to security is not just advisable—it’s essential. With the right strategies in place, organizations can confidently navigate the complexities of the digital world, protecting their critical systems from potential exploitation.
References
- OPSWAT. (2024, October 3). Protecting OT Systems from Remote Attacks: How MetaDefender OT Security™ Protects the Micrologix™ 1400 Controller from CVE-2021-22659. Retrieved from https://www.opswat.com/blog/protecting-ot-systems-from-remote-attacks-how-metadefender-ot-securitytm-protects-the-micrologixtm-1400-controller-from-cve-2021-22659
- CVE-2021-22659 Detail. National Institute of Standards and Technology. Retrieved from https://nvd.nist.gov/vuln/detail/CVE-2021-22659
Connect with Me
Connect with me on Facebook, LinkedIn, via email at dangduongminhnhat2003@gmail.com, GitHub, or by phone at +84829258815.