The Vulnerability Can Lead to Native Remote-Code-Execution on Vulnerable PLCs

The command writes a chunk of binary data to an offset within a certain block ID. The blocks are located in fixed memory addresses, and are marked as writable or read-only blocks. When attempting to write on a read-only block, the MemoryBlockWrite command returns an error response.

UMAS Reservation Mechanisms

Certain changes to a PLC require multiple commands that depend on one another. To allow for such scenarios, Modicon implemented a reservation mechanism. The reservation mechanism was created to synchronize modifications of the PLC’s program – a form of a global locking mechanism over certain critical changes. Once an engineering workstation successfully reserves a PLC over UMAS, it receives a one-byte token that is used to perform modifications to the PLC. This token allows the workstation to change any aspect of the application running on the PLC. UMAS commands that don’t modify the PLC do not require this token and can take place without any authentication by the workstation. Since only one workstation can reserve the PLC at a time, this mechanism protects the PLC from overlapping modifications that can damage the PLC, the equipment it controls and the normal operation of the factory.

The initial version of the reservation mechanism (we’ll name this basic reservation) worked by utilizing a UMAS command with function code 0x10. This command did not require authentication, or challenge-response handshake, and relied on a hardcoded shared secret between the PLC and SE’s managing software on the engineering workstation:

The hardcoded secret used by this mechanism can be observed in the unencrypted UMAS traffic, or located by reverse engineering a Modicon PLC firmware.

Enhanced Reservation

Over time, security concerns were raised, and various undocumented UMAS commands were shown to allow remote-code-execution, or other malicious intent. SE decided to enhance the reservation mechanism, so it will not only act as a locking mechanism, but as an authentication mechanism as well.

The Enhanced Reservation mechanism is based on a challenge-response handshake in which a shared password is authenticated. The shared password, called the application password, is dynamically set, when a project file is being uploaded to the PLC. The Enhanced Reservation mechanism utilizes the UMAS command with the function code 0x6E:

In this command the workstation and the PLC are exchanging a randomly generated buffer of 0x20 bytes:

A hash of these buffers, combined with the application password’s hash is used to complete the reservation.

Decompiled code snippet from the umas_EnahcnedResvMngt command handler from a Modicon firmware

As noted above, the secret shared key used in this mechanism is the hash of the password configured in the EcoStruxure software running on the Engineering Workstation. The EcoStruxure software encourages the user to configure a password upon creation of a new project. When a project file is transferred to the PLC the new application password is also configured on the PLC.

In both versions of the reservation mechanism, a one byte token is sent in response upon a successful reservation, and this token will then be prepended to UMAS commands that require authentication.

Bypassing Authentication – Take 1 (CVE-2020-7537)

Having reversed engineered the algorithm of the enhanced reservation mechanism, we wanted to see if we can leak the application password (or it’s hash) via an undocumented UMAS command. Static analysis of the latest firmware (at the time) of the M340 PLC, revealed a suspicious UMAS command:

The pu_ReadPhysicalAddress copies a memory chunk from a chosen address in the input command, to a response buffer. Other than simple validation of buffer sizes, the function poses no limitation on the address being read from the memory. Essentially this undocumented commands allows leaking all memory in the address space of the PLC.

Decompiled snippet from the pu_ReadPhysicalAddress command

This command can be used to leak the hash of the application password, that is stored in the memory of the PLC, and used to reserve and manage a PLC by an unauthenticated attacker.

In addition, a memory read command such as this can be used to leak sensitive information from the PLC that might relate to its operation, or even used as a denial of service primitive (!). Since there are no limitations on the address being read by this command, an attacker can abuse this command to crash the device by reading from certain hardware-specific addresses that will cause drivers on the PLC to be out-of-sync with the hardware. This can lead to various edge cases that can result in denial of service. When a PLC crashes in such a way it will not return quickly to normal operation –  a physical button needs to be pushed by an operator to restart the device.

Wireshark capture of an application password hash being leaked via the ReadPhysicalAddress UMAS command

This vulnerability was reported to SE in November 2020, and was disclosed in a security advisory December 2020. The patch introduced by SE to resolve this issue defined the ReadPhysicalAddress command as one that requires reservation – leveraging the mechanism to fend off this attack. While this did mitigate this authentication bypass, it did not fully resolve the underline risks in this command – since it might still be triggered if the project file in use is password-less.

Bypassing Authentication – Take 2 (CVE-2021-22779)

To better understand the UMAS messages flow of the Enhanced Reservation mechanism we connected to the PLC with the EcoStruxure software and analyzed the traffic it created. We noticed something interesting: when the correct password was typed into the EcoStruxure software some UMAS commands were generated as expected, but when an incorrect password was typed the software rejected the password without generating any traffic with the PLC.

This raised the question – how does the EcoStruxure software know the password is incorrect without communicating with the PLC? To answer this question we analyzed the UMAS commands sent by the workstation before the password is entered. One of the commands used by the workstation was the MemoryBlockRead command – that allows reading preconfigured blocks from memory, without authentication (similar to the MemoryBlockWrite command). Unlike the ReadPhysicalAddress command, the block IDs limit the access of the memory to certain fixed memory addresses.

The structure of UMAS command used to read predefined memory blocks from the PLC

Nevertheless, it appears the software uses this command, pre-reservation, to read the hash of the password from the PLC, and validate if the password entered by the user is correct. Needless to say, this mechanism is fundamentally flawed – the password hash is both passed over an unencrypted protocol, and can also be read by any unauthenticated attacker that simply implements the memory block read command.

While the EcoStruxure software uses the memory read command to validate the password hash – an unauthenticated attacker can simply use the read password hash to bypass the authentication mechanism of the Enhanced Reservation altogether.

Simple script that implements this authentication bypass technique (certain details have been censored)

From Authentication Bypass to RCE

As described above, two undocumented UMAS commands where found in the past to lead to denial-of-service – the UMAS command WritePhysicalAddress (function code 0x29, CVE-2019-6829), and PrivateMessage (function code 0x6D, CVE-2018-7852). As we’ll show below, the two can actually lead to remote-code-execution.

Arbitrary Memory Write

The command WritePhysicalAddress is the write equivalent for the ReadPhysicalAddress command described above. This command allows arbitrary write to any address in the PLC memory, with a data buffer supplied in the input buffer. While in the latest firmware version this command is inaccessible when an application password is in use, it can still be triggered if a downgrade attack is performed after the reservation mechanism has been bypassed (more on that in a bit) – or if an application password is never set in the first place.

The WritePhysicalAddress command handler (the test variable represents the current reservation mode)

While it is clear why this command can lead to denial-of-service (by altering memory with arbitrary data), it is unclear why this vulnerability was not categorized as remote-code-execution. Altering memory in an attacker-controlled address with an attacker-controlled payload is probably the easiest exploitation path there is to RCE. Numerous  function pointers, stack variables, or C++ vtable pointers reside in memory that can be altered, and shift the execution state from its original state. Using these to then reach attacker-controlled code can be done using ROP techniques. A similar exploit was developed by Armis researchers when an exploit utilizing the URGENT/11 was demonstrated to impact Modicon PLCs in a white paper (page 20) from December 2020.

Remote Procedure Call (RPC, a.k.a PrivateMessage)

The second undocumented command – PrivateMessage is a command that triggers internal functions in the PLC, by accessing C++ objects pointed by a pointer provided in the input buffer, and than triggering a callback function from these parsed objects. It is unclear what is the commercial use for this specific command, but it is clear it can lead to denial-of-service when the passed pointer does not point to a valid C++ object in the PLCs memory.

Turning this vulnerability to an RCE is only a bit more complex. A valid structure of a C++ object can be uploaded to the PLC memory via the MemoryBlockWrite command to a known address in memory. Then the PrivateMessage command can be sent – triggering a call to a function within the vtable of the C++ object controlled by the attacker. Similar to the steps detailed above, reaching attacker-controlled code by controlling the PC of the program is only a matter of connecting the dots via several ROP gadgets.

Downgrade Attack

Schneider Electric’s fix for both undocumented commands shown above was similar – disabling them completely when an application password is in use. However, when it isn’t in use, these commands remain accessible, perhaps to retain some legacy compatibility with tools that use these commands.

However, by exploiting the authentication bypass vulnerability (such as CVE-2021-22779) an attacker can downgrade the PLC’s security by uploading a new project file with no password configured. Once this downgrade attack is done, the undocumented commands detailed above can nevertheless be used by attackers to gain native code execution.

The attack steps are as follow:

1. Bypass the authentication with CVE-2021-22779 and reserve the PLC
2. Upload a new project file with no application password configured
3. Release the PLC reservation and disconnect from the device
4. Reconnect to the PLC with the basic reservation method, no password is needed

Reach code execution by exploiting one of the undocumented commands that can reach RCE (WritePhysicalAddress, or PrivateMessage)

Future Research

As detailed in the technical deep dive above, it is clear the underlying design flaws in UMAS and Modbus remain unfixed for the time being. While attempts to harden access to certain commands are being introduced, these design flaws create significant challenges for the developers – which will likely lead to additional vulnerabilities in the future.

In addition to the two CVEs detailed above, which allowed a full bypass of the enhanced reservation mechanism, we were also able to identify two additional attack scenarios that remain to be unpatched for the time being.

Man-on-the-Side Authentication Bypass

As detailed above, when a successful reservation has taken place, a 1-byte token is returned by the PLC. This token is later used in all commands that require reservation. If an attacker is placed within a network, in such a way that certain packets between the engineering workstation and the PLC are viewed by him – he can use that position to inject a TCP RST packet to the PLC, which will drop the Modbus TCP connection between the workstation and the PLC. The PLC will keep the reservation token’s state valid for reuse, for a few seconds. If in that time frame an attacker connects to the PLC, he can reuse the token, without needing to reauthenticate. This can be done by using an observed token (in a man-on-the-side scenario) or by simply brute-forcing the 255 possible values (the PLC will reject wrong tokens, and will not reset the token upon multiple attempts).

Although this attack scenario can be partly mitigated using a longer token, or by rejecting brute force attempts – the underlying threat to the reservation mechanism is yet again the lack of encryption – that allows a man-on-the-side attacker to obtain information that may be used to bypass this authentication mechanism.

Man-in-the-Middle Authentication Bypass

A more straightforward attack, that is unfortunately, very simple to carry out – is a man-in-the-middle attack. Using ARP spoofing, for example, an attacker can set up a man-in-the-middle position between an engineering workstation and a Modicon PLC.

Using this position an attacker can ambush a reservation attempt from the workstation, and harvest the credentials andor token used by a legitimate user. While in the current design of the reservation mechanism, the password hash is being passed unencrypted via the MemoryBlockRead command, it is expected this command will not be used in the future, and the password hash will not pass in plain-text via the UMASModbus connection. However, since there is currently no way for the protocol to detect a man-in-the-middle attack, simply forwarding the authentication packets to the PLC will allow him to gain a reservation token that he can than abuse to run any of the undocumented commands that may be used to alter the PLC configuration, or trigger commands that may lead to RCE.

Yet again, fixing this MiTM authentication bypass will require a secure connection between the engineering workstation and the PLC – one that is able to both encrypt the communication but also authenticate both parties, validating that the connection isn’t passed through a MiTM.

Final Notes

While secure communication in endpoints is considered a solved issue nowadays, solving it in a similar fashion poses a challenge for industrial controllers. In traditional endpoints, services are authenticated using certificates, and a root of trust is defined in a secure way. In industrial controllers, a user-interface isn’t present to allow validation of a certificate and lack of Internet connectivity (by design) prevents the use of a CA (certificate authority). Creating secure communications without these means require physical access to the controllers, through which keys can be exchanged externally to the network. This would pose a deployment challenge, and it seems manufacturers and vendors are not ready to take this step.

Unfortunately, without this type of fundamental rehaull of the way Modicon PLCs communicate, the security risks detailed above would remain relevant to these controllers for the time being.

Disclosure Timeline:

• November 13, 2020 – Initial report on three undocumented UMAS commands affecting Modicon PLCs that can lead to remote-code-execution and info-leak.
• November 21, 2020 – SE claims two of the commands were already patched (CVE-2018-7852, CVE-2019-6829; discovered by Talos [1,2]), and that the info-leak issue was previously disclosed to them and is expected to be disclosed on December 2020 (here, CVE-2020-7537).
• November 25, 2020 – Armis finds that the two patched commands were not properly patched, the PoC script provided in the initial report shows these PLCs are still vulnerable in the latest software; Moreover, the vulnerabilities were identified as denial-of-service, while Armis finds they can actually lead to remote-code-execution.
• February 9, 2021 – SE claims the patch for these PLCs is only effective when an application password is set on the PLC projects.
• February 25, 2021 – Armis finds various bypass techniques for the application password mechanism (enhanced reservation bypass, ARP spoofing to gain MiTM, and brute force of weak token)
• March 26, 2021 – Armis provides PoC scripts that demo the enhanced reservation bypass in an unauthenticated attack. This attack allows an attacker to perform a downgrade attack — removing the application password restriction, which enables access to the undocumented UMAS commands that can lead to native code execution.
• March 31, 2021 – SE confirms an additional vulnerability (CVE-2021-22779) exists in the enhanced reservation bypass, and it had too been disclosed to them by an additional 3rd party. A patch is expected to be released Q4 of 2021, and a workaround will be provided by SE in an advisory on July 13, 2021. Other bypass techniques (MiTM via ARP spoofing and brute force of security token) remain unpatched due to design limitations.