Logix PLC Vulnerability: What You Need To Know and What to Do Now
4 min read
News recently broke that Logix brand programmable logic controllers (PLCs) from Rockwell Automation have a hard-coded security vulnerability with a critical severity score of 10 out of 10. Essentially, this vulnerability leaves a secret remote-access key open for exploitation, allowing a hacker who obtains it to mimic an engineering workstation and manipulate code or configurations that directly impacts manufacturing.
Even just looking at the recent hack of a Florida water plant that nearly poisoned a municipal water supply, it’s irrefutable that organizations need to take these concerns seriously. If a bad actor were able to remotely access a PLC, the consequences can be just as dire.
However, for a variety of reasons that we recently covered in an article on enabling remote access to plant equipment, manufacturers often rely on systems integrators, such as Outlier, to remotely support their automation equipment. We covered some security best practices in that article, but, in light of these recent developments, knew we had to revisit the topic.
If this has been weighing heavily on your mind, then you’re not alone. But we do have some good news. By understanding what we’re fighting against and by taking the appropriate countermeasures, we can find a solution that continues to enable remote support while simultaneously mitigating the risk of this vulnerability.
So let’s dive in.
What’s the Vulnerability?
Dubbed CVE-2021-22681, the vulnerability advisory was released by the Cybersecurity and Infrastructure Security Agency (CISA) on February 25, 2021. In their risk evaluation, the agency explains, “Successful exploitation of this vulnerability could allow a remote unauthenticated attacker to bypass the verification mechanism and connect with Logix controllers. Additionally, this vulnerability could enable an unauthorized third-party tool to alter the controller’s configuration and/or application code.”
According to Claroty, the research firm that discovered the vulnerability, “The vulnerability lies in the fact that the Studio 5000 Logix Designer software may allow a secret cryptographic key to be discovered. This key is used to verify communication between Rockwell Logix controllers and their engineering stations.”
The following Rockwell software is affected:
RSLogix 5000: Versions 16 through 20
Studio 5000 Logix Designer: Versions 21 and later
And these Rockwell Logix Controllers are affected:
CompactLogix 1768
CompactLogix 1769
CompactLogix 5370
CompactLogix 5380
CompactLogix 5480
ControlLogix 5550
ControlLogix 5560
ControlLogix 5570
ControlLogix 5580
DriveLogix 5560
DriveLogix 5730
DriveLogix 1794-L34
Compact GuardLogix 5370
Compact GuardLogix 5380
GuardLogix 5570
GuardLogix 5580
SoftLogix 5800
How Do We Defend Against It?
At the time of writing in March 2021, Rockwell Automation has not yet released a patch for this vulnerability. We’re certainly going to keep an eye on this, and we recommend patching when it becomes available.
In the meantime, one defense-in-depth practice that’s a cornerstone tactic is segmenting the network into different levels and routing traffic through firewalls at the way-points between them. For instance, a network architecture should employ the principles of the following basic topology.
The enterprise network, our standard IT infrastructure, connects to the internet through one firewall and to the plant floor through a different one. In fact, traffic that flows to and from a desktop computer in the enterprise network and a PLC on the factory floor should often go through multiple layers of firewalls, including through an Industrial Demilitarized Zone (IDMZ). The takeaway here is that there’s multiple checkpoints between the vulnerable PLC and the internet.
Under no circumstances should we ever directly expose a PLC to the internet. This is the single most important thing that we can do to protect against this vulnerability.
Another mitigation that CISA recommends is switching all affected PLCs from “remote run mode” to “run mode.” Essentially, this makes it so the PLC can only execute code, meaning we can’t read or write to it. Since this requires a person to physically flip a switch on the machine, it protects against changes being made without our awareness.
Lastly, we have Common Industrial Protocol (CIP) Security, a standard communication method for secure data transport across an EtherNet/IP network. This security layer is on the plant floor’s network level itself, and it’s main feature is using TLS and DTLS for end-point authentication, much like we use HTTPS for secure transactions over the internet. This is a tool for rejecting data that has been altered, rejected messages sent by untrusted users or devices, and rejecting messages that request non-permitted actions.
Conclusion
Implementing these security measures will minimize the risk of exploitation of this vulnerability while still leaving open the possibility of remote support. Although it may require a more sophisticated network architecture and the occasional technician flipping the switch on a PLC to put it temporarily into remote run mode, it’s worth it.
One solution for remote support is to use a Virtual Private Network (VPN) that lets us log into your enterprise network. Once we have access to your intranet, we can then move through a more rigid authorization and access control process to access the industrial control equipment. Remember, we should never log into a PLC directly from the internet.
The final piece of the puzzle here is monitoring. Make sure you’re keeping track of what’s happening with your automation equipment, and implement a system to detect changes or to flag an intruder if they do get in.
Setting up these measures may be complicated, but Outlier is here to help. Our partners trust us with both remote support for their PLCs and integrating the systems to make that happen in a secure way. If you’re ready to add an extra layer of defense to your industrial control systems, contact us today.