A state transition-based industrial control system protocol fuzzing method

Abstract

The application discloses an industrial control system protocol fuzzing test method based on state conversion, and particularly, the communication flow of an upper computer and a PLC is analyzed, a protocol finite state machine of a communication interaction process is constructed, and the PLC is subjected to the fuzzing test by using test cases violating the finite state machine in a test process, so that the purpose of triggering unknown vulnerabilities of the PLC is finally achieved. The application uses the protocol finite state machine to guide the state conversion path of the fuzzing test process. The method for obtaining the test cases violating the original protocol finite state machine and then performing the fuzzing test on the equipment can efficiently find vulnerabilities. The confirmation method for the state conversion leading to the vulnerabilities can obtain the shortest state conversion path leading to the vulnerabilities.

Description

Technical Field

[0001] This invention relates to the field of industrial control system security, and in particular to a fuzzy testing method for industrial control system protocols based on state transitions. Background Technology

[0002] An industrial control system (ICS) is a computerized system used to manage, monitor, and control automated industrial processes. ICSs are widely deployed in critical infrastructure. A typical ICS can be divided into an enterprise resource layer, a production management layer, a process monitoring layer, a field control layer, and a field device layer. With the development of the Industrial Internet, any of these layers can be connected to the internet, which brings a series of security challenges.

[0003] Programmable Logic Controllers (PLCs), as a key component of the field control layer, are often used to regulate production processes and control critical infrastructure. Currently, many PLCs are connected to the internet due to practical needs, exposing them to the risk of attack. To identify unknown problems with PLCs as early as possible and prevent malicious attacks, vulnerability discovery in PLC protocols has emerged.

[0004] The traditional PLC protocol vulnerability discovery process is as follows: 1) Capturing the communication traffic between the PLC and the host computer; 2) Performing manual or partially automated protocol reverse engineering; 3) Describing the reverse engineering results; 4) Using the description to perform byte-level mutations and sending it to the target device; 5) Vulnerability triggering and verification. Traditional PLC protocol vulnerability discovery involves a significant amount of manual work, and its effectiveness heavily relies on the results of protocol reverse engineering. Therefore, this paper proposes a fuzzy testing method for state transitions in industrial control system protocols to address the existing problems. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of traditional industrial control system protocol fuzzy testing methods, which require extensive manual reverse engineering and whose effectiveness is limited by the inadequacy of protocol reverse engineering results. This invention proposes a state transition-based industrial control system protocol fuzzy testing method.

[0006] The objective of this invention is achieved through the following technical solution: a fuzzy testing method for industrial control system protocols based on state transitions, the method comprising the following steps:

[0007] S1, the seed acquisition phase, includes:

[0008] The system captures and saves the background flow rate of the host computer and PLC in the industrial control system under the connection state; it also captures and saves the flow rate of the host computer's different operations on the PLC in the industrial control system, with the operation sequence being to execute the operable functions in sequence starting from different functions.

[0009] Analyze the background traffic and the traffic of each operation to locate the function code position in the message. Based on the function code position, use the state machine extraction algorithm to extract the protocol finite state machine. Then, remove invalid state transitions. Specifically, remove all state transitions that exist in the background traffic except for the initial state transition. Use the remaining non-initial state transitions after removing invalid state transitions as test seeds.

[0010] S2, the mutation phase, includes:

[0011] Based on the existing protocol finite state machine and test seed, test cases are generated using mutation rules; the mutation rules are to violate the protocol finite state machine and use state transition paths that do not exist in the original protocol finite state machine as test cases to test the PLC.

[0012] S3, the testing and monitoring phase, includes:

[0013] Each test case is sent to the PLC under test in sequence and the sending order is recorded in the log. At the same time, the network service of the PLC under test is monitored, specifically the connectivity between the host computer and the PLC is continuously monitored. If the connectivity fails, it is considered that a denial-of-service problem may occur and the exception handling process is initiated.

[0014] In the exception handling process, the PLC under test is first powered off and restarted. Then, the test state transition paths that have been sent are all replayed using the test case sending order recorded in the log to check if the PLC still shows a denial-of-service situation. If the denial-of-service situation is reproduced, the operation is repeated. The total number of replays is set to confirm that the occurrence of the denial-of-service problem is not a random situation but a real vulnerability.

[0015] Furthermore, the background traffic is captured as follows: after connecting the host computer to the PLC, without performing any other operations, a packet capture tool is used to capture the data, and after waiting for a few seconds, the capture ends and the corresponding traffic file is saved.

[0016] Furthermore, the method for capturing the traffic of different operations is as follows: after the host computer establishes a connection with the PLC, it executes the operable functions sequentially from different functions, that is, it executes a certain function, then executes the next operable function, and finally disconnects, ends the capture, and saves the corresponding traffic file; this capture method indirectly obtains the state constraints of the protocol; during the function execution process, the state of the PLC will undergo several state transitions, and the operable functions include the initial essential functions and the subsequent optional functions.

[0017] Furthermore, the specific steps of the state machine extraction algorithm include:

[0018] (1) The protocol finite state machine is represented as F =<Set S,Set M,Set T> Let Set S represent the set of protocol states, Set M represent the set of messages, and Set T represent the set of state transitions; further expressed as Set S = {S0, S1, ..., Sn}, where S0 represents the initial state, S* represents the *th state; Set M = {M1, M2, ..., Mn}, where M* represents the *th message, and sending M* will cause the device to receive S*; Set T = {T1, T2, ..., Tm}, where T* represents the *th transition, and T* = ...<source=Sx,trigger=My,destination=Sy> This indicates that the device state changes from Sx to Sy via message My;

[0019] (2) Define a message pool Mp, check the function code of each message in turn. If it has not appeared before, add the message function code to Mp and consider that a new state has been triggered. Add the current state transition to Set T. If the function code has appeared before, check whether the current path has appeared before, that is, check whether the source and trigger in the current T have appeared in Set T. If the current T does not exist in Set T, add the current T to Set T. If it exists, skip the current message and check the next message.

[0020] (3) Follow the above steps to check until the last message has been checked, and then end the state machine extraction.

[0021] Furthermore, during the testing and monitoring phase, after confirming the existence of the vulnerability, it is further determined which state transitions led to the vulnerability. The determination method is as follows:

[0022] (1) Extend the time interval between sending each test case to identify the last state transition path that led to the vulnerability;

[0023] (2) In addition to the necessary state transitions, proceed with the subsequent state transitions according to the logs to identify the first state transition path that led to the vulnerability.

[0024] (3) Retain the first and last state transition paths that lead to the vulnerability, and remove the state transition paths that are the same as the two paths mentioned above that appear in the middle process;

[0025] (4) Send state transition paths in sequence. The path consists of the first state transition path that leads to the vulnerability, an intermediate state transition path, and the last state transition path that leads to the vulnerability. If no vulnerability is found, increase the number of intermediate state transition paths until the shortest state transition path that leads to the vulnerability is found.

[0026] Furthermore, during the testing and monitoring phase, the control service of the PLC under test is monitored, mainly by monitoring the changes in the PLC output waveform. If there is a long delay or the waveform changes to another waveform, it indicates that there is a vulnerability.

[0027] The beneficial effects of this invention are:

[0028] 1. This invention utilizes a finite state machine based on a protocol to guide the state transition path in the fuzzing process. Experiments demonstrate that the method used in this invention—which uses a finite state machine that violates the original protocol to obtain test cases and then performs fuzzing on the device—can efficiently discover vulnerabilities.

[0029] 2. The method for identifying vulnerabilities caused by state transitions proposed in this invention can obtain the shortest state transition path leading to the vulnerability. Attached Figure Description

[0030] Figure 1 This is the overall implementation flow of an industrial control system protocol fuzzy testing method based on state transition provided by an exemplary embodiment of the present invention;

[0031] Figure 2 This is an example of automatically extracting the state machine in the method of the present invention;

[0032] Figure 3 This is an example of the background traffic removal operation in the method of the present invention;

[0033] Figure 4 This is an example of a test state transition path in the method of this invention;

[0034] Figure 5 This is an example of testing real equipment in the implementation of the method of the present invention. Detailed Implementation

[0035] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0036] This invention provides a fuzzy testing method for industrial control system protocols based on state transitions, the basic architecture of which is as follows: Figure 1 As shown, the overall testing process includes the following three stages: seed acquisition stage, mutation stage, and testing and monitoring stage.

[0037] I. Seed Acquisition Stage

[0038] In this stage, the host computer and PLC in the industrial control system communicate directly. The first traffic captured during this communication is the protocol's background traffic. The capture method is as follows: after connecting the host computer to the PLC, without performing any other operations, use packet capture tools such as Wireshark or TCPdump to capture the data. After waiting a few seconds, stop the capture and save the corresponding traffic file. Background traffic consists of heartbeat packets and other traffic unrelated to specific functional operations. Since background traffic often does not affect the PLC's status, this traffic will be removed in subsequent steps.

[0039] Subsequently, the traffic flow of each operation with state constraints is captured. The capture method is as follows: after the host computer establishes a connection with the PLC, it executes operable functions sequentially, starting from different functions. That is, it executes one function, then the next operable function, and finally disconnects, ending the capture and saving the corresponding traffic flow file. This capture method indirectly obtains the state constraints of the protocol. During the function execution, the PLC's state will undergo several state transitions. Operable functions include the initial required functions and subsequent optional functions.

[0040] To improve testing efficiency, the acquired traffic files need to be preprocessed during the seed acquisition phase. The aim is to retain essential state transitions while removing irrelevant transitions that reduce testing efficiency. This requires extracting the protocol finite state machine (FDM) corresponding to each traffic file. The extraction method involves analyzing the background traffic and the traffic of each operation to locate the function codes within the messages. Based on the function code locations in the traffic files, a state machine extraction algorithm is used to extract the protocol FDM. The specific implementation process of the state machine extraction algorithm is as follows:

[0041] a. The protocol finite state machine can be represented as F =<Set S,Set M,Set T> Here, Set S represents the set of protocol states, Set M represents the set of messages, and Set T represents the set of state transitions. It can also be represented as Set S = {S0, S1, ..., Sn}, where S0 represents the initial state, S* represents the *th state; Set M = {M1, M2, ..., Mn}, where M* represents the *th message, and sending M* will cause the device to receive S*; Set T = {T1, T2, ..., Tm}, where T* represents the *th transition, and T* = ...<source=Sx,trigger=My,destination=Sy> This indicates that the device state changes from Sx to Sy via message My.

[0042] b. The state extraction algorithm is as follows: Define a message pool Mp, check the function code of each message in turn, if it has not appeared before, add the message function code to Mp, and consider that a new state has been triggered, and add the current state transition to Set T.

[0043] c. If the function code has already appeared, check if the current path has appeared before, that is, check if the source and trigger in the current T have already appeared in Set T. If the current T does not exist in Set T, add the current T to Set T. If it exists, skip the current message and check the next message.

[0044] d. Follow the steps above to check until the last message has been checked, then end the state machine extraction.

[0045] Figure 2 This is an example of a protocol finite state machine extracted from a real device. After obtaining the protocol finite state machine corresponding to each traffic file, invalid state transitions are removed. Specifically, all state transitions present in the background traffic, except for the initial state transition, are removed. The remaining non-initial state transitions after removing invalid state transitions are used as test seeds.

[0046] exist Figure 3 In the example shown, S0 is the initial state of the PLC under test, the triangle represents the irrelevant state to be eliminated, and the square represents the state to be retained for mutation.

[0047] II. Variation Stage

[0048] This stage requires generating test cases based on the existing protocol finite state machine and test seeds, using mutation rules. The mutation rule violates the protocol finite state machine, using state transition paths not present in the original protocol finite state machine as test cases to test the PLC. An example of mutation operation implementation is shown below. Figure 4In the example shown, the original state transitions of the PLC include: Set T = {T1, T2, T3, T4, T5, T6, T7, T8, T9}, where T1 =<source=S0,trigger=M1,destination=S1> The same applies to other state transitions; retain the test state transition path after the necessary state transitions, such as... Figure 4 Therefore, it can be represented as: S0->S1->S6->S5->S7, where S1->S6, S6->S5, and S5->S7 are all state transition paths that do not exist in the original protocol finite state machine.

[0049] III. Testing and Monitoring Phase

[0050] During this phase, each test case is sent to the PLC under test in sequence and the sending order is recorded in the log. At the same time, the network service of the PLC under test is monitored. The network service monitoring method is to continuously monitor the connectivity between the host computer and the PLC using the ICMP protocol. If the connectivity fails, it is considered that a denial-of-service problem may occur, and the exception handling process is initiated.

[0051] In the exception handling process, the PLC under test is first powered off and restarted using a smart switch. The interval between the power off and restart is n seconds (n is 2 in this embodiment). Then, the test state transition paths that have been sent are replayed using the test case sending order recorded in the log to check whether the PLC still shows a denial-of-service situation. If the denial-of-service situation is reproduced, the operation is repeated. The replay is repeated a total of three times (in this embodiment, it is set to replay three times) to confirm that the occurrence of the denial-of-service problem is not an accidental situation but a real vulnerability.

[0052] Since all test cases are sent to the PLC under test during replay, after confirming the existence of the vulnerability, it is necessary to further confirm which state transitions caused the vulnerability. The confirmation method is as follows:

[0053] a. Increase the time interval between sending each test case to identify the last state transition path that led to the vulnerability.

[0054] b. In addition to the necessary state transitions, proceed sequentially through the logs to identify the first state transition path that led to the vulnerability.

[0055] c. Retain the first and last state transition paths that lead to the vulnerability, and remove any intermediate state transition paths that are identical to the two paths mentioned above.

[0056] d. Send state transition paths sequentially. Each path consists of: the first state transition path leading to the vulnerability, an intermediate state transition path, and the last state transition path leading to the vulnerability. If no vulnerability is found, increase the number of intermediate state transition paths until the shortest state transition path leading to the vulnerability is found.

[0057] Furthermore, the control service of the PLC under test can also be monitored. The main monitoring of the control service is the change of the PLC output waveform. If there is a long delay or the waveform changes to another waveform, it indicates that there is a vulnerability. For example, if the original waveform is a square wave and it changes to a flat wave, it is considered that there is a vulnerability.

[0058] Figure 5 The figure shows the testing results of a real device from a certain manufacturer using the method of this invention. The solid lines in the figure represent the test case generation method using a finite state machine that violates the original protocol, and the dashed lines represent random state transitions.

[0059] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A fuzzy testing method for industrial control system protocols based on state transitions, characterized in that, Includes the following steps: S1, the seed acquisition phase, includes: The system captures and saves the background flow rate of the host computer and PLC in the industrial control system under the connection state; it also captures and saves the flow rate of the host computer's different operations on the PLC in the industrial control system, with the operation sequence being to execute the operable functions in sequence starting from different functions. Analyze the background traffic and the traffic of each operation to locate the function code position in the message. Based on the function code position, use the state machine extraction algorithm to extract the protocol finite state machine. Then, remove invalid state transitions. Specifically, remove all state transitions that exist in the background traffic except for the initial state transition. Use the remaining non-initial state transitions after removing invalid state transitions as test seeds. S2, the mutation phase, includes: Based on the existing protocol finite state machine and test seed, test cases are generated using mutation rules; the mutation rules are to violate the protocol finite state machine and use state transition paths that do not exist in the original protocol finite state machine as test cases to test the PLC. S3, the testing and monitoring phase, includes: Each test case is sent to the PLC under test in sequence and the sending order is recorded in the log. At the same time, the network service of the PLC under test is monitored, specifically the connectivity between the host computer and the PLC is continuously monitored. If the connectivity fails, it is considered that a denial-of-service problem may occur and the exception handling process is initiated. In the exception handling process, the PLC under test is first powered off and restarted. Then, the test state transition paths that have been sent are all replayed using the test case sending order recorded in the log to check if the PLC still shows a denial-of-service situation. If the denial-of-service situation is reproduced, the operation is repeated. The total number of replays is set to confirm that the occurrence of the denial-of-service problem is not a random situation but a real vulnerability.

2. The fuzzy testing method for industrial control system protocols based on state transitions according to claim 1, characterized in that, The background traffic is captured as follows: after connecting the host computer to the PLC, without performing any other operations, use a packet capture tool to capture the traffic, wait a few seconds, end the capture, and save the corresponding traffic file.

3. The fuzzy testing method for industrial control system protocols based on state transitions according to claim 1, characterized in that, The capture method for the different operations is as follows: after the host computer establishes a connection with the PLC, it executes the operable functions sequentially from different functions, that is, it executes a certain function, then executes the next operable function, and finally disconnects, ends the capture, and saves the corresponding traffic file; this capture method indirectly obtains the state constraints of the protocol; during the function execution process, the PLC's state will undergo several state transitions, and the operable functions include the initial essential functions and subsequent optional functions.

4. The fuzzy testing method for industrial control system protocols based on state transitions according to claim 1, characterized in that, The specific steps of the state machine extraction algorithm include: (1) The protocol finite state machine is represented as F =<Set S,Set M,Set T> Let Set S represent the set of protocol states, Set M represent the set of messages, and Set T represent the set of state transitions; further expressed as Set S = {S0, S1, ..., Sn}, where S0 represents the initial state, S* represents the *th state; Set M = {M1, M2, ..., Mn}, where M* represents the *th message, and sending M* will cause the device to receive S*; Set T = {T1, T2, ..., Tm}, where T* represents the *th transition, and T* = ...<source=Sx,trigger=My,destination=Sy> This indicates that the device state changes from Sx to Sy via message My; (2) Define a message pool Mp, check the function code of each message in turn. If it has not appeared before, add the message function code to Mp and consider that a new state has been triggered. Add the current state transition to Set T. If the function code has appeared before, check whether the current path has appeared before, that is, check whether the source and trigger in the current T have appeared in Set T. If the current T does not exist in Set T, add the current T to Set T. If it exists, skip the current message and check the next message. (3) Follow the above steps to check until the last message has been checked, and then end the state machine extraction.

5. The fuzzy testing method for industrial control system protocols based on state transitions according to claim 1, characterized in that, During the testing and monitoring phase, after confirming the existence of the vulnerability, it is further determined which state transitions led to the vulnerability. The determination method is as follows: (1) Extend the time interval between sending each test case to identify the last state transition path that led to the vulnerability; (2) In addition to the necessary state transitions, proceed with the subsequent state transitions according to the logs to identify the first state transition path that led to the vulnerability. (3) Retain the first and last state transition paths that lead to the vulnerability, and remove the state transition paths that are the same as the two paths mentioned above that appear in the middle process; (4) Send state transition paths in sequence. The path consists of the first state transition path that leads to the vulnerability, an intermediate state transition path, and the last state transition path that leads to the vulnerability. If no vulnerability is found, increase the number of intermediate state transition paths until the shortest state transition path that leads to the vulnerability is found.

6. The fuzzy testing method for industrial control system protocols based on state transitions according to claim 1, characterized in that, During the testing and monitoring phase, the control service of the PLC under test is monitored, mainly by monitoring the changes in the PLC output waveform. If there is a long delay or the waveform changes to another waveform, it indicates that there is a vulnerability.

Images