Attacking SCADA Part II: Vulnerabilities in Schneider Electric EcoStruxure Machine Expert and M221 PLC
This is part 2 of a two-part series. You can read part 1 here.
Summary
We present two vulnerabilities in EcoStruxure Machine Expert v1.0 and Schneider Electric M221 (Firmware 1.10.2.2) Programmable Logic Controller (PLC). All three vulnerabilities were disclosed to Schneider Electric and the details were released on 10 November 2020.
The first vulnerability (CVE-2020-7566) is a small space seed vulnerability. We are able to run an exhaustive key search to identify the encryption key that is used to encrypt the hashed password used to protect the application on the PLC. The malicious actor can use this encryption key to decrypt the encrypted hash password that is sent to the controller to unlock read/write protection.
In the second vulnerability (CVE-2020-7568), we discovered an alternate channel to bypass a read protection feature on the controller. This read protection feature is meant to protect the application that is deployed on the controller from being downloaded by unauthorized personnel. Our research shows that there is an alternate channel that can be used by a malicious actor to bypass the protection and download the application from the M221 controller. The malicious actor will be able to run more sophisticated attacks after he performs reconnaissance on the application on the M221 controller.
This research work is performed by our Global Emerging Technologies research team as part of our research into authentication and authorization implementations in ICS networks.
Introduction
In our previous work on “Attacking the Schneider Electric SoMachine Basic and M221 Programmable Logic Controller”, we have orientated the reader to the functionalities of the components in an industrial control systems (ICS) network. In this research, we continue to focus on the engineering software, EcoStruxure Machine-Expert Basic, and Schneider Electric M221 controller.
A controller contains control logic that is developed by the OT engineer to run a sequential process. Typically, the OT engineer will develop this control logic using the engineering software before deploying it on the controller. The controller will read the values from the input signals into the input variables, execute the logic accordingly, and write any output signals to the output variables. These variables are often referred to as “tags” in ICS.
Tags are often referred to using an address when the controller is communicating on the network. Hence, it’s not a trivial task to understand the function of these tags on the network. In order for an attacker to conduct a targeted attack, he will need to figure out the context of the tags that are used in the control logic. One way to make this process easier is to download the control logic from the controller and read the tags that are set to gain a complete understanding of the process that is deployed on the controller.
Application Protection
Schneider Electric EcoStruxure Machine Expert Basic is an engineering software. Under normal use, an OT engineer can use the Machine Expert-Basic to upload or download the application to run from the controller. The application contains the control logic that is deployed on the controller.
Schneider Electric has implemented a security feature in EcoStruxure Machine-Expert Basic to protect the application from unauthorized read and write. This is known as the “Application Protection” as shown in Figure 1.
Figure 1: Application Protection on EcoStruxure Machine Basic
There are two types of application protections available. Read protection protects the application from being read by any unauthorized personnel at the engineering workstation while the Write protection protects the controller’s application from unauthorized write. As can be seen from Figure 1, it is possible to set different passwords for each protection. For the purpose of our testing, we input the same password for both read and write protection.
After the passwords have been set, the engineer can save the application locally as a project file and deploy the protected application to the controller, anyone that attempts to communicate with the controller is prompted to enter the passwords as seen in Figure 2.
Figure 2: Application Protection in active for the M221 controller that we have set to be protected
In our research, we focus on finding the security flaws to bypass these application protections.
Attack 1: Exhaustive Key Search using a Small Space Seed (CVE-2020-7566)
In this section, we describe our discovery on the small space seed that is used to exchange keys between the engineering software and the controller to validate the application protection passwords. The use of a small space seed makes it possible for the attacker to do an exhaustive key search to obtain the encryption key if he has captured sufficient information on the network.
Under normal circumstances, an engineer will be required to log in and setup a session with the controller before making any administrative changes to the controller. This is done by using the “Login” button as shown in Figure 3. If the application protections are activated on the controller, the session initialization process will include two key exchange processes.
Figure 3: Login button on the engineering software. A login is required before the OT engineer can make any changes to the application on the controller.
In the first key exchange process, the engineering software generates a random encryption key to encrypt the hashed password. This encrypted hashed password will be sent to the M221 controller to verify that the engineering software is authorized to manage the protected application. The steps taken in this process are denoted in Figure 4 from Step 1 to Step 5. There are two inputs use in the key generation function to output this random encryption key.
The first input is a nonce. A nonce is a random number that is meant to be used only once in a cryptographic exchange. It is used to prevent replay attacks on past communications. The engineering software will send a request to the controller for a random nonce. Each login session generates a different nonce.
The second input is a pseudo-random seed. This seed will be generated by the engineering software. Based on our analysis, we noticed that the software uses the current timestamp as an input to a random number generator function to generate this random seed. Hence, the seed differs in most of the login sessions.
The output from the key generation function will be used as the encryption key to encrypt the hashed password using the XOR algorithm. Each login session will generate a different encryption key as the nonce and pseudo-random seed are supposed to be random in each session.
In the second key exchange process, the engineering software generates a secret key so that the M221 controller will be able to generate the same encryption key to decrypt the encrypted hash password. The steps taken are denoted in Figure 4 from Step 6 to Step 8.
The key generation function used in this process is identical to the function used in the first key exchange process. One of the inputs to the function is the same pseudo-random seed that is previously generated in the first key exchange process. However, the other input uses a hard-coded value “0x2” instead of the random nonce that is requested from the controller.
The output from the key generation function will be sent to the controller with the encrypted hashed password as shown in Step 7 in Figure 4. Using the secret key, the controller will be able to generate the same encryption key to decrypt the encrypted hashed password. If the decrypted hashed password is identical to the password deployed on the controller, the controller will grant access to the engineering software. A high-level view of the key exchange can be found in Figure 6.
Figure 4: A high-level view of how the key exchange works during the session initialization process.
We reversed engineered the engineering software to figure out the algorithm to generate the public key and encryption key. The pseudo-code for this key generation algorithm is shown in Figure 5.
Figure 5: The key generation algorithm used to generate public key and encryption key.
In our research, we were able to brute-force the seed and obtain the encryption key from the network packets that we have captured from the session initialization process. There are two security flaws that we have discovered to make this attack possible.
In the first security flaw, the random nonce and secret key are exchanged in clear. Hence, we are able to intercept and obtain the secret key from the network packets.
In the second security flaw, the seed that is used to generate both keys is only 2-bytes long. This means that there are only 65535 possible combinations of seed.
Once we have obtained the secret key from the network packet, it is possible for us to run an exhaustive key search using the algorithm shown in Figure 6 to find out the pseudo-random seed that is used during this key exchange process. The pseudo-code to generate the public key is presented as below.
Figure 6: Pseudo-code to brute force the seed
Once we have obtained the seed, we can use this seed and the nonce that we have extracted from the network packet to generate the encryption key. This encryption key can be used to decrypt the encrypted hashed password that we have extracted from the network packet using the XOR algorithm. Using the previous attack, it will be possible for an attacker to find the plain passwords used for application protection.
Attack 2: Bypass Protected Application using an Alternate Channel (CVE-2020-7568)
When the engineer requests to upload the application from the controller to the engineering workstation, the application data in transit will be encrypted if the application protection is activated. This helps to prevent any man-in-the-middle to sniff the data.
However, we discovered that we can use the same request payloads that is sent from the engineering workstation as a third-party directly to the controller to request for the application data. These payloads can be consumed by the controller successfully without any authentication, thereby bypassing any read protection in place. In our analysis, we also realized that the application data in transit will be sent in clear instead of being encrypted.
A high-level view of how these request payloads look like is shown in Figure 7.
Figure 7: A high-level view of how the request payload can be crafted
The attacker can conduct this attack anywhere on the same network as long as there is no engineering software logged on to the controller as the controller activates the read protection on the application once a session has been successfully set up.
Figure 8: A high-level view of how the attacker can download the protected application from the controller.
The response packets contain different parts of the application data that will need to be concatenated and saved as a zip file. This can be extracted using a unzip program such as 7zip. A proof-of-concept code is shown in Figure 10. The actual request payloads are removed from the proof-of-concept code.
Figure 9: A proof-of-concept code used to download the project from the read-protected controller without any authentication.
Once the attacker has extracted the unprotected application successfully from the concatenated packets, he can perform reconnaissance on the application and identify all the critical tags that will help in advance in other attacks on the controller.
Mitigations
The general mitigation provided by the manufacturer is to patch the engineering software, update the firmware of the controller, and block the port on the firewall or disable the protocol. We will like to add on to the recommended mitigations provided.
For the first vulnerability, it is recommended to the customers to use two different complex passwords for different application protections. In any case, where the algorithm does not use any random salt, it will not be easily guessed by the attacker that the passwords are identical. Complex passwords also remain as a good policy to prevent dictionary attacks.
For the second and third vulnerabilities, it is recommended to take additional steps to ensure only the engineering workstation and authorized clients can communicate to the PLC directly. This helps to reduce the perimeter surfaces that can be leveraged by the attackers to communicate with the controllers.