Bypassing Authentication and Achieving RCE on Schneider Electric M340 PLCs

TLDR: This research details a multi-stage attack chain against Schneider Electric M340 PLCs that leverages the proprietary UMAS protocol to achieve remote code execution. By performing a Man-in-the-Middle attack to intercept session nonces, an attacker can bypass authentication and modify memory to redirect execution flow. Security teams must prioritize firmware updates and network segmentation to prevent unauthorized access to these critical industrial controllers.

Industrial control systems often rely on proprietary protocols that prioritize operational uptime over modern security primitives. The recent research presented at Black Hat 2024 regarding the Schneider Electric M340 PLC series highlights exactly how fragile these systems become when they are exposed to network-based attacks. While the industry has long warned against connecting PLCs directly to the internet, this research proves that even internal network access is sufficient for a complete compromise of the controller.

The UMAS Protocol and the Authentication Gap

At the heart of the M340 PLC management is the Unified Messaging Application Services (UMAS) protocol. This proprietary protocol is used for configuration and monitoring, operating over Modbus/TCP with a specific function code of 0x5A. The protocol distinguishes between public and reserved sessions. Public sessions require no prior authentication, while reserved sessions are intended for sensitive operations like firmware updates or project modifications.

The researchers identified that the authentication process for reserved sessions is fundamentally flawed. During the handshake, both the engineering station and the PLC generate random nonces. These nonces are used to derive a session key, which then signs subsequent messages. The critical failure here is that the implementation of this exchange is susceptible to a Man-in-the-Middle (MitM) attack. By using tools like Ettercap, an attacker can intercept the traffic, drop the legitimate key exchange, and inject their own, effectively establishing a reserved session without ever knowing the project password.

From Memory Leak to Remote Code Execution

Once the attacker has established a reserved session, the path to code execution opens up through memory manipulation. The research highlights a series of vulnerabilities, including CVE-2020-7537, which allowed for an information leak. While later firmware versions addressed this specific leak, the underlying issue of improper access control remained.

The attack chain relies on the fact that the PLC does not implement modern memory protections like the NX (No-Execute) bit. Consequently, any memory page that is writable is also executable. The researchers demonstrated that by modifying the addr_read_limiter variable in memory, they could expand the range of memory accessible via the ReadPhysicalAddress command. This allowed them to read and write to memory regions that were previously protected.

The final stage of the attack involves overriding a function pointer. The PLC uses a source function that eventually invokes a destination function. By using the WritePhysicalAddress command, an attacker can overwrite the secondary function pointer to point to their own injected shellcode. The next time the PLC triggers the source function, it executes the attacker's payload instead of the intended logic. This is a classic exploitation technique, but its application here demonstrates how Broken Access Control in industrial protocols can be weaponized to bypass even basic security checks.

Real-World Implications for Pentesters

For those performing penetration tests on OT environments, this research provides a clear roadmap for assessing PLC security. If you encounter an M340 PLC on a network, your first step should be to verify the firmware version. If the device is running a version older than 3.65, it is likely vulnerable to the full attack chain.

During an engagement, you should focus on the UMAS protocol traffic. Look for the 0x5A function code in your packet captures. If you can successfully perform an ARP spoofing attack or otherwise position yourself as a MitM, you can attempt to intercept the nonce exchange. Even without the ability to fully automate the exploit, the mere presence of these vulnerabilities suggests that the device is not hardened against an adversary with network access. The impact of a successful exploit is total control over the PLC, which could lead to physical process disruption, unauthorized logic changes, or the exfiltration of sensitive process data.

Defending the Controller

Defending against these attacks requires a layered approach. First and foremost, apply the latest firmware updates provided by the vendor. Schneider Electric has released updates that specifically address the read-limit bypass and the RCE vulnerabilities, as noted in their security advisories SEVD-2024-317-02 and SEVD-2024-317-03.

Beyond patching, network segmentation is non-negotiable. PLCs should never be reachable from general-purpose corporate networks, let alone the public internet. Implement strict firewall rules that restrict access to the UMAS and Modbus/TCP ports to only authorized engineering workstations. If remote access is required, it must be handled through a secure, authenticated VPN tunnel with multi-factor authentication.

The reality of industrial security is that we are often dealing with legacy designs that were never intended to face the threats of today. As researchers continue to peel back the layers of these proprietary protocols, the burden falls on both vendors to modernize their security and on practitioners to enforce strict network boundaries. Do not assume that the lack of a public exploit means your controllers are safe. Investigate the traffic, segment your networks, and assume that any device on the wire is a potential target.