Security wall of S7CommPlus - Part 1

Introduction

Siemens PLC is often used in ISC industrial control systems to perform important logic actions of the operation process. New versions of Siemens PLC from s7-1500 and s7-1200V4.0 used an encryption protocol s7CommPLus to protect against replay attacks. The study below, it can be applied in the SCADA-Based OT Environments.

The example is set when the system is hacked and hackers break into the main Control Center. From there, set up a rogue control station to directly control siemens PLCs via siemens proprietary and the latest protocol is S7CommPlus.

To perform an attack on the new version of the PLC, the only way is to study the S7commPlus protocol and understand the entire handshake, authentication, and communication encryption process.

Environment Configuration

Environment

Basic environment for testing:

• PLC: s7-1200,  6E27 214-1BG40-0XB0
• Software: Tia portal V15.1
• Firmware: V4.3.1
• Wireshark: V3.6.5

Topology

Protocol framework structure

Through packet capture and analysis on Wireshark, we can see that the S7Comm-Plus protocol is implemented based on the OSI model as follows:

The frame structure of the S7CommPlus protocol roughly consists of three parts: header, data, and trailer. The header and trailer fields are fixed, and the data field has different structure and content.

Header and Trailer

The components and structure of the Header and Trailer are the same including Protocol ID - 1 byte, Protocol version (PDU type) - 1 byte, and Data length - 2 bytes, its structure is shown in the following figure.

Data

The Data field is the most complex and diverse field in the frame structure, through analysis the data field can be divided into 3 main parts: Integrity, D_header, and Data.

D_header

When the PDU type is 0x1 or 0x2, there is no 32-byte Integrity part in the data packet. When the PDU type is 0x3, there is an Integrity part in the data packet.

Data

The structure and content of the data part are related to the PDU type and opcode. The data part has many types and is relatively complex. For detailed analysis, you can read and parse the protocol using Wireshark.

Analyze the communication process

Handshake process

The basic process of interaction between the host computer (TIA) and the PLC is shown in the following figure.

• Start handshake: Initiate communication handshake, CR/CC packet

• TIA sends M1 packet to PLC to open session and uses CreateObject function to create ClassServerSession

• The PLC responds to the TIA request and responds to M2. M2 contains the firmware version, PLC model, session id, and 20 bytes ServerSessionChallenge.

• After the TIA receives the M2, with a random ServerSessionChallege received from the PLC (only the middle 16 bytes are used during the actual computation challenge = ServerSessionChallenge[2:18]) and associated with the public key. Use complex cryptographic algorithms (including XOR, hash like hmac-sha256, AES-CTR, AES-EBC, ECC...) to generate authentication data and respond to PLC with M3 packet. The important part of the authentication data is the structure of StructSecurityKey and SecurityKeyEncryptedKey which are 180 bytes in length.

• After the PLC receives the M3, it will use the private key to decrypt and authenticate the data, if the authentication is successful, it will reply to the TIA with the M4 data packet.

• After successful authentication, TIA sends data packets with active function to PLC. TIA uses a separate algorithm (using session_key) to compute the data content to obtain a 32-byte integrity part field and the PLC receives that functional data packet. The PLC then checks the integrity part field and performs the corresponding action function if the verification is passed.

Encrypted fields

It can be seen that the creation of encrypted fields in the M3 data packet is the key to the successful establishment of communication with the PLC, and subsequent integrity computation is the key to the successful manipulation of the PLC. Data encryption is a process with many complex encryption algorithms.

I will review the SecurityKeyEncryptedKey structure in the StructSecurityKey recognized by Wireshark and the analysis paper of the research team at Blackhat.

From the two images above, we can draw the following similarity:

• KDK ID Header (16 bytes): Symmetric key checksum | Symmetric key flags | Symmetric key internal flags
• Public key ID Header (16 bytes): Symmetric key checksum | public key flags | public key internal flags
• EG1, EG2, Nonce (60 bytes): Encrypted random seed
• IinitializationV (16 bytes): Encryption initialization vector
• Encrypted challenge, Encrypted KDK, Encrypted Checksum (56 bytes): Encrypted challenge

In the article, the algorithm for encrypting fields in SecuritykeyEncryptedKey is mentioned and it is implemented in the OMSp_core_managed.dll library. The article uses python's Ctypes module to call the OMSp_core_managed.dll DLL. Define the functions involved and construct the complete input parameters to complete the validation. From that base, we will perform dynamic debugging to clarify the cryptographic validation process, and locate the relevant functionality.

Dynamic debug

Environment setup

Software: I use during debugging: TIA portal V15.1, IDA 7.5, Wireshark.

Plugin: Findcrypt

I'm going to write an extremely simple PLC program that turns an LED on and off for research. And we can press Go online to set up the handshake process.

Implement Dynamic debug OMSp_core_managed.dll on IDA by attaching process TIA portal.

Debug

Reading the article can see that the program uses some hash functions hmac-sha256, sha256… So I used the plugin to define related functions and set breakpoints and reverse traces. Fortunately, I found a function that contains a 16 bytes challenge parameter that the PLC returns a TIA. Continuing to follow back, I found the function that handles the original 20 bytes challenge value.

Continue inverting and as a result, I have found the algorithm_1 handling function.

As you can see, this function takes as input challenge 16 bytes of input stored at [rdx] and truncated from byte[2:18] and 24 bytes of random KDK. The processing result at function f is concatenated with a 16 bytes challenge string through the hmac_sha256_update function. Then compute the session_key based on hmac_sha256 and store the result 24 bytes into buf_sessionkey at [rdi].

Exactly what was mentioned in the article.

Continuing to trace, we get the algorithm_5 processing function.

The function processes the input key and returns a value of 8 bytes fingerprint.

Looking at the program and compared to the article we can see that I have the correct positioning.

Set a breakpoint and look at the key passed in. The key input stored at [rcx] is a fixed 40 bytes Public key value according to the docs.

The algorithm takes 24 bytes from the public key and concatenates it with the string DERIVE via the sha256_update function. The hash then stores the returned 8 bytes result in a buffer stored at [rbx] , and we can see the result corresponding to the Public_key_checksum taken from Wireshark, concatenated with the 2 fields public_key_flags and Public_key_internal_flag, we get the Public key ID Header field.

The next run, we get 8 bytes Symmetric_key_checksum with a key input of 24 non-fixed bytes. Comparing with the information on Wireshark and the M3 packet as in the article, we can be sure that it is 24 bytes KDK. From there, we can determine the function algorithm_5 that returns the value for the Public key ID header field and the KDK ID Header field.

Analysis shows that the remaining 2 3, and 4 algorithms are related to a random function prng. If this function is identified, the rest of the algorithms will be found more easily. The value of 24 bytes passed to algorithm_1 and algorithm_5 is also generated from this prng function. Traceback and we find the prng and related functions.

From this prng function, I have determined algorithm_3. The fields of this algorithm are Nonce, EG1, EG2 which have also been defined by me.

TIA randomly generates 20 bytes of PreKey and encrypts the PreKey using an elliptic curve encryption algorithm with the public key, until the contents are the contents of EG1 and EG2. The values ​​of the 3 fields are stored and sorted in the correct position EG1, EG2, Nonce in the address buf_store_ECC at [r8].

Prekey value generated from algorithm_2.

Traceback from this value, we can determine the processing function algorithm_2. The KDF function returns an array containing 3 keys KEK, CEK, LUT and these 3 keys are used as keys in the AES algorithm. Here the program also randomizes 16 bytes using the prng function which is the IV (initialization vector) field in the M3 packet.

This value corresponds to the Encryption initialization vector on Wireshark.

From the above information, the last 3 fields encoding KDK, Challenge, Checksum were found. The encryption process challenge and KDK use the same algorithm, AES-CTR.

Check the result after encrypting the challenge stored in buf_encrypt at [rcx].

Similarly, we will get KDK encoding result

Finally, use the AES-ECB algorithm to encrypt the Encrypted_Checksum field stored in [rsi]. You can see that the encrypted fields are stored one after the other as in an M3 packet into a memory area.

The images of functions and variables above have been changed by me to facilitate the analysis process.

Summary

Through analysis, we have identified the coding fields, and by looking at the whole algorithm more clearly, we have also shaped its process.

Based on the above analysis of S7CommPlus communication protocol, it can be seen that the whole process of using authentication and encryption methods is very complex and cracking and bypassing is not easy. But because the authentication during communication is unilateral, i.e. TIA authenticates PLC but PLC does not authenticate TIA. If it is possible to create an M3 packet, we can completely spoof TIA to establish communication with the PLC and perform functions for the PLC such as start/stop…, and how this attack goes I'll see you in the next part.

References

• https://i.blackhat.com/USA-19/Thursday/us-19-Bitan-Rogue7-Rogue-Engineering-Station-Attacks-On-S7-Simatic-PLCs-wp.pdf
• https://i.blackhat.com/USA-19/Thursday/us-19-Bitan-Rogue7-Rogue-Engineering-Station-Attacks-On-S7-Simatic-PLCs.pdf