Authentication bypass allows complete takeover of Modicon PLCs used across industries

The vulnerability could allow attackers to insert malicious code and easily avoid detection.

skull and crossbones in binary code
Thinkstock

Several programmable logic controllers (PLCs) from Schneider Electric’s Modicon series that automate industrial processes in factories, energy utilities, HVAC systems and other installations are impacted by a flaw that could allow hackers to bypass their authentication mechanism and execute malicious code. According to researchers from security firm Armis, who found and reported the vulnerability, attackers with network access to impacted controllers could exploit the issue to install malware that alters the operation of the controllers and hides those malicious changes from the workstations and operators managing them.

Attacks against industrial controllers have been observed in the wild in the past with Stuxnet, the cyber-sabotage worm that infected Siemens PLCs used to control uranium enrichment centrifuges at Iran's Natanz nuclear plant, and with Triton, the malware that targeted Triconex safety controllers at a petrochemical plant in Saudi Arabia.

Authentication bypass re-enables past flaws

The issue is caused by an undocumented command in the protocol used by engineering workstations to communicate with the PLCs and upload programs to them to be executed. This protocol, known as UMAS, is an extension to the Modbus protocol originally designed in 1979 and widely used to control PLCs over serial or TCP/IP connections. UMAS implements functionalities that were missing from Modbus, including firmware updates, binary transfers and authentication.

UMAS commands that can change the configuration of the PLC or the program running on it require authentication. This is achieved through a challenge-response mechanism that validates an application password, or more precisely the password hash, and then establishes a shared secret or token that needs to accompany any subsequent authenticated commands. This is similar to how websites set a session cookie inside the user's browser following successful authentication and password validation.

The problem in the case of M340, M580, and possibly other Modicon PLCs is how the password is validated. When a new project is created on the engineering workstation, Schneider Electric’s EcoStruxure software encourages the user to create a new application password. When the project file is then transferred to the PLC for the first time, the password is also set on the PLC enabling authentication. Later, when the software needs to send a command that requires authentication, the user will be prompted by the password and the software will verify that the password hash matches the password hash stored on the PLC.

Last year, the Armis researchers analyzed the firmware of M340 PLCs and discovered an undocumented command called pu_ReadPhysicalAddress that did not require authentication. This command allowed reading the entire memory of the PLC, including the password hash. The issue, tracked as CVE-2020-7537, was reported to Schneider Electric in November and was patched in December via an update that enforced authentication for the undocumented command.

The researchers then set out to analyze how the EcoStruxure software validates the user-inputted password and looked at the traffic between the software and the PLC. This allowed them to discover another undocumented command called MemoryBlockRead that the software uses pre-authentication to read the password hash from the PLC and compare it to the hash of the password inputted by the user. The existence of the MemoryBlockRead command can also lead to an authentication bypass and is now tracked as CVE-2021-22779.

"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," the researchers wrote in a new report. Essentially, an attacker on the same network as a vulnerable PLC can use this command to read the password hash from the PLCs memory, then complete the challenge response and obtain the secret token that would enable authenticated command execution.

Remote code execution via disabled commands

In the past, Schneider Electric disabled other undocumented UMAS commands that could be abused to perform denial-of-service attacks against Modicon PLCs. Two of these commands were WritePhysicalAddress (function code 0x29) and PrivateMessage (function code 0x6D) and were tracked as CVE-2019-6829 and CVE-2018-7852 at the time. Schneider's fix for them involved disabling the commands entirely when an application password was set on a PLC. According to the Armis researchers, both commands can actually also lead to remote code execution (RCE) with system-level privileges.

"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," the Armis researchers said about WritePhysicalAddress in their new report. "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 from December 2020."

Schneider's fix for WritePhysicalAddress and PrivateMessage is incomplete because the commands are still accessible when no application password is set on the PLC, possibly for backwards compatibility with older tools that don't support the new UMAS authentication feature. The problem is that the new CVE-2021-22779 vulnerability found by Armis allows unauthenticated attackers to bypass authentication and enables them to then perform a downgrade attack where they disable authentication on the PLC entirely by uploading a project without a password. This in turn would enable the exploitation of the WritePhysicalAddress and PrivateMessage commands for arbitrary code execution, resulting in full takeover of the device.

According to the researchers, the attack steps are:

  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.
  5. Reach code execution by exploiting one of the undocumented commands that can reach RCE (WritePhysicalAddress, or PrivateMessage).

As a final step, the hacker can use the newly gained RCE privilege to upload malware to the PLC that would return the PLC to its previously password-protected state, Ben Seri, Armis's VP of research, tells CSO. This attack chain can be automated and performed quickly, significantly decreasing the chance of anyone noticing. The malware could then alter the program running on it and feed false data back to the engineering workstation.

According to Armis, Schneider will release an advisory Tuesday that will include a workaround and plans to release patches to address the authentication bypass in Q4. The problem is that even if access to the MemoryBlockRead command is removed and this authentication bypass technique is mitigated, the lack of encryption in the UMAS protocol itself can still be exploited using other techniques. For example, in a man-on-the-side or man-in-the-middle (MitM) scenario, an attacker in a position to intercept traffic between the engineering workstation and the PLC could intercept and extract the authorization token or could brute-force it since it only has 255 possible values and the PLC does not reset it on failed attempts.

"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 [an attacker] to gain a reservation token that he can then 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," the Armis researchers said. "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."

Copyright © 2021 IDG Communications, Inc.

AWS, Google Cloud, and Azure: How their security features compare