PLC vulnerabilities can enable deep lateral movement inside OT networks

Threat groups who target operational technology (OT) networks have so far focused their efforts on defeating segmentation layers to reach field controllers such as programmable logic controllers (PLCs) and alter the programs (ladder logic) running on them. However, researchers warn that these controllers should themselves be treated as perimeter devices and flaws in their firmware could enable deep lateral movement through the point-to-point and other non-routable connections they maintain to other low-level devices.

To exemplify such a scenario and highlight the risks, researchers from security firm Forescout used two vulnerabilities they discovered in Schneider Modicon PLCs to move deeper into a simulated OT architecture of a movable bridge and bypass all safety mechanisms to cause physical damage.

Authentication bypass and remote code execution

The two vulnerabilities found by Forescout affect PLCs from the Modicon Unity line that are managed with the EcoStruxure Control Expert and EcoStruxure Process Expert control systems using Schneider’s Unified Messaging Application Services (UMAS) protocol. This includes the following PLCs:

• M340 (BMXP34*)
• M580 (BMEP*, BMEH*)
• M580 Safety (BMEP58*S, BMEH58*S)
• MC80 (BMKC80)
• Momentum Unity M1E (171CBU*)
• Quantum Unity (140CPU65*)
• Premium Unity (TSXP57*)

Modicon PLCs are among the most popular in the world being used in industries including water, power generation, mining, transportation, and manufacturing. The Control Expert PLCs are used for process automation and the M340 and M580 PLCs are the Unity’s line most prevalent products.

One of the vulnerabilities, tracked as CVE-2022-45789 and rated with 8.1 severity on the CVSS scale, allows attackers to hijack an already authenticated Modbus session and execute unauthorized Modbus functions on the controller. Modbus is a data communications protocol originally developed by Modicon in the late 1970s that is now a de-facto communications standard for industrial devices. UMAS is a proprietary variant based on it.

The issue was in the UMAS EnhancedCyberReserve mechanism, which is Modicon’s attempt to implement authentication in UMAS between the PLC and the engineering client programming it. Originally the protocol came without any authentication or encryption, and this was added later in several iterations as other vulnerabilities were found in it in the past. However, the Forescout researchers found that the current implementation is not completely safe either.

“When investigating the patched EnhancedCyberReserve mechanism, we observed that it is still fundamentally broken,” the researchers said. “First, nonces are maintained by the PLC as globals without any explicit ties to a particular client or reservation ID […] In addition, these nonces only renew when a session ends or an explicit UMAS nonce exchange request is received.”

In cryptography, a nonce is a secret number that can be used for an operation only once. However, since in the UMAS implementation it only refreshes when a session ends, a man-in-the-middle attacker between an engineering client and a PLC can sniff them out from intercepted traffic along with a reservation ID and then forge their own authentication request that the PLC will accept without ending the original session.

The second vulnerability, tracked as CVE-2022-45788 allows for remote code execution on the PLC and is rated even lower than the first with 7.5 on the CVSS, though this still qualifies as high criticality. This vulnerability is interesting because it involves the use of an undocumented Modbus UMAS command (service code 0x50) that is very powerful and allows for direct memory manipulation with little to no traces.

“It should be noted that while Schneider Electric describes CVE-2022-45788 as relating to downloading malicious project files, this vulnerability actually operates on a completely different – undocumented – set of functionality that allows for modifying internal PLC memory without affecting the PLC run state or requiring a project download,” the Forescout researchers said.

This distinction is important because most PLC attacks target the program code running on the PLC that then influences a physical process through valves, motors, actuators, pumps that are connected to the PLC. The problem is, modifying the code or uploading new logic to the PLC might trigger safety mechanisms or might require a restart of the PLC or the logic running on it. With this vulnerability, the attacker can create virtual memory pages and then fill them with a proprietary command set that allows them to operate directly – read, write, copy, resize, etc. – on the internal memory blocks. This is essentially similar to live patching a running process in an operating system.

These two vulnerabilities were found by the Forescout researchers last year as part of a larger research project of industrial control systems called OT:ICEFALL and were reported to Schneider in April and July, but their disclosure was delayed at the vendor’s request. Schneider released advisories for them in January.

Remote access to PLCs bypasses traditional OT security controls

A traditional OT environment is split into multiple functional levels that include the devices directly impacting physical processes, such as valves, actuators, and sensors (level 0); the PLCs that control them (level 1); and the systems that supervise and acquire data from the PLCs, also known as SCADA systems (level 2). It is at this point that we generally encounter the first security perimeter where organizations place some access controls.

Level 3 contains operation management software such as a logging server, databases, application servers and engineering workstations (EWSs), while level 4 contains the organization’s IT network with enterprise resource planning (ERP) and financial systems. Between levels 3 and 4 there are additional security controls to separate the IT from the OT network segments.

Following this map an attacker would either have to first break into the IT segment, manage to jump to the level 3 segment inside the OT, infect an engineering workstation and then use its connections to reach PLCs or hijack a SCADA system and effect change through its human-to-machine (HMI) interface. There are often shortcuts, and these are typically caused by the need of organizations to implement remote management.

PLCs in remote installations are often connected to an organization’s control center through wireless or cellular IoT gateways and these can have vulnerabilities that are remotely exploitable, as researchers from industrial cybersecurity firm Otorio showed recently. That might not even be needed as SCADA systems and PLCs are routinely connected directly to the internet, even though that’s very bad practice.

The Forescout researchers used the Shodan search engine and found more than 1,000 Modicon Unity PLCs exposed to the internet with France, Spain, Italy, and the United States having the biggest number of them.

“A quick search for the affected models on Shodan has shown exposed Modicon PLCs in everything from airports, mining, and solar and hydro power generation to chemical manufacturing,” the researchers said. “One of the exposed M340 PLCs with a project loaded for a “impianto di frantumazione,” the Italian term for a crushing plant used in mining operations. Smaller power generation facilities (often owned by local communities) seem particularly overrepresented in the set of exposed PLCs.”

Then there are the so-called packaged units (PUs), which are entire subsystems built for a specific purpose — HVAC, chemical injection, water treatment, gas turbine — that manufacturers sell to operators and which are plugged directly into an asset owner’s control system. These PUs can control PLCs and various other components that make the subsystem work, but they generally operate as black boxes that are remotely managed by the system provider asset and the asset owner has little control over them, often being restricted to only reading output data or issuing a limited set of commands.

So attackers can reach a PLC in multiple ways, either using the long path from enterprise IT into OT or by using shortcuts such as remote access gateways and protocols that the asset owner has intentionally put in. Stuxnet was reportedly delivered to Iran’s Natanz nuclear plant on USB drives that got plugged directly into the engineering workstations, bypassing any perimeter controls. Meanwhile, the GhostSec hacktivist group recently targeted a M340 Modicon PLC belonging to Nicaraguan ISP UFINET because it was exposed to the internet. Attackers will usually look for the path of least resistance.

The good news is that gaining access to a PLC does not immediately mean you can perform destructive attacks. Industrial installations usually have safety instrumented systems (SIS) that usually monitor physical processes out-of-band and prevent them from exceeding certain safe operational parameters. HMIs and PLCs might have built-in restrictions on how high certain parameters are allowed to be changed to as well. There can be nested deployments, where one PLC does not control devices directly, but is only used to receive data from other PLCs behind it or from PUs.

Deep lateral movement

That said, many L0-2 architectures are supported by manufacturers where PLCs and SIS and PUs and wireless industrial gateways, WAN radio modems, are all linked through serial or point-to-point Ethernet connections, usually through devices called fieldbus couplers — the equivalent of network switches — which are increasingly sophisticated with support for many protocols and types of connections. These direct connections lack security by design and because they are not routable, they’re not taken into account when doing threat modeling, by either vendors or asset owners.

According to the Forescout researchers, because of all these connections, in many instances a PLC is more than a field controller. It’s a perimeter device through which attackers can reach other L1 devices by exploiting these non-routable links. They call this deep lateral movement.

Forescout

“Oftentimes people have this assumption that once an attacker reaches a PLC, then that’s it and then whatever the PLC kind of allows them to do as an attack surface, that’s what they can do,” Daniel dos Santos, Forescout’s head of security research, tells CSO. “If there’s a safety system next to that PLC, or if there’s anything behind the PLC, then the attacker cannot reach that because it’s serial, because it’s a separate device, it’s a separate environment and so on. What we are showing is that that assumption is not always correct.”

In their proof-of-concept scenario, the researchers considered an OT architecture for controlling a movable bridge that’s modeled after real world deployments. The bridge systems are delivered as packaged units managed by a third party while the monitoring is done through SCADA by a central government agency.

There is an object PLC that exposes limited functionality like initiating the bridge closing or opening sequence and some variables but offers no granular control over the bridge systems. It does talk to motors and other elements through a fieldbus and has a point-to-point Ethernet link to a safety system that only exposes a few status values, but which then has a safety bypass mechanism linked to it. The PLC is also connected to a fieldbus coupler that acts as a central gateway between multiple bridges, but the coupler doesn’t allow sending messages directly to the PLC.

“An attacker coming in from the central SCADA who wishes to carry out one of the attack scenarios we described above will first have to get past the coupler,” the researchers explained. “After that, they will need to be able to get RCE on the bridge object PLC and, to do that, they need an authentication bypass. After they have RCE on the object PLC, they can move into the fieldbus link to have detailed manipulation of the field devices. They can also cross the point-to-point link to the SIS by getting RCE on the Ethernet module and then moving across the backplane to take care of the safety systems.”

Forescout

First, the researchers gained remote code execution the central coupler, which in their scenario was a Wago 750 series. They did this using a buffer overflow vulnerability they found in the past and disclosed as part of their NUCLEUS:13 research project. They then hooked the coupler’s Modbus handler to act as a proxy and enable them to talk UMAS to the M340 PLC as well as sniff traffic.

This gave them a man-in-the-middle position to be able to exploit the CVE-2022-45789 vulnerability and spoof an authenticated session to the M340 PLC. Next, they exploited the CVE-2022-45788 vulnerability, which enabled them to bypass the restrictions of what the PLC program allowed a normal operator to do and move into the internals of the packaged unit.

With this level of access, the researchers could then start interacting with the CANopen bridge systems fieldbus that connects the PLC to the bridge systems like motors and encoders. But there is still the safety PLC and system that would prevent any destructive action, so the next goal was to jump into that.

In their example, the SIS uses a GuardLogix PLC with an Ethernet module that has a point-to-point link to the M340 object PLC. In this case, they used a pre-auth stack buffer overflow vulnerability in the IP options TCP/IP stack (CVE-2019-12256) that they previously found and reported as part of the Urgent/11 project. With code execution into the Ethernet controller they can start talking to the GuardLogix PLC  CPU via the device driver API.

The attacker has now used their access to a PLC that initially exposed limited functionality to move deeper inside the network through non-routable links and gain the ability to influence the safety systems and bridge components directly.

“The impact of a compromised device isn’t limited to the explicit capabilities of a link or its first-order connectivity,” the researchers said. “Just because it only exposes a few Modbus registers or is hooked up to an uninteresting device does not mean that an attacker cannot turn that link into something else and use that uninteresting device as a staging point for moving towards more interesting targets. And with the kind of deep access attackers get through this approach, things might become possible which change the potential impact of an attack.”

Mitigating lateral movement risk

To mitigate some of the risks of deep lateral movement, the Forescout researchers have the following recommendations:

• Disable unused services on devices. For instance, if UMAS over Ethernet is not required on a PLC, disable it. Even if the PLC is nested, since we showed in this report how attackers can leverage vulnerabilities on nested devices.
• Use DPI firewalls and IP-based access control lists to restrict sensitive flows between engineering workstations and PLCs. In cases where only subsets of protocols are required, use DPI to restrict this further.
• From a forensics perspective, ingest level 1 event logs which contain indicators of malicious activity of this kind. Enforce segmentation through OT-DPI firewalls and/or conformance-checking gateways including for point-to-point links.
• Depending on whether the risk justifies it, certain point-to-point links that cross highly sensitive segments might warrant dedicated drop-in DPI firewalls for Ethernet and for serial links with similar profiles you might want to consider inline taps that collect data out-of-band.

Even if the state of attacks currently observed in the wild have not yet reached this level of complexity of chaining multiple vulnerabilities in different types of L1 devices and hopping between them through non-routed links, attackers are always catching up to new techniques. Before Stuxnet no one had seen malware that interacted with PLCs and before Triton no one had seen malware that interacted with safety instrumented systems.

According to dos Santos, what is demonstrated in security research tends to become a reality in real world attacks a few years later and in the IT world there are examples of malware that follows this principle of exploiting deeper components of a computer system after gaining access to the OS, like the UEFI, the Intel Management Engine or the out-of-band management controllers. And just like in the IT or IoT world where there is a trend of adding connectivity to previously “dumb” devices, the same trend exists in the OT world, including at the network architecture level by integrating previously separated systems more and more with direct links and even adding external connectivity to them for remote management, which ends up increasing their attack surface and creating paths for attackers to reach previously unreachable devices.