29 September 2022

    The secrets of Schneider Electric’s UMAS protocol

      UMAS (Unified Messaging Application Services) is a proprietary Schneider Electric (SE) protocol that is used to configure and monitor Schneider Electric PLCs.

      Schneider Electric controllers that use UMAS include Modicon M580 CPU (part numbers BMEP* and BMEH*) and Modicon M340 CPU (part numbers BMXP34*). Controllers are configured and programmed using engineering software – EcoStruxure™ Control Expert (Unity Pro), EcoStruxure™ Process Expert, etc.

      In 2020, a vulnerability, CVE-2020-28212, was reported, which could be exploited by a remote unauthorized attacker to gain control of a PLC with the privileges of an operator already authenticated on the controller. To address the vulnerability, Schneider Electric developed a new mechanism, Application Password, which should provide protection against unauthorized access to PLCs and unwanted modifications.

      An analysis conducted by Kaspersky ICS CERT experts has shown that the implementation of the new security mechanism also has flaws. The CVE-2021-22779 vulnerability, which was identified in the course of the research, could allow a remote attacker to make changes to the PLC, bypassing authentication.

      It was established that the UMAS protocol, in its implementation prior to the version in which the CVE-2021-22779 vulnerability was fixed, had significant shortcomings that had a critical effect on the security of control systems based on Schneider Electric controllers.

      As of the middle of August 2022, Schneider Electric has released an update for the EcoStruxure™ Control Expert software, as well as for Modicon M340 and Modicon M580 PLC firmware, which fixes the vulnerability.

      This report describes:

      • the implementation of the UMAS protocol that does not use the Application Password security mechanism;
      • authentication bypass if Application Password is not enabled;
      • the principles on which the Application Password security mechanism is based;
      • mechanisms that can be used to exploit the CVE-2021-22779 vulnerability (authentication bypass where Application Password is configured).
      • operating principles of the updated device reservation mechanism.

      The conclusion provides remediations and recommendations from Schneider Electric on addressing the authentication bypass vulnerability, as well as Kaspersky ICS CERT recommendations.

      If you would like to request additional information or to share your thoughts on issues discussed in this article, please write to ics-cert@kaspersky.com.

      Snort rules are available on the Kaspersky Threat Intelligence (ICS Reporting) portal.

      Object of research

      UMAS (Unified Messaging Application Services) is Schneider Electric’s proprietary protocol used to configure, monitor, collect data and control Schneider Electric industrial controllers.

      UMAS is based on a client-server architecture. In the process of our research, we used the EcoStruxure™ Control Expert PLC configuration software as the client part and a Modicon M340 CPU controller as the server part.

      UMAS protocol

      Network packet structure

      UMAS is based on the Modbus/TCP protocol.

      Structure of the UMAS protocol

      Specifications of the Modbus/TCP protocol include reserved Function Code values that developers can use according to their needs. A complete list of reserved values can be found in the official documentation.

      Schneider Electric uses Function Code 90 (0x5A) to define that the value in the Data field is UMAS compliant.

      The network packet structure is shown below, using a request to read a memory block (pu_ReadMemoryBlock) on the PLC as an example:

      Each function includes a certain set of information in Data, such as offset from the base memory address, size of the data sent, memory block number, etc.

      Network communication

      UMAS also inherits the Modbus client-server architecture. A structural diagram of the communication between the client and the server is provided below.

      Communication between the client (EcoStruxure™ Control Expert) and server (PLC)

      In a UMAS network packet, Function Code 0x5A is immediately followed by the Session Key.

      UMAS network packet structure

      Below we examine the communication between a client and a server (a PLC, also referred to below as “device”) by analyzing a sample real-world traffic fragment.

      The screenshot below shows a packet containing the function umas_QueryGetComInfo(0x01) sent from the client (EcoStruxure™ Control Expert) to the server (the PLC).

      Structure of the function:

      TCP DATA – Modbus Header – 0x5A – session – 01(UMAS function code) – 00(data)


      The device should send a response to each request received. The screenshot below shows the device’s response to the client’s request:

      The status code is the status of execution by the device of the function sent to it by the client in the previous request. The value “fe” corresponds to successful execution of the function, “fd” – to an error. These values are present in each response sent by the device to the client’s request containing a function. The status code is always located immediately after the session key.

      Reservation procedure

      A “reservation” procedure is required to make changes to a PLC. The procedure acts as authentication.

      Only one client (e.g., an engineering workstation) can reserve a device at any specific time for configuration or status monitoring. This is required to prevent changes from being made to a device in parallel without coordination.

      The screenshot below shows a request from the engineering software to the PLC to perform the device reservation procedure in its basic variant that does not use the Application Password security mechanism.

      The umas_QueryTakePLCReservation(0x10) function is used to reserve a device.

      To reserve a device, the client sends a request containing the 0x10 function to the device. The request includes the name of the client reserving the device and the value equal to the length of that name.

      Session key

      Upon completing the reservation, the device sends the value of the new one-byte session key to the client. The key is subsequently used to authorize device modification requests.

      With the release of new firmware versions, the session creation mechanism has undergone some changes, namely:

      1. In firmware versions prior to 2.7, the session key for a Modicon M340 device after its reservation had the fixed value 0x01;
      2. In firmware versions 2.7 or later, the session key for a Modicon M340 device had a random value, i.e., from 0 to 0xFF, as the session key is 1 byte in size.

      Until the reservation procedure is completed, a service session with the value “0x00” is used. Functions that do not require reservation can be executed in that session.

      The device’s response, which includes the status code (0xfe) and the new session key, looks as follows:

      The status code “fe” means that the reservation procedure was successful.

      In this case, the device sends the new session key value. The new session key is used in all subsequent requests during the current “reserved” session.

      The following screenshot shows a request from a client to the device using the new session key immediately after the device’s successful reservation. In this example, the request uses the ex_GetPlcStatus(0x04) function.

      The reservation procedure plays the role of authentication when making changes to a device. This means that the mechanism is critically important from the security viewpoint.

      Issues related to reserving a device in the default configuration and using security features are covered in the following sections.

      UMAS protocol functions

      The UMAS protocol has numerous functions for communicating with target devices. Functions can be divided into two groups:

      1. Functions that require reserving the device. As a rule, these are functions that make changes to the PLC.
      2. Functions that do not require device reservation. Such functions do not make any changes to the PLC and do not affect its operation.

      An abbreviated list of functions available in the UMAS protocol is shown below. Information on the need to reserve the device for the functions listed below is relevant to firmware version 3.30 for Modicon M340 devices without the use of the Application Password security mechanism.

      Functions used in the device reservation process

      1. 0x10 – umas_QueryTakePLCReservation – reserves the device.
      2. 0x11 – umas_QueryReleasePLCReservation – releases the device from reservation.
      3. 0x12 – umas_QueryKeepPLCReservation – reservation status.

      Functions that require device reservation

      Initialization functions

      0x01 – umas_QueryGetComInfo – UMAS message initialization.

      Functions used to request information about a device

      1. 0x02 – pu_GetPlcInfo – requests information about the device
      2. 0x04 – pu_GetPlcStatus – queries the PLC status
      3. 0x06 – pu_GetMemoryCardInfo – requests information about the device’s SD card

      Functions for downloading and uploading PLC strategies

      A strategy is a set of instructions and data used by the PLC to perform its main function, that is, to control terminal equipment, e.g., to automate a certain industrial process.

      1. 0x30 – pumem_BeginDownload – initializes an upload from the PC to the PLC.
      2. 0x31 – pumem_DownloadPacket – uploads a strategy block from the PC to the PLC.
      3. 0x32 – pumem_EndDownload – ends the upload from the PC to the PLC.
      4. 0x33 – pumem_BeginUpload – initializes a download from the PLC to the PC.
      5. 0x34 – pumem_UploadPacket – downloads a strategy block from the PLC to the PC.
      6. 0x35 – pumem_EndUpload – ends the download from the PLC to the PC.

      Functions that do not require device reservation

      Function that reads information from device memory

      0x20 – pu_ReadMemoryBlock – reads PLC memory block.

      Function that writes values to device memory

      0x21 – pu_WriteMemoryBlock – writes PLC memory block.

      Functions that control the state of the PLC

      The following functions can be used to start or suspend the operation of the PLC. These functions do not require reservation if the Application Password security mechanism is not activated, in which case the device will successfully handle a request using a service session (0x00) (see Session key).

      Unless the Application Password setting is enabled, an attacker can use these functions to stop the PLC, thereby causing significant damage to the industrial process.

      1. 0x40 – ex_StartTask – Start PLC operation.
      2. 0x41 – ex_StopTask – Stop PLC operation.

      CVE-2020-28212: authentication bypass without Application Password

      The main issue with the basic reservation mechanism that does not use Application Password is that an attacker can use the session key to send requests and change the device’s configuration.

      In firmware versions prior to 2.7 for Modicon M340 devices, the session key has the same value each time the device is reserved and is equal to “0x01”. This means that attackers can make changes on the device by calling the relevant functions after reserving the device themselves or after the device has been reserved by a legitimate user.

      The attack workflow is shown in the diagram below:

      Remote threat actor attack workflow. Modicon M340 firmware version prior to 2.7,
      device reserved by an engineer

      If the device has not been reserved at the time of an attack, the attacker can use the umas_QueryTakePLCReservation(0x10) function to reserve the device in order to make changes to it.

      With Modicon M340 firmware versions 2.7 or later, the session key takes a random value after device reservation. However, the session key is one byte in length, which means there are only 256 possible session ID values. This enables a remote unauthorized attacker to brute-force an existing ID of the session between a legitimate user and the PLC.

      To carry out this type of attack, a remote attacker needs to send a series of network requests on port 502/TCP of the PLC with different session ID values and look at responses returned by the PLC. If the correct session ID was sent, the attacker will get status code 0xfe, which means that the request was fulfilled successfully. Otherwise, the attacker will get status code 0xfd.

      The operations described above can be implemented using any programming language – an attacker does not have to use EcoStruxure™ Control Expert or any other dedicated software to communicate with the device.

      Application Password

      To mitigate the CVE-2020-28212 vulnerability, the exploitation of which could allow a remote unauthorized attacker to gain control of the PLC with the privileges of an operator already authenticated on the PLC, Schneider Electric developed a new security mechanism. Schneider Electric believed that implementing an improved security mechanism that used cryptographic algorithms to compute the session ID and increasing the session ID length would prevent brute-force attacks that could be used to crack single-byte session IDs.

      Starting with firmware version 3.01 for Modicon M340 devices, Schneider Electric actively developed security mechanisms to prevent attackers from abusing UMAS functions to make changes to device operation. To implement authentication between the client and the device, Application Password should be enabled in project settings (“Project & Controller Protection”). The mechanism is designed to provide protection against unauthorized access, unwanted changes, as well as unauthorized downloading or uploading of PLC strategies.

      After activating the mechanism using EcoStruxure™ Control Expert, the client needs to enter the password when connecting to a device as part of the reservation procedure.

      Application Password also makes changes to the reservation mechanism itself. These changes are discussed in the sections below.

      Authentication bypass with Application Password

      Unfortunately, an analysis conducted by Kaspersky ICS CERT experts has shown that the implementation of the new security mechanism also has flaws. The vulnerability identified during the research, CVE-2021-22779, could allow a remote attacker to bypass the authentication mechanism and use functions that require reservation to make changes to the PLC.

      To grasp more fully what the shortcomings of the ‘improved’ security mechanism are, let’s look at the authentication and PLC reservation process in greater detail. The new security mechanism is based on exchanging a randomly generated byte sequence (a nonce) between the client and the server and subsequently producing a single session secret. The diagram below shows the sequence of requests sent and responses received.

      Device reservation sequence with Application Password enabled

      Below we look at the process in more detail.

      After establishing a TCP session, the EcoStruxure™ Control Expert software sends a request to the PLC (port 502/TCP) to read a memory block using UMAS function 0x20, which does not require authentication.

      Next, the client receives a response from the PLC. The memory block is needed for further computation since it contains two base64 strings that make up a password hash.

      After this, EcoStruxure™ Control Expert generates a random byte sequence (a nonce) that is 32 bytes in length and sends it to the PLC.

      In response to receiving the nonce, the PLC also sends a byte sequence (a nonce response) to EcoStruxure™ Control Expert, which is also 32 bytes long.

      Importantly, the nonce response computed on the PLC side depends only on the byte sequence received from EcoStruxure™ Control Expert (the nonce) and no additional random element is used to generate the response. In other words, the same response is always sent to the same nonce.

      In the next step, EcoStruxure™ Control Expert uses the same nonce and response to compute the SHA 256 hash, which is required to reserve the PLC.

      The hash is computed as follows:

      SHA256 (PLC nonce response + base64 strings (password hash) from PLC's memory block + EcoStruxure Control Expert nonce)

      Using the data from the above examples, the hash computation looks as follows:

      SHA256("\x25\xe4\x23\xb1\x5b\xa0\x5f\x47\xc0\xb5\x3c\xdf\x47\x86\x8e\x4e\x33\xe3\xb0\xa1\x10\xfd\x0d\x81\x22\x31\xa5\xa8\x5f\x7e\x93\x97" + “\x43\x47\x49\x33\x55\x53\x4f\x39\x49\x00\x43\x30\x69\x6e\x30\x6a\x38\x41\x4c\x78\x55\x3d\x0d\x0a\x31\x4f\x6d\x5a\x42\x33\x31\x77\x57\x57\x6c\x6c\x67\x47\x45\x4b\x2f\x75\x36\x45\x43\x7a\x66\x6f\x39\x48\x55\x76\x59\x69\x4e\x44\x6c\x6a\x2b\x73\x59\x77\x77\x71\x74\x47\x38\x3d” + "\xe7\x62\xed\xdd\x78\x4b\x61\xf7\x64\xca\xfa\x84\xaf\xc6\x7c\x5b\x40\x4f\x62\x10\xa8\xed\x31\x2b\x82\x94\xc4\x89\x96\x6f\xd4\x26") = 1bc23b84e0989643965ef082869d17d5a8398b82fbc8e2775419a8a807f5fe04

      Ultimately, PLC reservation is performed using the ASCII representation of the computer’s name and the SHA256 hash computed earlier.

      PWIN-FQIR7QT81KI + ‘\x00’ + 1bc23b84e0989643965ef082869d17d5a8398b82fbc8e2775419a8a807f5fe04

      If the request is successfully fulfilled, the PLC will return session ID (0xf8 on the screenshot below) to EcoStruxure™ Control Expert.

      This session ID will subsequently be used to send Security function (0x38) protected commands to the PLC.

      It can be seen from the above analysis of the PLC reservation process using the new and improved mechanism that the new method is by no means secure since all computation is performed on the client side (i.e., by EcoStruxure™ Control Expert), while the “secret” can be obtained from the PLC without authentication.

      The fact that the PLC always sends the same response to the same nonce received from the client is an additional shortcoming of the mechanism, which enables an attacker to carry out a Replay attack using network traffic between a legitimate client (the operator) and the server (the PLC) captured earlier in the process of PLC reservation.

      Updated reservation procedure with Application Password

      At the time of publication, Schneider Electric had released updates for EcoStruxure™ Control Expert software (version 15.1), Modicon M340 PLC firmware (version 3.50), and Modicon M580 PLC firmware (version 4.02). These updates fix the vulnerability described in the Authentication bypass with Application Password section.

      This section describes the updated reservation procedure used after the vendor had fixed the vulnerability.

      During the PLC reservation procedure, a total of 0x534 bytes are read from memory block 0x14 in two requests, using UMAS function pu_ReadMemoryBlock(0x20), which does not require authentication. In the earlier version of the reservation mechanism, that memory segment contained the password hash, but in the new version it contains a salt and a ciphertext.

      When the client (EcoStruxure™ Control Expert) has obtained the salt value for hashing, it can start the PLC reservation procedure. The client computes the SHA256 hash of the password entered by the user with the salt obtained at the previous step to compute the password hash.

      The next step is the nonce exchange between the client and the PLC.

      In the final step, the client computes the SHA256 hash that is to be used to reserve the device. The hash is computed from the PLC nonce, the password hash and the client nonce.

      The screenshot below shows a request from the client (EcoStruxure™ Control Expert) to the PLC to reserve the device using the SHA256 hash computed in the final step.

      In the earlier version of the reservation mechanism, the main problem was that the “secret” used to reserve the device was computed entirely on the client side (i.e., by EcoStruxure™ Control Expert). In the corrected implementation of the mechanism, memory block 0x14 of the PLC does not contain the password hash used to compute the “secret”, i.e., the final SHA256 hash.

      Conclusion

      Our analysis shows that the implementation of the UMAS protocol in Modicon M340 firmware versions prior to 3.50 had significant shortcomings that critically affected the security of automation systems based on Schneider Electric solutions.

      According to shodan.io data, the number of Modicon M340/M580 devices available online is greater than 1000. This is obviously just the tip of the iceberg.

      Vendor recommendations

      The vendor recommends following the remediation provided for EcoStruxure™ Control Expert in the SEVD-2021-194-01 security advisory and using the Application Password mechanism to ensure complete remediation of this issue.

      Kaspersky ICS CERT recommendations

      In addition to the recommendations provided by the vendor, Kaspersky ICS CERT strongly recommends monitoring critical UMAS functions at traffic level, for example, using IDS or dedicated solutions for monitoring industrial network traffic, identifying and analyzing network anomalies. It is obvious that such functions as device reservation, stopping the device or downloading/uploading strategies are critically important and can be abused by an attacker to disrupt the industrial process.

      Authors
      • Security Researcher, Kaspersky ICS CERT

      • Security Researcher, Kaspersky ICS CERT

      • Senior Security Researcher, Kaspersky ICS CERT