Security wall of S7CommPlus - Part 2

Briefly

In the previous article, I clearly described the structure of the S7CommPlus protocol and debugged OMSp_core_managed.dll to understand the cryptographic authentication and communication handshake process. From there, we find the position of the functions to calculate the main parameters such as Symmetric key checksum, public key checksum… From that information, in this article, I will build an authentication package from those parameters and proceed to the next step in the process after validation that is to perform some logic operations on the PLC.

Packet Construction

The authentication handshake begins by sending a session open packet to retrieve the challenge from the PLC. Run the test program to get the important parameters.

Retrieved information has been displayed like firmware version, CPU, challenge... Note that the screen shows two important values ​​to watch out for: session ID and the object ID. The session ID is 4 bytes in size and the value is always of the form 0x000003xx. The xx value is calculated by taking the 2nd byte of the object ID + 0x80. And this value will be in every packet sent. From the challenge we received, some values ​​like KDK are obtained during debugging. The position of the functions participating in the algorithm. Build the complete parameter and we will calculate the fields in SecurityKeyEncryptedKey as follows.

And the result of successful authentication is returned.

But at this stage, we are only completing the first step. To perform the next major operations on the PLC, such as start/stop, the integrity part of the data must be calculated.

Perform PLC start/stop through TIA Portal and capture packets during communication. You can view the following important data.

To perform the PLC start/stop function, TIA sends an S7CommPlus packet to implement SetVariable on the NativeObject.theCPUexeUnit_Rid object. This packet contains a 32 bytes Integrity part field in the data. It is generated by an algorithm with the Data. This field is to check the correctness of the data. Only when this value is calculated correctly and the PLC confirms it, our start/stop command will be executed.

In the previous article, we mentioned algorithm 1, if you read carefully you will see that I do not use the results of this algorithm in the authentication handshake. As it will be used during the creation of the integrity part field.

This algorithm produces a result called sessionkey which is 24 bytes long. Through the reverse process, the sessionkey value is stored in a structure as follows. This struct address is stored in a global variable var_global_struct_store_data.

And parameters such as size, sessionkey will be obtained through a get_key function and passed into hmac_sha256_init function.

Hash value is in a temporary structure called struct_init_hmac.

Then data is updated through the function hmac_sha256_update.

And the integrity part field value is calculated using the function hmac_sha256_calc.

Therefore, we have the following algorithm to compute the partial integrity part field:

Scenario 1

Hackers can control the logic operation of PLC.

Scenario 2

Hackers can take advantage of the rogue station to back up the program and change it ... and then re-download the modified program to the PLC device.

Summary

If you want to perform any of the above attack tests on the PLC over this protocol, the basic process is divided into two steps: a successful handshake to establish communication and the correct calculation of the Integrity Part  specific control. This series of articles has completed protocol analysis, dynamic debugging, and demonstration testing, which will hopefully be useful to your research colleagues. Please critique or correct me if there are mistakes to make the following articles better.