Attacking industrial networks (Siemens)

A week ago in the first part of this post we were able to visualize a general description of PLCs (language and hardware) and some vulnerabilities, as well as a general description of associated industrial networks, field devices, HMI, and DTU. Now that we have assimilated these concepts about industrial networks and their associated elements, let's go into detail on how they communicate.

This post presents an analysis on the Siemens PLC environment, in particular the communication protocol known as S7CommPlus. This protocol allows communication between Siemens endpoints such as TIA Portal (the manufacturer's engineering software), and PLCs such as the S7-1211C that has been used for the experiments performed by Hui, H., McLaughlin, K., & Sezer, S. The analysis uses the WinDbg and Scapy. tools. The anti-replay mechanism used in the protocol is investigated, including the identification of the specific bytes required to create valid network packets. From the experimental analysis, new exploits are identified, including cryptographic key manipulation.

Subsequently, exploits are demonstrated that allow impersonating an existing communication session, denying an engineer's ability to configure a PLC, making unauthorized changes to PLC states, and other potential integrity and availability violations. Several mitigation recommendations will also be proposed taking into account the concepts seen above.

Introduction

Siemens is one of the leading vendors in the world, and for this analysis the S7-1211C controller was investigated. As we recall the Stuxnetattack demonstrated how compromised PLCs could cause a physical impact. The worm first spread from a removable drive inside a uranium enrichment plant in Iran and infected an "air-gapped"network machine. The worm then spread across the network using four zero-day vulnerabilities and digital signatures from two legitimate companies. Apart from the sophisticated infection and propagation mechanisms used by Stuxnet, a key aspect from an ICS point of view was that it only targeted a few specific PLC models, namely the Siemens S7 315 and 417, which were used to control the centrifuges in the enrichment process. Stuxnet determined whether a target was a Siemens PLC by checking the model number, configuration details and downloading the device's program code. If the check failed, Stuxnet did not perform any further attacks, possibly to avoid detection of its actions. Otherwise, it proceeded to update the PLC's main cycle block with malicious code to increase the rotation frequency of connected centrifuges to damaging levels, while fooling the operator by injecting false data into the HMI. The attack changed the way the industry viewed security.

Related research

Programming or configuring a PLC usually requires proprietary software from the manufacturer. Devices in a process control network can communicate with PLCs via serial connections or, more recently, via Ethernet, through TCP/IP-based protocols. Whereas the protocols used during normal operations may be openly standardized e.g. Modbus TCP or vendor specific.

The following chart shows a timeline with the release of various PLC models along with discovered vulnerabilities and their exploits and the specific protocol versions.

Beresford demonstrated a number of attacks on the S7-1200 PLC, e.g., replay attack, authentication bypass, starting or stopping a PLC, etc. The work was based on PLC firmware v2, which does not include any security mechanisms in the communication protocol.

"PLC inject" exploits the S7Comm protocol (the latest generation of the Siemens protocol, in which an anti-replay mechanism is not included) and has the ability to add codes to the main program cycle of a PLC without interruption of services. It was also demonstrated that it was possible to introduce a network proxy into a Siemens S7-300 PLC as a backdoor to the process control network.

Spenneberg demonstrated a worm-like attack, called PLC Blaster, which can propagate between PLCs. The worm exploits vulnerabilities in the S7CommPlus protocol, and in a newer version of the protocol with an anti-replay mechanism. The malicious program is loaded into a PLC via an Ethernet cable. The upload also includes bytes of network packets needed to program other PLCs. The affected PLC then automatically scans the network and connects to other PLCs and attempts to load the malicious code into them.

In 2017, L. Martin-Liras presented a comparative analysis between three proprietary protocols used by PLCs. The three protocols involved were the S7Comm protocol, the UMAS protocol (used by Modicon PLCs) and the Opto Comm protocol (used by Opto PLCs). Existing information on the vulnerabilities of the protocols was investigated. The analysis also investigated the possibility of performing various attacks on PLCs, including DoS, firmware alteration and user program change, etc. A more recent publication in 2018 by L. Ghaleb documented an investigation into S7 protocol vulnerabilities specifically, which demonstrated Man-in-the-Middle attack, command modification and replay attack on an S7-400 PLC using the S7Comm protocol.

In 2018 the authors published a preliminary work related to the research that was taken as a reference to make this post. It was demonstrated that it was possible to perform a general network attack, based on ARP-poisoning, on the S7 -1211C PLC (firmware 4) and TIA Portal. The authors also demonstrated that a 7-byte "S7-ACK" " packet, "03 00 00 07 07 02 f0 00", can be exploited for session hijacking and DoS attack.

In 2019, Biham delved deeper into the research of Siemens S7 protocols and they demonstrated attacks to reprogram S7 PLCs, which were named Rogue7.

S7Commplus Protocol

The S7CommPlus protocol facilitates the transfer of critical operational and configuration information such as PLC logic, diagnostic information, configuration details and data block values between PLCs and engineering software. The following image shows the dissected protocol stack of a packet carrying S7CommPlus data as viewed in Wireshark.


TCP port 102 is used for all S7 communications. The protocol runs in ISO over TCP (TPKT), and Connection Oriented Transport Protocol (COTP). If an operator initiates a connection to a PLC from the TIA-Portal, he would do so by pressing the "Go online" button.


After pressing it internally, the following steps take place:

• The TIA Gateway issues an "Identify All" packet from the Discovery Protocol and Profinet Basic Configuration (PN -DCP) to the network
• All PLCs or devices respond to the TIA Portal with a PN-DCP packet "Identify OK".
• TIA Portal initializes a TCP handshake with the PLC, and the PLC will respond.
• The TIA Gateway and the PLC exchange COTP connection information.
• TIA Portal sends the first S7 packet (connection request from TIA).



• The PLC responds with a packet containing a 1-byte and a 20-byte anti-replay challenge.



• TIA Portal responds with a packet containing an anti-replay byte and a 132-byte array, which is the anti-replay response.

(Representation of byte positions)

  •The TIA Portal sends packets with the requested action to the PLC, along with a integrity check of 20 bytes in each packet

The pictures in steps 5-7 show the TIA Gateway and the PLC exchanging S7 request, challenge and response packets, where special bytes are involved in the process. For example 1C9C381.If any of the S7CommPlus packets do not include the correct anti-replay bytes or integrity check values, the other end of the connection will send a TCP reset packet and the session will be terminated.

Once the "Go online" button is clicked on the TIA portal, a session will be initiated using the S7 protocol. The operator can upload custom programs, diagnose PLC-related problems, view real-time data from PLC data blocks, configure communication between the PLC and other devices, etc. During a period online with the S7 -1211C PLC, several packets are sent to the TIA Portal during idle time specifying details and live status of the PLC, e.g., cycle time, memory usage, etc.


Byte Anti-Replay

The S7CommPlus protocol uses a 1-byte value in the anti-repeat mechanism, which has been used since version 3 of the S7-1200 firmware. When the TIA Portal initiates a connection to a PLC, the PLC sends a challenge byte in the range 0x06 to 0x7f. The TIA Portal will respond to the PLC with a response that is calculated by adding the value 0x80 to the challenge. For example, if the PLC challenge is 0x08, the TIA Portal response would be 0x08 + 0x80 = 0x88, as shown in 6 and 7. The challenge is in byte position 25 and the response is in bytes 24 and 29 of the respective packets.

Encryption in the response packet

Since firmware version 4, the TIA Portal response packet has to include several bytes in addition to the single anti-replay byte discussed above. In 2017 Cheng discovered two 16-byte ciphers involved in the packet, where the second cipher depends on the first one. The two 16-byte values start at bytes 235 and 291 of the S7 response packet, as shown in 7. The first encryption is an XOR operation, while the second is generated by a more complex algorithm.

Function of the "Encryption" Package

After sending the response packet to the PLC, the TIA Portal will start sending bytes related to the TIA Portal functions, which are called "function packets". All these packets have to include a 32-byte "encryption" value, as shown in 8. This "encryption" is found to be an integrity check facilitated by the Hash-based Message Authentication Code (HMAC) and is related to the anti-replay byte. Cheng proposed the possibility of starting and stopping a PLC by exploiting the protocol, but however does not provide details describing the vulnerabilities of the protocol, and merely points out that the packet integrity checking function is a "cipher". Biham subsequently identified the underlying mechanism used in the S7 protocol as an HMAC and discovered that the key for the HMAC is exchanged using an ElGamal elliptic curve type key exchange.

However, the protocol-specific mechanisms were not described, e.g., each field of the anti-replay response is loosely identified with pseudocode, while the detail of the algorithmic execution is missing. Similarly, in the HMAC packet calculation function, two sets of HMACs are discovered with two different keys that were not previously identified.

Analysis of the S7CommPlus protocol

A manual analysis was performed using tools such as Scapy and WinDbg to examine the communication between the TIA Portal and the PLCs during several different communication sessions. In the first experiment, by manually inspecting the packets, including byte manipulation using Scapy, it was discovered that the bytes labeled in steps 5 - 8 served a number of specific purposes, which will now be explained. As an example, steps 5 - 7 show the TIA Gateway and PLC exchanging S7 request, challenge and response packets, while at 8 shows a subsequent "function packet". See also step 4, which shows the general exchanges in a session.

In step 5, 1C9C381M indicates a server session number that is generated by TIA Portal each time a communication session is started. However, this number can be reused and is not checked by the PLC. At 16 2913981 there is another session number, or "PC" session number, which is generated each time TIA Portal is opened (i.e., the first time TIA Portal is opened or after the computer is rebooted, hence the name "PC" session number). This number can also be reused.

01 c9 c3 81 is the value of the server session repeated directly in hexadecimal. The segment highlighted in the dot, in contrast to other bytes in the same packet, is significantly different for each session. It seems more likely to have been generated by a hash or pseudo-random function. The PLC checks these three blocks, the 9-byte and 8-byte segments 132 bytes respectively from step 7 and immediately sends a TCP packet with a reset flag if the byte blocks are not what the PLC expected; otherwise, communication continues. These bytes are generated by a specific algorithm. After the response from the TIA Portal, if the connection is accepted, the PLC sends an S7CommPlus packet. The S7CommPlus packet will contain information related to the functions provided by TIA Portal.

Sophisticated attackers could identify these bytes and use this information to further exploit the protocol.

TIA-Portal Analysis

WinDbgwas used to perform an analysis of TIA Portal. In this section is described in summary the process performed during the experiments. The function that runs a search for accessible devices in TIA Portal to generate S7CommPlus traffic was used for this purpose.

Reference Diagram TIA-Portal Analysis

To support the analysis, several breakpoints were established during the communication between the software and the PLC. A manual analysis process identified that the byte array changes significantly each time TIA Portal makes a request. This 20-byte block has no obvious relationship to the payload of the connection request packet, as confirmed by sending the exact same connection request packet to the PLC using Scapy.

The first challenge for whoever carries out this analysis is to identify the part of the ecosystem susceptible to attack and the entry point of the analysis, for which some tipsare given below.

To start the analysis, the TIA Portal search function is used once without any breakpoints and a complete communication session is generated (terminated by a TCP reset packet from the PLC). By manually initiating a breakpoint using WinDbg in the software, and then using the "s" command to search for the 20 bytes of the PLC in memory, the memory address containing this 20-byte block can be identified. This memory address could be located with a single "s" search, or often only the area that stores the entire S7 challenge packet received is located.

Another lookup must be done using an access breakpoint and trace the specific address to which this 20-byte array is written. Once this address is identified, it will not change until the TIA Portal is restarted. An access breakpoint, "breakpoint A", will be established at this address. After initializing another S7 communication using the TIA Portal, it was found that breakpoint A was accessed by two different locations, both of which are functions that involve copying the 20 -byte block to another address. The first function copies the address pointed to by breakpoint A, while the second function copies the bytes to a specific address. Therefore, to continue the investigation, two other access breakpoints, breakpoint B and breakpoint C, were established for each of the two identified addresses.

It was discovered that breakpoint B points to the 3rd byte address and breakpoint C stores the 3rd to 18th byte of the 20-byte array. This 16-byte value (bytes 3 to 18), or "challenge matrix", was found to play an important role for the rest of the byte generation process. In addition, the two memory locations pointed to by breakpoints B and C were found to be involved in the byte generation for the S7CommPlus response and function packet, respectively.

It is at this point that the dll, "OMSp_core_managed.dll" first appears and the addresses pointed to by breakpoint A, B and C are within the range of this dll. During analysis, it was confirmed that this module, or dll, is where all of the anti-replay byte generation takes place.

We invite you to read Vulnerability Analysis of S7 PLCs: Manipulating the Security Mechanism. The complete paper on the research on which this post is based and the detailed work on TIA-Portal can be found in the references.

discusses in detail topics such as:

• TIA Portal S7 Response Package
• Manipulable bytes
• First encryption
• Second encryption
• Finite Field Augmentation Algorithm
• Algorithm A480
• TIA-Portal Feature Packs
• Integrity Check

HMAC

After exchanging S7 challenge and response packets, S7 function packets will be sent. These packets include the purpose and detail of the communication and as seen in step 8 one of the packets containing control information sent by TIA Portal is shown. Each packet must include the 32 "Encryption" bytes (as Cheng calls them) before the payload, as shown in the byte delineation. It was found in this analysis that this 32-byte block is actually an HMAC integrity check for the packet. This integrity check serves two purposes: to ensure that the payloads are not tampered with; and to authenticate the sender (since the keys for HMAC are only known to the hosts that are involved in the connection). To generate this 32-byte value, two HMAC calculations were found.

The first is used to generate the key for all subsequent HMACs. The second is used to sign all function packets. Both HMACs are based on the same hashing algorithm as the rest of the mechanism. The following graphic shows how both HMACs generate the integrity bytes.


First HMAC

The calculation of the first HMAC is performed before sending the S7 response packet to the PLC. The plaintext of the HMAC consists of an 8-byte value and the 16-byte challenge matrix, read from the breakpoint C

Below is a sample pseudocode for the generation of 8 bytes, which is essential for the integrity check of the S7 function. This algorithm is not identified as a standardized algorithm, so the pseudocode is generated by an analysis of the assembler code. This analysis is instructive from a security point of view, since the 8-byte generation algorithm is an essential part of generating the integrity byte.


The combined 24-byte value is then signed using a 24-byte key generated in sector Ⓕ of the TIA-Portal reference diagram. The 32-byte output of the HMAC will be reduced to a 24-byte value, which will be stored and used as the key of the second HMAC.

Second HMAC

The second HMAC is used to generate the actual integrity check bytes, which are inserted into the function packet sent by both parties. Here it has been identified for the first time how the key of the second HMAC is the result of the first HMAC , and furthermore which part of the payload of the S7 function packet is used as input of the second HMAC. The length of the function packet is not always the same, but the 32-byte HMAC of the packet always starts at the 13th byte of the packet. The entry of this HMAC comprises all bytes following the HMAC in the packet, i.e., starting from the 45th byte, excluding the packet footer which is normally the last four bytes (e.g., in step 8 it is "72 03 00 00" at the end of the packet). As the length of each packet and the information it contains may vary, the length and content of the footer vary accordingly. However, to reproduce the packet, given that the key is known, a simple trial and error method could identify which byte is needed as HMAC input.

Potential holdingss

The above analysis of the S7CommPlus protocol and TIA Portal reveals the possibility of exploiting the protocol and software. Several validated exploits are discussed below, as well as possible additional attacks that could be carried out by an attacker sufficiently motivated to further analyze the findings presented above and proceed to develop malicious exploits.

Unauthorized changes in PLC status

Since all actions performed in the TIA Portal are sent to the PLC using the S7 protocol, using the findings of this research it may be possible to cause interruptions in a number of processes, including: reprogramming a PLC, changing the value of a PLC variable, setting the password of a PLC, and changing the state of the PLC (from running state to stopped state, and vice versa). For demonstration purposes, the scope of the current work has focused on whether it is possible to remotely change the state of a PLC, i.e., stop a running PLC. Experiments have shown that this can be achieved using two S7 function packets in addition to the anti-replay response, which includes the 132 bytes identified in step 7.


This image shows one of the spoofed function packages required to stop a PLC. The spoofed packet is generated based on the findings documented in the TIA-Portal Analysis section. Apart from the anti-replay byte (step 6), the integrity check bytes and the sequence number, all other bytes are the same in the two packets (one normal and one spoofed). It is worth mentioning again that even in different S7 sessions, all anti-replay bytes can be generated for any forged packet based on the same encryption keys and required bytes that will remain constant based on the hashes in Ⓓ and Ⓔ and Ⓕ boxes in the TIA-Portal Reference Diagram.

As mentioned, it is also possible to reprogram a PLC using the S7 protocol. Although there is a built-in copy protection mechanism, as long as the attacker can identify the relationship between the PLC serial number that is sent along the PLC logic and the PLC logic itself, an attack to reprogram the logic may be feasible.

DoS Communication

Apart from exploiting the normal functionality provided through TIA Portal, the findings have been shown to enable a DOS attack by sending crafted packets that establish and maintain a new S7 session to a PLC. This will prevent the TIA Portal from connecting to the PLC. This exploit is possible because the S7-1211C will not allow a new session to be started if a previous session already exists.

To apply this exploit it is assumed that there is no current session between the PLC and the TIA Portal. A host on the same LAN as the PLC can initiate a TCP connection to the PLC using the usual handshake and COTP packet exchange. By responding to the PLC challenge packet with a crafted packet containing the appropriate anti-replay bytes, followed by "S7-ACK" packets, the attacker can prevent a genuine connection from the TIA Portal. In order to keep a normal session alive, for example to ask the other end to wait while a process is running, either end connection can respond with such an S7 -ACK packet, seemingly indefinitely.

This exploit is possible because the "S7-ACK" packet, "03 00 00 00 07 02 F0 00", lacks anti-replay or integrity check functions, and can be used to respond to any S7 packet. Therefore, the session can be kept alive without the attacker obtaining any additional information. Although the PLC will continue to execute the pre-programmed logic, it is not possible to stop, reconfigure or reprogram it. A manual reboot can terminate the existing session, however a compromised host or device on the network could restart a new DOS session. This attack could be critical on its own, but could also enable a larger scale attack.

Session hijacking

The exploit described above assumes that there is no connection between the TIA Portal and the target PLC. However, this exploit could be combined with a traditional network attack, using crafted exploit packets along with ARP poisoning, to hijack a session to the PLC and cause a DOS so that the TIA Portal cannot reconnect. The authors have previously documented how session hijacking via ARP poisoning can work in this context. This can be accomplished by actively dropping all packets from the engineering software after stealing the S7 session, which causes the TIA Portal side of the connection to terminate. At the same time, the PLC side of the session can be kept alive by an attacker creating and sending S7-ACK packets. During such an attack, one option is to use excessive ARP responses to overwhelm any further ARP packets after the session is stolen. However, to avoid generating too much ARP "noise", the stolen S7 session could be terminated and replaced by a new DOS session, as described in the previous section. This attack accomplishes two things:
1) A smaller network "footprint" would be generated compared to session hijack via ARP poisoning.
2) It is possible to perform the DOS attack without waiting for the legitimate session to end, since a DOS session cannot be started if there is a legitimate one.

Elimination of the main program

A new exploit based on the S7CommPlus protocol has been found that can manipulate PLC logic and delete the Main Object block of S7 PLCs -1200 and causes TIA-Portal to provide incomplete or incorrect PLC information. It can be produced by replaying S7 packets captured under an abnormal use case.

The following describes the exploit replay steps, including packet generation, packet replay and the expected behavior from the generation of the packets that will be replayed as the exploit:

• Create a new project in TIA-Portal and add a PLC to the project with the firmware version of the target PLC (which can be obtained via the LLDP broadcast of the PLC or by logging in with the PLC).
• Load a default project (having only an empty Main object block) into the test PLC (a PLC having the same firmware version as the target PLC).
• Make sure that the PLC is in Shutdown state.
• Delete the Main Object block in the project and start a redy capture, and then load the project with the "Software (changes)" option. End the capture after the PLC terminates the session using a TCP packet with the Reset and Finish flags set.
• Extract the entire packet sent by the TIA-Portal for use in the script, which was sent in the previous communication

Sending (replaying) these captured packets to a target PLC, which has the same firmware version, which is in the shutdown state, will cause abnormal behaviors. Packets captured from different firmware, will cause different behaviors on a different firmware version. This exploit was tested on S7-1211C DC/DC/DC, firmware versions v4.1.3 and v.4.2.3.

For v4.1.3, the capture can be replayed as-is, and the PLC will restart the connection after the crafted packets are sent to the PLCs. The exploit can have the following behaviors, depending on the PLC configuration and state:

• When connecting to the infected PLC, the PLC cannot be put into the running state. If a user tries to download the custom code from the TIA-Portal to the PLC, the portal will indicate that the program between the PLC and the PLC is the same without displaying any error. However, the PLC is running without the Main Object Block, i.e. it does not perform any action. A possible solution is to disconnect and download the complete configurations to the PLC using the download option "Hardware and Software (changes only)". A window to synchronize the program will be displayed before the download, showing that there are differences between the logic in the PLC and the project in TIA Portal.
• When connected, the PLC cannot be put into a run state. If a user tries to download the custom code to the PLC, a synchronization window will be displayed before downloading.Also, no error will be displayed or an error saying "The block of main object does not exist".
• When connected, the PLC can be put into a running state. However, no logic will actually be executed in the PLC, and all program blocks will be shown as "only exist offline" in TIA-Portal. It is necessary to synchronize before downloading.

The user can put the PLC in the execution state. However, no logic will be executed in the main object block, but the cyclic interrupt or hardware interrupt can still be executed. If the user attempts to activate "monitoring" on the main object block while online (a TIA-Portal option that provides real-time PLC diagnostic information), the error "Internal system error (error code:0xCF000AF0700008002)..." will be displayed. Internal error: Referenced UnFunctionalObject does not exist".

A possible solution is to download the project to the PLC, and manual synchronization of the custom program will be necessary.

During testing, on two occasions the PLC went into an unrecoverable state after several captures were played back on the device repeatedly. The only viable solution in this situation is a factory reset.

Unfortunately, no screenshots of the exact packet sequences required were saved, as the behavior appears to be somewhat random and unpredictable.

Recommendations

As we saw, at least two hashes play an important role in the anti-replay mechanism. It was discovered that the input of these hashes could be manipulated by modifying the memory used by the software. This vulnerability allows an attacker to generate an S7 session that requires only 17 of the 150 "anti-replay" bytes in the S7CommPlus response packet instead of 150 bytes (the 132-byte, 8-byte and 9-byte blocks, plus the anti-replay byte). In addition, all the keys involved, whether for the First Cipher and Second Cipher, or the HMACs in the function packets, remain constant with respect to the input hashes. These two problems significantly reduce the potential security provided by the algorithm, as well as the apparent waste of resources. In the short term, adopting the security measures proposed below could limit the ability of an attacker to carry out similar exploits without significant design changes.

Changing the hash algorithm input

Some bytes exchanged between the TIA Gateway and a PLC are not used, nor is there an obvious impact for those bytes on communication. Consider the following findings:

• The server session and PC session, labeled in step 5, appear to have no purpose in the protocol and can be reused in different sessions, which defeats the purpose of a session number.
• It has been shown that the 16-byte "challenge matrix" in the 20-byte challenge sent by the PLC plays an important role in the anti-replay mechanism. However, it has not been determined that the remaining 4 bytes influence the anti-repetition mechanism.
• In the TIA-Portal S7 response packet, the bytes tagged at step 7, are generated before the value of 132 bytes. However, they remain constant with respect to the two hash values and no relation to the anti-replay mechanism is discovered.

Accordingly, it is proposed that one option to limit an attacker's ability to generate a viable S7 packet is to include some of the above bytes in the anti-replay mechanism. For example, it is suggested to include the server session and the remaining four bytes of the challenge matrix in the hash algorithm that generates the encryption keys, along with a brief history of the challenge matrix as part of the input to generate the anti-replay bytes. This will not remedy the threat of an attacker using reverse engineering techniques in software to obtain the input and algorithm used in the anti-replay mechanism, but anyone attempting to do so will need to generate the full 150 anti-replay bytes, including determining the keys in each attack, and be able to obtain previous communication sessions from the TIA Portal.

Limit the duration of the session

During analysis, it was discovered that a TCP session will remain alive until the TIA Portal terminates communication, does not acknowledge TCP keep alive packets or S7 packets sent by the PLC, or sends the wrong anti-replay bytes. For example, if a breakpoint is set in TIA Portal during communication with the PLC, legitimate S7CommPlus packets will no longer be sent.

In the meantime, the PLC will periodically send TCP keep alive packets and will not terminate the communication as long as the TIA Portal responds with the TCP keep alive packet. This increases the time available for any potential attacker to perform a deeper analysis at each stage of the communication.

In addition, the S7 -ACK packet can be exploited to perform a denial of service attack, through resource exhaustion, since the amount of resources dedicated to communication in a PLC is limited.

One possible mitigation would be a PLC firmware upgrade to ensure that PLCs disconnect from an inactive S7 session (a session containing only S7 -ACK packets) or after not receiving any legitimate S7 packets after a specified period of time, unless the operator configures the PLC otherwise.

Other recommendations

The following are some recommendations to keep PLC protected against threats or at least mitigate the risks taking into account what we have seen in this post and in its first part:

• Safety first: As industries consider safety as a major factor when designing, upgrading or operating any PLC, safety must be paramount. This should consider hardware, software and networks. Companies should elaborate a more detailed risk assessment, answers and standardizations before implementing any PLC project. An example could be: Do not consider a firmware upgrade of an old PLC because there is no planned shutdown of the production line.
• Cybersecurity is everyone's responsibility. All employees should always be aware and concerned about security. Employees should immediately report any unsafe practices, unsafe devices or suspicious behavior.
• Roles and authentication: Privileges to access information and devices must be properly restricted and well considered before assigning them to employees. Privileges should be well validated, controlled, logged and monitored (use unique IDs or access credentials). Unauthorized or unmonitored activity should be prevented or at least minimized. Users should only have access to their work and related daily tasks. Automatic log review and monitoring of users could also help.
• Daily review and comparison: as companies are so concerned about safety before and during the operation of production lines, they should be more concerned about the integrity of the files running on PLCs or HMIs. This should be done using a software tool that compares the ladder logic to the original trusted master file before starting new production lines. There is always the possibility of someone sabotaging the logic or creating dormant malware within the ladder logic code that goes undetected.
• Remote access and IoT (Internet of Things): should be restricted to certain devices, areas or sometimes disabled. If necessary, it should only be enabled for a limited time and used by trained internal personnel from an approved, monitored and controlled device; all communications should be filtered and verified. Systems or devices that do not need to be connected to other networks, including the Internet, should be adequately segregated and isolated to prevent any threat.
• USB ports must be physically disabled on HMIs (human machine interfaces) and any associated PCs. Only authenticated and approved USBs should be allowed to be used by administrators. Malware such as Stuxnet spreads through a SCADA network via infected USB storage devices.
• System log: should be generated and maintained for a reasonable time in case they are needed if something goes wrong.
• Periodic system auditing and periodic penetration testing.
• System intrusion detection: which should also include "traditional" perimeter protection (e.g. antivirus, firewalls, etc.). They should always be kept up to date and turned on.
• PLCs in general must be physically rugged and secure. Don't just focus on securing certain field devices. Securing the entire system is critical and mandatory.

Conclusion

In this series of posts, we have provided an overview of PLCs: their languages and hardware, as well as an overview of the industrial networks associated with them, HMIs and DTUs. We have summarized the main vulnerabilities of devices based on these devices, also examples were given based on other research on how to apply exploits on these vulnerabilities. Using the S7CommPlus protocol, it has been shown that an attacker with network access can send packets to a PLC, read a challenge, calculate the response and create integrity checks on subsequent packets to maintain a valid session. This allows an attacker to create packets that will be accepted by the PLC, for example to cause a PLC to halt, start CPU logic that has previously been stopped by a legitimate user, hijack an existing legitimate session between a PLC and the TIA Portal (shown to cause a DOS), and potentially other problems such as reprogramming the CPU.

Compared to Cheng's paper “The spear to break the security wall of S7CommPlus”, this research provides a more detailed analysis describing the anti-replay mechanism of the S7CommPlus protocol, including new information on the two symmetric key encryptions involved in the 132-byte block and the HMAC in the function packets.
In addition, new insights are provided on the generation of anti-replay bytes, including details of the algorithms used and how to manipulate the generated keys.

In the meantime, the authors of those papers have proposed a number of new mitigation steps not previously proposed in related research. These steps can be undertaken to make such exploits more difficult to discover and execute by a determined attacker; namely, adopting a timeout approach to mitigate potential DOS, and changing the way the hash algorithm is implemented to ensure that manipulation of TIA Portal functions is more difficult for an attacker to achieve. Similar to cybersecurity research in other fields, the authors hope that the information provided on conducting this vulnerability scan will provide the research community with deeper insight towards understanding attacker approaches and viable mitigation strategies.

Readings of Interest

• https://claroty.com/team82/research/white-papers/evil-plc-attack-weaponizing-plcs
• Peter M. D. Scully Mark J. Neal “Positional: A Collaborative Host-based Architecture for Securing Industrial Networks” Department of Computer Science, Aberystwyth University, Wales, United Kingdom
• Yong Wang, Jinyong Liu, Can Yang, Lin Zhou, Shuangfei Li, Zhaoyan Xu “Access Control Attacks on PLC Vulnerabilities”Department of Information Security, Shanghai University of Electric Power, Shanghai, China & Palo Alto Networks, California, CA, USA
• https://www.youtube.com/watch?v=93lyRgZYxKw
• https://youtu.be/ocOEiNp-8K0