A security vendor’s recent analysis of Rockwell Automation’s programmable logic controller (PLC) platform has uncovered two serious vulnerabilities that give attackers a way to modify automation processes and potentially disrupt industrial operations, cause physical damage to factories, or take other malicious actions.
Researchers from Claroty Team82 discovered the vulnerabilities and this week described them as being Stuxnet-like in nature because of how they allow attackers to run malicious code on a PLC without triggering any obviously unusual behavior.
Rockwell Automation simultaneously published advisories on the two flaws for its customers. The advisories are accessible here and here, to those who have an account.
The vulnerabilities prompted an alert from the US Cybersecurity and Infrastructure Security Agency (CISA) Thursday that points organizations using the affected components to mitigation measures and a detection method for addressing the threat. The agency says the vulnerabilities impact critical infrastructure sector organizations around the world. It identifies the vulnerabilities as involving low attack complexity and one of them as being remotely exploitable.
Remotely Exploitable Vulnerability
The remotely exploitable vulnerability (CVE-2022-1161) has a maximum severity rating of 10 and is present in PLC firmware running on Rockwell’s ControlLogix, CompactLogix, and GuardLogix lines of control systems.
These are the leading lines of PLCs in Rockwell’s catalog, says Amir Preminger, vice president of research at Claroty. “These devices are common in almost all verticals including automotive, food & beverage, and oil & gas,” Preminger says. “The only industry that we can think of where we wouldn’t expect to see them is power transmission and distribution.”
Preminger says the vulnerability is tied to the fact the PLC stores the executable file — or bytecode — and the source code (aka textual code) in separate locations on the PLC. This gives attackers a way to modify the bytecode without changing the source code.
“The PLC doesn’t require the two to be compatible,” Preminger says. “When an engineer connects to a PLC, they would see the same textual code running, while the bytecode that was altered results in malicious code running without any indication of change.” Claroty identified 17 Rockwell PLC models as being affected.
CISA’s alert said the issue stemmed from a failure to control inclusion of functionality from an untrusted sphere. Its recommendations for addressing the problem are available here.
Code Injection Vulnerability
The second vulnerability (CVE-2022-1159) is present in Rockwell’s Studio 5000 Logix Designer, the software that engineers use to program its PLCs. The software allows engineers to develop, compile, and transfer newly developed logic to the company’s line of programmable logic controllers.
It’s common for engineers in operational technology environments to make upgrades to the complex logic in PLCs to improve, tweak, or modify whatever process the PLC is controlling, Preminger says. The vulnerability in Studio 5000 Logix Designer allows an attacker that already has administrative access on the workstation running the software to hijack the compilation process and inject malicious code, which they can then execute on the PLC without triggering any alert.
“CVE-2022-1159 enables an attacker to alter code as it is being compiled without the user’s knowledge,” Preminger says. “This could result in alteration of the logic that the engineer thought they were transferring to the PLC.”
The vulnerability has been assigned a severity rating of 7.7 out of 10, which makes it high priority but not necessarily a critical vulnerability. CISA’s advisory for the flaw called it a code injection issue.
Potential for Stuxnet-Like Attacks?
Both vulnerabilities exist in different Rockwell Automation components. But they enable attackers to essentially do the same thing: to change the logic flow in a PLC to trigger new commands being set to the physical devices that are being controlled by the system. As an example, Claroty researchers said they changed certain tags — or automation processes variables — to different values, which in a real-life situation could have resulted in things like engine speeds being manipulated to cause significant damage to an automation process.
“This is a Stuxnet-type of attack because Stuxnet was the first reported attack that concealed executed bytecode on a PLC while letting engineers believe that normal code was executed,” Preminger says. “Stuxnet altered all the visual indications that something else was running which, in Stuxnet’s case, resulted in centrifuges spinning faster than what was intended and causing an unexpected result.”
Concerns over ICS security are by no means new. But they have been heightening in recent years. A recent study from Claroty found a 52% increase in reported ICS vulnerabilities in 2021 compared to 2020. That’s significantly higher growth compared to the 25% increase in disclosed ICS vulnerabilities between 2019 and 2020. Of the 82 vendors whose ICS products contained vulnerabilities last year, 21 had not previously reported any flaws, meaning researchers have begun more broadly hunting for ICS bugs.
A previous report that Claroty released last year showed that 90% of the disclosed vulnerabilities in the first six months of 2021 had low attack complexity and 71% had severity ratings of ‘high’ or ‘critical’. More than six in 10 (61%) were remotely executable, and 74% did not require any privileges to execute.
Attacks like the one on Colonial Pipeline and reports like the one the FBI recently issued about the operators of the infamous Triton malware continuing to attack energy sector organizations — in the same way they did at a Saudi Arabian energy firm in 2017 — have significantly exacerbated those concerns. Such concerns have contributed to significant new investments and initiatives around cybersecurity from the US government over the past year.
