ModiPwn

Revised Edition: 8:07am, July 13th, 2021

What was discovered:

Armis researchers discovered a new vulnerability (CVE-2021-22779) in Schneider Electric (SE) Modicon PLCs that bypasses security mechanisms added to these PLCs to prevent abuse of undocumented Modbus commands. These undocumented commands can allow full control over the PLC — overwriting critical memory regions, leaking sensitive memory content, or invoking internal functions. Armis researchers found that these commands can be used to take over the PLC and gain native code execution on the device which can be used to alter the operation of the PLC, while hiding the alterations from the engineering workstation that manages the PLC. This attack is an unauthenticated attack that only requires network access to the targeted PLCs.

The process:

Armis informed SE on November 13, 2020 and has since worked with them to understand the underlying issues, and work towards a patch. Today SE has issued a security advisory with mitigation steps. A patch that fully mitigates the issues is still under development.

In the process of working with SE, Armis researchers discovered and reported two additional authentication bypass techniques that have yet to be resolved by SE. Due to inherent shortcomings of the Modbus protocol that powers SE’s UMAS protocol used by Modicon PLCs, Armis will continue working with SE and additional vendors to address these issues.

Please note: Due to an error in timing, this research post was published in advance of the SE security advisory statement (linked below and here). This advisory note is now live and we strongly encourage all of our readers to review the notice. We apologize for any inconvenience that this earlier publication may have caused any parties. The SE advisory notice can also be downloaded from here: security advisory.

High-level takeaway point:

• The analysis revealed weak points of the Modbus protocol – an industry standard protocol that is used commonly in a wide array of industrial controls. SE’s UMAS protocol operates over the Modbus protocol, which lacks encryption and proper authentication mechanisms. These known deficiencies lead to vulnerabilities which are discovered, patched, and then re-patched time and time again, in a classic whack-a-mole cycle.
• SE has stated in the past its intent to adopt the Modbus Security protocol that offers encryption and authentication mechanisms that are not part of the classic Modbus protocol. These adoption steps, however, have yet to be implemented.
• Malware that targets industrial controllers have been found in attacks in the wild – such as the Triton malware, which targeted Triconex safety controllers from SE. This malware was an example of the devastating potential a malware running on an industrial controller can achieve by gaining native code execution. This latest vulnerability shows the potential for an attacker to gain native code execution on a similar controller.

How Armis can help:

• Armis strongly recommends the use of Schneider Electric guidelines for secure configuration of Modicon PLCs – such as the use of application password in project files, properly using network segmentation, and implementing access control lists to shield industrial controllers from unwanted communications and attacks.
• This research underlines the importance of 3rd party solutions that are able to monitor devices, identify risks, and prevent attacks on vulnerable industrial controllers.
• The Armis platform for Operational Technology (OT) supports advanced features to identify and monitor risks to OT devices. This includes detection of vulnerable PLCs, anomalies in ICS protocols, detection of man-in-the-middle attacks that may undermine the security of unencrypted ICS protocols, and identification of active exploitation attempts.
• The Armis platform also supports a wide-array of integrations that can help organizations carry out security policies – for example, identifying the correct boundaries that should be in use based on the strict Purdue-levels of OT devices, and configuring these boundaries via integrations with network infrastructure solutions.
• Read more about How Armis can help in this white paper.

Vimeo

Technical findings overview

The discovered vulnerability (CVE-2021-22779) is a authentication bypass vulnerability that can be chained with additional vulnerabilities in the UMAS protocol that were discovered in the past but only partly mitigated. Armis researchers discovered (as we’ll detail below) that while these additional vulnerabilities (CVE-2018-7852, CVE-2019-6829) were categorized as denial-of-service, they can actually lead to native remote-code-execution. These vulnerabilities are essentially undocumented commands in the UMAS protocol, and Armis researchers discovered that instead of removing these commands from the protocol (maybe due to legacy dependencies), SE added an authentication mechanism around them to mitigate their risk. Unfortunately, this mechanism was found to be faulty, and thus in light of this latest discovery these commands will require a more fundamental fix to be fully mitigated.

Due to the above, the following CVEs still impact latest firmware versions of Modicon M340 and M580 PLCs:

• CVE-2021-22779 – Authentication bypass vulnerability via UMAS command MemoryBlockRead
• CVE-2018-7852 – Untrusted pointer dereference via UMAS command PrivateMessage (RCE)
• CVE-2019-6829 – Arbitrary memory write via UMAS command WritePhysicalAddress (RCE)
• CVE-2020-7537 – Arbitrary memory read via UMAS command ReadPhysicalAddress (Information leak)

Additional Modicon models are currently considered not vulnerable, while Armis researchers continue analyzing their full impact.

To fully understand the technical details of the findings described above, some background is required on the Modbus and UMAS protocols.

Modbus

Modbus is the de facto standard for controlling PLCs in SCADA systems. It was first published by Modicon (now Schneider Electric) in 1979. Modbus was designed a long time ago and is missing features required by modern systems, such as transfer of binary objects to and from the PLC.

Modbus can operate over serial communication or IP communication. The widely used IP version of Modbus is the Modbus/TCP standard.

Modicon chose to extend the Modbus implementation under a reserved Modbus function code. The extended protocol is called UMAS, and it adds authentication, binary data transfer, firmware updates, and additional features to the basic Modbus protocol.

UMAS

Modicon PLCs (M340, M580, and others) implement UMAS. UMAS re-implements standard Modbus commands and some necessary Modbus functions that are missing.

For example, one of the proprietary UMAS commands is the MemoryBlockWrite command (function code 0x21), which does not require authentication.

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 whitepaper (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 and\or 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 UMAS\Modbus 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.