Security wall of S7CommPlus - Part 2
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.
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
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
integrity part of the
data must be calculated.
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
And parameters such as
sessionkey will be obtained through a
get_key function and passed into
Hash value is in a temporary structure called
data is updated through the function
integrity part field value is calculated using the function
Therefore, we have the following algorithm to compute the partial
integrity part field:
Hackers can control the logic operation of PLC.
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.
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.