Fuzz Testing Method for Protocol Implementation Module of Industrial Control System Monitoring Software

Abstract

The present invention provides a fuzz testing method, system, electronic device and medium. The method includes determining a seed message and dynamic fields in the seed message; adjusting the dynamic fields in the seed message to form a mutated message; inputting the mutated message into the program under test, monitoring the state of the program under test, and obtaining a test result. By determining the dynamic fields of the seed message and adjusting the dynamic fields to form a mutated message, the present invention omits the step of adjusting the fixed fields, effectively improving the formation efficiency of the mutated message.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular, to a fuzz testing method for a protocol implementation module of an industrial control system monitoring software. Background Art

[0002] With the development of software systems, their complexity has been increasing continuously, and the chances of running errors or security risks have also increased accordingly. In order to improve the stability and security of software program operation, special testing methods and testing systems are often required to verify software programs.

[0003] Fuzz testing is a method for discovering software vulnerabilities by providing unexpected inputs to a target system and monitoring abnormal results. It can reveal important bugs in a program, verify real-world error patterns, and prompt potential attack channels that should be blocked before the tested program is actually attacked.

[0004] Existing fuzz testing methods and program products, due to their wide application scope, are not well adapted to passive tested programs (i.e., tested programs that actively communicate with devices and passively receive response data from devices), and there are problems such as cumbersome testing and low vulnerability discovery efficiency. Summary of the Invention

[0005] The present invention provides a fuzz testing method, system, electronic device, and medium for a protocol implementation module of an industrial control system monitoring software, to solve the defect of low software vulnerability discovery efficiency in the prior art and achieve effective discovery of software vulnerabilities.

[0006] The present invention provides a fuzz testing method for a protocol implementation module of an industrial control system monitoring software, including:

[0007] Instantiate dynamic fields in a seed message according to a test protocol, and retain fixed fields to form at least one mutated message, where the seed message is generated according to a communication protocol between a device and a tested program, and the field values corresponding to the dynamic fields are configurable device operation parameters or user parameters;

[0008] Run the tested program according to the mutated message, monitor the state of the tested program, and obtain a test result, where the test result includes the correspondence between the mutated message and the state of the tested program.

[0009] A fuzz testing method for a protocol implementation module of an industrial control system monitoring software according to the present invention, wherein the seed message is selected from multiple communication messages according to a priority weight, the multiple communication messages are response messages obtained from the device, and the response messages are generated by the device under the trigger of the program under test; the priority weight is determined according to any one or any combination of the communication message length, the communication message interaction depth, and the number of program basic blocks executed by the program under test for processing the communication message.

[0010] A fuzz testing method for a protocol implementation module of an industrial control system monitoring software according to the present invention, wherein the dynamic fields in the seed message are a set of fields determined by comparing multiple seed messages and having different field values in the multiple seed messages.

[0011] A fuzz testing method for a protocol implementation module of an industrial control system monitoring software according to the present invention, wherein the steps of obtaining the test result include:

[0012] If it is determined that the program under test runs abnormally, then the abnormal result of the program under test and the corresponding mutated message are used as the test result;

[0013] If it is determined that the program under test runs normally, then update the mutated message, and return to input the mutated message into the program under test and monitor the status of the program under test.

[0014] A fuzz testing method for a protocol implementation module of an industrial control system monitoring software according to the present invention, wherein the fuzz testing method further includes:

[0015] Update the mutated message, and return to the step of inputting the mutated message into the program under test and monitoring the status of the program under test.

[0016] A fuzz testing method for a protocol implementation module of an industrial control system monitoring software according to the present invention, wherein the fuzz testing method further includes:

[0017] If it is determined that the program under test runs abnormally, restart the program under test.

[0018] A fuzz testing method for a protocol implementation module of an industrial control system monitoring software according to the present invention, wherein the instantiation of the dynamic fields in the seed message according to the test protocol includes:

[0019] Extract the format information of the dynamic fields in the seed message; the format information includes the communication protocol corresponding to the seed message;

[0020] According to the format information of the dynamic fields in the seed message, instantiate the dynamic fields in the seed message.

[0021] The present invention also provides a passive fuzzy testing system, comprising:

[0022] A mutation module, instantiating the dynamic fields in the seed message according to the test protocol and retaining the fixed fields to form at least one mutation message, wherein the seed message is generated according to the communication protocol between the device and the program under test, and the field value corresponding to the dynamic field is a configurable device operation parameter or user parameter;

[0023] The test module runs the program under test according to the variation message, monitors the state of the program under test, and obtains a test result, wherein the test result includes a corresponding relationship between the variation message and the state of the program under test.

[0024] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the fuzzy testing method for a protocol implementation module of industrial control system monitoring software as described in any one of the above are implemented.

[0025] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the fuzzy testing method for a protocol implementation module of industrial control system monitoring software as described in any of the above.

[0026] The fuzzy testing method, system, electronic device and medium for the protocol implementation module of the industrial control system monitoring software provided by the present invention eliminate the step of adjusting the fixed fields by determining the dynamic fields of the seed message and adjusting the dynamic fields to form a variant message, thereby effectively improving the efficiency of forming the variant message, providing a basis for the testing and vulnerability mining process, and achieving the beneficial effects of simple testing and improved vulnerability mining efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0028] Figure 1 It is a flowchart of the fuzzy testing method provided by the present invention;

[0029] Figure 2 It is a schematic diagram of the phase flow of the fuzzy testing method provided by an embodiment of the present invention;

[0030] Figure 3 is an interactive schematic diagram of a passive fuzzy testing device provided by an embodiment of the present invention;

[0031] Figure 4 It is a timing schematic diagram of the fuzz testing method provided by an embodiment of the present invention;

[0032] Figure 5 It is a schematic structural diagram of an electronic device provided by the present invention. Detailed implementation manners

[0033] To make the objectives, technical solutions and advantages of the present invention clearer, the technical solutions in the present invention will be clearly and completely described below with reference to the accompanying drawings in the present invention. Apparently, the described embodiments are some but not all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art without making creative efforts based on the embodiments in the present invention belong to the scope of protection of the present invention.

[0034] The following combines Figures 1 - 4 to describe the fuzz testing method of the present invention.

[0035] As Figure 1 shown, an embodiment of the present invention provides a fuzz testing method for a protocol implementation module of an industrial control system monitoring software. The execution subject of this method can be a test system, a test program running in the test system, or a controller, which is not limited in the present invention. This method includes the following steps:

[0036] Step 100: Instantiate the dynamic fields in the seed message according to the test protocol, and retain the fixed fields to form at least one mutated message, where the seed message is generated according to the communication protocol between the device and the program under test, and the field values corresponding to the dynamic fields are configurable device operating parameters or user parameters;

[0037] Step 200: Run the program under test according to the mutated message, monitor the status of the program under test, and obtain a test result, where the test result includes the correspondence between the mutated message and the status of the program under test.

[0038] In this embodiment, the seed message is essentially one of all possible communication messages that can be triggered by the program under test.

[0039] The determination of the seed message can be achieved through the following ideas:

[0040] Traverse all communication operations of the program under test to obtain all possible communication messages that can be triggered by the program under test;

[0041] Evaluate the priority weight of each communication message as a mutation of the seed message; the priority weight of the seed message is jointly determined by the length of the message, the interaction depth corresponding to the message, and the coverage information triggered when the message is parsed and processed by the monitoring software;

[0042] Define the probability of each seed message being selected for mutation using the priority weight of the seed message; select the seed message in real time through a probability-based seed message selection algorithm.

[0043] The determination of the dynamic fields in the seed message can be achieved through the following idea:

[0044] Analyze and compare the communication data packets generated by repeated operations to obtain the field information that needs to be dynamically adjusted, that is, the dynamic fields.

[0045] The instantiation of the dynamic fields is based on the communication protocol regulations. After instantiation, a finite number of mutant messages can be formed for use in step 200, or a mutant message general formula, set, or generation model can be formed, so as to be able to provide any number of mutant messages for use in step 200.

[0046] In step 200, the state of the program under test includes normal operation and abnormal operation. The state of the program under test with abnormal operation can be software crashes, such as process termination, freezing, restarting, etc.

[0047] It should be noted that in the method provided in this embodiment, the program under test is a client program, that is, the program under test interacts with the device / user. In a typical application scenario, the program under test is a monitoring software for monitoring a specified device;

[0048] Specifically, different from conventional test objects such as server programs, it is only necessary to actively send test data. The test object in this embodiment is a client, and it is necessary to first initiate a request and then can passively receive test data.

[0049] Therefore, this embodiment further provides a proxy mechanism for inputting mutant messages into the program under test, which solves the problem of difficulty in automating the test protocol client object.

[0050] Taking the test system as the execution subject of this embodiment as an example, the proxy mechanism is described as follows.

[0051] The test system runs a GUI (Graphical User Interface) proxy to control the communication behavior of the software under test (such as monitoring software); the test system runs a traffic proxy to control the software under test to receive response messages;

[0052] Select any one or more response messages as seed messages according to the set conditions;

[0053] The response message refers to the message sent by the user / device and received by the software under test.

[0054] The beneficial effects of this embodiment are as follows:

[0055] By determining the dynamic fields of the seed message and adjusting the dynamic fields to form a mutated message, the steps of adjusting the fixed fields are omitted, effectively improving the formation efficiency of the mutated message, providing a basis for the testing and vulnerability mining processes, and thus achieving the beneficial effects of simple testing and improved vulnerability mining efficiency.

[0056] According to the above embodiments, in this embodiment:

[0057] The seed message is selected from multiple communication messages according to a priority weight. The multiple communication messages are response messages obtained from the device, and the response messages are generated by the device under the trigger of the program under test; the priority weight is determined according to any one or any combination of the communication message length, the communication message interaction depth, and the number of program basic blocks executed by the program under test for processing the communication message.

[0058] The response message is a multiple of communication messages returned by the device triggered by the program under test under different control instructions;

[0059] The dynamic fields in the seed message are a set of fields determined by comparing multiple seed messages and having different field values in the multiple seed messages.

[0060] The multiple seed messages are multiple seed messages returned by the device triggered by the program under test under the same control instruction.

[0061] In this embodiment, the following idea can be used to obtain multiple communication messages triggered by the program under test in response to different set operations:

[0062] For the program under test, obtain the operation process that can generate network communication behavior;

[0063] According to the recorded operation process, construct an automated trigger tool;

[0064] Use the automated trigger tool to run the program under test to trigger communication and capture network communication data packets;

[0065] Preprocess and filter the captured network communication data packets to obtain a set of communication network data packets of the program under test;

[0066] Parse the set of network data packets to obtain communication messages.

[0067] This acquisition idea can solve the problems that traditional vulnerability mining tools do not support monitoring software for passive communication and the difficulty in automating the management of the GUI operation process during the testing process.

[0068] This embodiment can compare the multiple seed messages and determine the dynamic fields in the seed message through the following idea:

[0069] For a set of network communication data packets, use a protocol analysis framework to analyze and process to obtain the format information of each communication message. And for each (request, response) pair in the communication packet, construct a communication dictionary, where the KEY in the dictionary is the request message and the VALUE is the response message.

[0070] By analyzing and comparing the communication data packets generated by repeated operations, obtain the field information that needs to be dynamically adjusted, that is, the dynamic field.

[0071] In this embodiment, after the test of a seed message is completed, the next seed message can be selected and updated to continue the test until the set test stop condition is reached.

[0072] In some preferred embodiments, the interaction depth can be understood as the number of different messages sent during the communication interaction process. For example, in a certain session, client A sends 10 different messages to server B, then the interaction depth of the 10th message is 10. Another example, in a certain session, client A sends 3 different messages to server B, then the interaction depth of the 3rd message is 3 and the interaction depth of the 2nd message is 2.

[0073] The beneficial effect of this embodiment lies in:

[0074] Based on the three parameters of the message length, interaction depth, and coverage rate of the program under test of the communication message in this embodiment, determine the priority weight of the communication message as the seed message for subsequent mutation, and can give priority to determining the communication message with a larger message length, a deeper interaction depth, and a higher coverage rate of the program under test as the seed message, so that the test process after the mutation of the seed message can cover more modules of the program under test, involve deeper and more interaction objects, and compress the design redundancy of the program under test, thereby effectively improving the test efficiency.

[0075] According to any of the above embodiments, in this embodiment:

[0076] The steps of obtaining the test result include:

[0077] If it is determined that the program under test runs abnormally, then use the abnormal result of the program under test and the corresponding mutated message as the test result;

[0078] If it is determined that the program under test runs normally, update the mutated message, and return to input the mutated message into the program under test and monitor the status of the program under test.

[0079] Alternatively, the fuzz testing method further includes:

[0080] Update the mutated message, and return to the step of inputting the mutated message into the program under test and monitoring the status of the program under test.

[0081] Determine that the program under test runs abnormally and restart the program under test.

[0082] That is to say, the steps of inputting the mutated message into the program under test, monitoring the state of the program under test, and obtaining the test result have two implementation schemes.

[0083] The first is the crash-stop test scheme, and the specific steps are as follows:

[0084] The steps of obtaining the test result include:

[0085] If it is determined that the program under test runs abnormally, then use the mutated message that causes the program under test to run abnormally as the test result;

[0086] If it is determined that the program under test runs normally, then update the mutated message and return to the step of inputting the mutated message into the program under test and monitoring the state of the program under test until the set test stop condition is met.

[0087] The test process of the first scheme terminates when the program under test crashes, or when the program under test always runs normally but the set test stop condition is reached, such as having traversed all possible mutated messages, reaching the set test time, or reaching the set number of test times.

[0088] There are two possible test results for this scheme, that is, the program under test crashes on a specific mutated message, or the program under test runs normally under a specific set of mutated messages.

[0089] The second is the loop test scheme, and the specific steps are as follows:

[0090] The steps of obtaining the test result include:

[0091] If the program under test runs abnormally, then:

[0092] Add the mutated message that causes the program under test to run abnormally to the test result;

[0093] Restart the program under test;

[0094] Update the mutated message and return to the step of inputting the mutated message into the program under test and monitoring the state of the program under test;

[0095] If the program under test runs normally, then update the mutated message and return to the step of inputting the mutated message into the program under test and monitoring the state of the program under test until the set test stop condition is met to obtain the test result.

[0096] The test process of the second scheme terminates when the test environment reaches the set test stop condition, such as having traversed all possible mutated messages, reaching the set test time, or reaching the set number of test times.

[0097] The essence of the test results of this solution is to record the content of specific mutated messages that cause the program under test to crash. On this basis, it is also possible to further record the content of specific mutated messages that enable the program under test to run normally.

[0098] The beneficial effect of this embodiment is as follows:

[0099] By monitoring the state of the program under test and then performing judgment and update to form the test results, this embodiment solves the problem of difficult input of malformed data (i.e., mutated messages) into the monitoring software automatically.

[0100] According to any of the above embodiments, in this embodiment:

[0101] The step of instantiating the dynamic fields in the seed message according to the test protocol includes:

[0102] Extract the format information of the dynamic fields in the seed message; the format information includes the communication protocol corresponding to the seed message;

[0103] According to the format information of the dynamic fields in the seed message, instantiate the dynamic fields in the seed message.

[0104] In this embodiment, the acquisition of the format information can be achieved based on the following idea:

[0105] Analyze the private protocol of the seed message and extract the format information and communication rules of the private protocol.

[0106] The step of adjusting the dynamic fields in the seed message needs to be carried out according to the format information and communication rules of the private protocol. Therefore, except for special cases, the number of generated mutated messages is limited. Thus, the test stop condition can be that all possible mutated messages have been tested.

[0107] The beneficial effect of this embodiment is as follows:

[0108] By parsing the private protocol in this embodiment, the format information of the seed message is obtained, thus providing a basis for the subsequent automatic generation of mutated messages and solving the problem of low efficiency in vulnerability mining caused by unknown private protocol formats and unknown interaction processes.

[0109] According to any of the above embodiments, a specific implementation manner for the industrial control field is provided in this embodiment as follows.

[0110] First, a description of this specific application scenario is as follows.

[0111] A typical application scenario is the testing of monitoring software in the field of industrial control. With the deep integration of informatization and automation in the industrial control field, in recent years, industrial control systems have increasingly adopted Internet technology solutions with low cost and good interoperability, such as communication protocols based on TCP / IP. This behavior of directly applying Internet technology solutions has broken the original closedness and isolation of industrial control systems, thus increasing the threat of attacks from the Internet. In fact, various network attack events against industrial control systems are increasing day by day, exposing a large number of security vulnerabilities in industrial control systems. Actively discovering and fixing security vulnerabilities in the monitoring software of industrial control systems has become an important security protection measure.

[0112] Since the monitoring software in industrial control systems actively communicates with devices, passively receives response data from devices, and uses a dedicated protocol for communication, and the communication content is highly related to the operation process of the operator on the GUI, traditional vulnerability mining tools such as Boofuzz, Peach, and AFL do not support the automated management of the GUI operation process during the testing of monitoring software with passive communication, it is difficult to automatically input malformed data into the monitoring software, and it faces the challenge of low vulnerability mining efficiency brought about by the unknown private protocol format and unknown interaction process of industrial control systems.

[0113] This embodiment proposes a vulnerability mining method of passive fuzz testing for the monitoring software in industrial control systems to effectively discover security vulnerabilities existing in the protocol implementation of the monitoring software of industrial control systems. Fuzz testing is a black box method for mining software security vulnerabilities and detecting software robustness. It is achieved by inputting illegal fields into the software and observing whether the software under test is abnormal.

[0114] This embodiment provides a fuzz testing method for the protocol implementation module of industrial control system monitoring software aiming at the security of the protocol implementation module of industrial control system monitoring software, to solve the problems that traditional vulnerability mining tools do not support the automated management of the GUI operation process during the testing of monitoring software with passive communication, it is difficult to automatically input malformed data into the monitoring software, and the problem of low vulnerability mining efficiency brought about by the unknown private protocol format and unknown interaction process of industrial control systems, and to achieve the purpose of effectively discovering security defects existing in the protocol implementation module of industrial control system monitoring software.

[0115] Such as Figure 2As shown in the figure, the method flow involved in this embodiment includes a preprocessing stage and a fuzz testing stage. (1) Preprocessing stage: Analyze the GUI of the monitoring software, and collect GUI operations that can trigger network communication behaviors; analyze the fields of the private protocol and generate communication rules, perform field division on the communication packets, and establish a communication template to assist in automated communication; (2) Fuzz testing stage: Combine the communication packet length, interaction depth, and path coverage information during parsing in the monitoring software, define the priority weight of each packet as a seed mutation, and propose a seed packet selection mechanism based on weight; based on the packet field format information obtained in the preprocessing stage, generate a packet mutation template, and generate mutated packets in real time; provide an automated packet input mechanism based on TrafficProxy and GUIProxy, and input the mutated test packets to the monitoring software for processing; use the EventLog service based on the Windows system to check whether the monitoring software vulnerabilities are triggered. The present invention aims at the monitoring software in the industrial control system and effectively discovers the security defects in the implementation of its protocol module.

[0116] This embodiment specifically includes the following steps:

[0117] Step 1, set logic or code according to the GUI interface of the monitoring software, and obtain the operation process that can generate network communication behaviors.

[0118] In step 1, the GUI interface of the preselected specific monitoring software can be analyzed to obtain the GUI operation sequence that can cause network communication behaviors, including: Button click, mouse coordinate click, shortcut key operation, input box filling, selection box selection, etc.

[0119] Step 2, use each operation process obtained in step 1 to generate a small program for automatically triggering GUI operations based on the AutoIT framework.

[0120] In step 2, the designed small program for automated GUI operations can support the following events: monitoring software startup command, button click, mouse coordinate click, selection box selection, Menu selection, shortcut key input, text box filling, killing the monitoring software process, etc.

[0121] Step 3, use all the operations in step 1 to capture the network communication packets triggered by them through a packet sniffer, and preprocess and filter to obtain a set of network packets for communication between the monitoring software and the device.

[0122] Step 4: Using the set of network communication data packets captured in Step 3, analyze and process them using a protocol analysis framework to obtain the format information of each communication message in the data packets. For each (request, response) pair in the communication packets, construct a communication dictionary where the KEY in the dictionary is the request message and the VALUE is the response message. At the same time, by analyzing and comparing the communication data packets generated by repeated operations, obtain the field information that needs to be dynamically adjusted, focusing on fields such as the Sequence Number field and the Session ID field, thereby constructing a dynamic communication template.

[0123] In Step 4, analyze the captured communication traffic to establish knowledge about the protocol, including obtaining protocol format information and a protocol communication template.

[0124] a) Extract protocol field format information, including: field type and field content. Field types include Number, Binary, String, and the field content corresponds to the divided message content.

[0125] When obtaining protocol field information through segmentation processing based on Netzob, classify specific field types: those with a length less than 4 bytes are regarded as the Number type, those with a length greater than 4 bytes and being consecutive visible strings are classified as the String type, and the remaining fields are classified as the Binary type.

[0126] b) Construct a protocol communication template, including: the correspondence between the request message and the response message during the protocol communication process and the dynamic fields in the response message. The dynamic fields mainly include: the Sequence Number field, the Session ID field, and the Checksum field.

[0127] Obtain the dynamic fields by comparing the different fields of the corresponding messages through repeated operations.

[0128] Step 5: Using the network communication messages in Step 3, evaluate the priority weight of each message as a mutant seed message. The priority weight of the seed message is jointly determined by the length of the message, the interaction depth corresponding to the message, and the coverage information triggered when the message is parsed and processed by the monitoring software.

[0129] In Step 5, evaluate the priority of the seed message based on three characteristics, including: the depth of the message in the entire communication process, which is determined by the order of the interaction process; the number of basic blocks of the monitoring software triggered during parsing, which is determined by the number of program basic blocks executed by the monitoring software when processing the communication message in real time; the complexity of the message itself, which is obtained by the method described in Step 4 to get the number of fields.

[0130] Step 6: Define the probability of each seed message being selected for mutation using the priority weight of the seed messages obtained in Step 5. Provide a probability-based seed message selection algorithm to select seed messages in real time. For the selected seed messages, generate a mutation template based on the format information of the messages in Step 4, and then generate mutated messages in real time.

[0131] Step 7: Automatically input the mutated messages generated in real time into the monitoring software. Construct an agent-based automated communication message input mechanism. Specifically, design GUIProxy to provide automated control of the GUI operations of the monitoring software, and design TrafficProxy to provide automated control of the communication behavior of the monitoring software. Then use the automated communication message input mechanism to input the mutated messages into the monitoring software for processing.

[0132] Step 8: After completing Step 7, send a command to GUIProxy to detect the status of the monitoring software and confirm whether a crash has occurred. If the monitoring software crashes, a POC script can be written based on the malformed data packet to verify the vulnerability, thereby verifying the security vulnerability existing in the target device.

[0133] In Step 8, GUIProxy actively searches for log records related to exceptions in the monitoring software through the Event Log service of the Windows system, including log records such as Application Error and Application hang. If the latest generated exception log record is detected, record the corresponding malformed message as a POC for verifying the vulnerability, which is used to reproduce the vulnerability.

[0134] Step 9: Repeat Step 6, Step 7, and Step 8 to continue the automated fuzz testing of the monitoring software. If the test time limit is reached or new mutated data packets cannot be generated, the test process stops.

[0135] As Figure 3 shown, in Step 7 of this embodiment, two proxy programs can be provided to control the monitoring behavior: including GUI operations and received network communication data. Control the GUI operations of the monitoring software through GUIProxy to trigger its network communication behavior, receive control commands from the Fuzzing main program, and call the automated operation program prepared in Step 2; control the response messages received by the monitoring software through Traffic Proxy to provide mutated malformed messages when receiving specific messages.

[0136] Based on the above technical solutions, the following improvements can also be made in this embodiment.

[0137] Further, in the step 1, the method for finding GUI operations that can trigger network communication behaviors in the GUI interface includes, but is not limited to, finding GUI interface controls, finding product manuals provided by manufacturers, and finding network communication behaviors based on experience. The specific operations for the communication behaviors include, but are not limited to, connecting to the PLC, uploading the PLC program, downloading the PLC program, switching the PLC mode (such as the programming mode), starting and stopping the PLC, etc.

[0138] Further, in the step 4, the format information of the communication message is analyzed using the protocol analysis framework. The communication messages need to be clustered according to their lengths, and then the Netzob protocol analysis framework is used to perform format alignment and segmentation on the clustered messages. For each segmented message field, the defined types include, but are not limited to: the Number type, data less than or equal to 4 bytes; the String type, consecutive visible characters; the Binary type, the remaining message types. For the constructed protocol communication template, there may be cases of duplicate KEYs. In this case, the duplicate KEYs are merged into one, and the corresponding VALUEs are de-duplicated and constructed into a list. For the identified dynamic fields, the messages containing these dynamic fields are replayed to exclude the non-influential fields.

[0139] Further, in the step 7, the commands sent to the GUIProxy include, but are not limited to, Kill, Launch, Detect, Operation:[cmd], where Kill means killing the process of the running monitoring software, Launch means starting the monitoring software program, Detect means checking whether the running state of the monitoring software has crashed, and Operation:[cmd] means a specific operation command, which directly calls and executes a small program for GUI operations written in advance. The commands sent to the TrafficProxy include, but are not limited to, Status, Forward, Modify, Close, where Status means checking the connection status between the monitoring software and the TrafficProxy and the communication messages cached therein, Forward means directly generating feedback messages using the communication template, Modify means inputting the provided mutated messages to the monitoring software, and Close means closing the communication connection between the monitoring software and the TrafficProxy.

[0140] Furthermore, in step 8, the Fuzzing main program discovers whether a vulnerability is triggered by actively requesting the GUIProxy for the status of the monitoring software. Among them, the GUIProxy actively requests the EventLog service of the Windows system to check the status of the Application. If it finds the Application Error log of the target monitoring software in the EventLog record, the GUIProxy will return the information that the vulnerability is discovered to the Fuzzing main program.

[0141] The beneficial effects of this embodiment are as follows:

[0142] This embodiment is used to solve the problems that traditional vulnerability mining tools do not support the automated management of the GUI operation process of passive communication monitoring software during testing, and it is difficult to automatically input malformed data into the monitoring software, as well as the low efficiency of vulnerability mining caused by the unknown private protocol format and interaction process of industrial control systems, achieving the purpose of effectively discovering security defects in the protocol implementation module of industrial control system monitoring software.

[0143] According to the above embodiments, in this embodiment:

[0144] To effectively discover the security vulnerabilities existing in the protocol implementation module of industrial control system monitoring software, solve the problems that traditional vulnerability mining tools do not support the automated management of the GUI operation process of passive communication monitoring software during testing, and it is difficult to automatically input malformed data into the monitoring software, as well as the low efficiency of vulnerability mining caused by the unknown private protocol format and interaction process of industrial control systems, this embodiment proposes a vulnerability mining method of passive fuzz testing. This embodiment solves the above problems and achieves the effect of effectively discovering security defects in the protocol implementation module of industrial control system monitoring software. Multiple 0day vulnerabilities have been discovered in commercial products in the real environment, which has strong practical value.

[0145] In this embodiment, network data packets for the communication between the monitoring software and the PLC device, as well as the GUI operations triggering these communication behaviors, are mainly obtained in the preprocessing stage. Then, based on these captured communication data packets, a communication template is constructed and a small program for automating the execution of GUI operations is prepared, enabling the automated operation of the monitoring software in the Fuzzing stage and correctly distinguishing requests from the monitoring software. At the same time, mutated data packets can be replied according to specific requests, thereby realizing the fuzz testing of the monitoring software. During this process, the Fuzzer main program automatically controls the GUI operations of the monitoring software by sending control commands to the GUIProxy, and automatically controls the communication data packets fed back to the monitoring software by sending control commands to the Traffic Proxy, especially providing mutated communication data packets to achieve the goal of fuzz testing. Further, a coverage-based mechanism is proposed to define the priority weight for each message to mutate as a seed message, and based on this, seed messages are dynamically selected during Fuzzing to generate malformed data. After the malformed data is input, the status of the monitoring is requested from the GUIProxy to determine whether a vulnerability is triggered, so as to accurately and effectively discover security defects existing in the industrial control system monitoring software.

[0146] The following will combine Figure 4 with the timing diagram shown to illustrate the specific steps of this embodiment as follows:

[0147] a) For a given monitoring software, analyze the GUI operations that can generate network communication behaviors and record the operation sequence. The tester manually operates the GUI interface of the monitoring software while using a packet sniffer such as Wireshark to monitor whether relevant network traffic is generated. If so, record the steps of this operation in text.

[0148] b) Using each operation process recorded in step a), write a small program for automatically triggering GUI operations based on the AutoIT framework and compile it into an executable binary program, which can be called by a Python script to trigger the GUI operation process.

[0149] c) Using all the operations in step a), capture and save the network communication data packets triggered by them through a packet sniffer, and limit the range of ip.src and ip.dst by executing a filtering command, where ip.src is the address of the host running the monitoring software and ip.dst is the network address of the PLC device, so as to obtain the set of network data packets for the communication between the monitoring software and the device.

[0150] d) Analyze the private protocol using the set of network communication data packets captured in step c). There are mainly two purposes for analyzing the private protocol: 1) Obtain the format information of the private protocol. First, cluster the communication data packets according to their lengths, and then use the protocol automation analysis framework Netzob to analyze and process them to obtain the field format information of each communication message. Provide type tags for the obtained field formats. Each field must be one of three types: Number, Str, Binary. Finally, obtain the segmented message format information and store this information in the Json file format for use in subsequent steps. 2) Obtain the communication rules of the private protocol. The communication rules are used to simulate communication. When a request initiated by the capture monitoring software is received, using the communication rules, we can provide the correct response or mutate the corresponding response message. Specifically, for each (request, response) pair in the communication packets, we construct a communication dictionary where the KEY is the request message and the VALUE is the response message. At the same time, by analyzing and comparing the communication data packets generated by repeated operations, we obtain the field information that needs to be dynamically adjusted. We focus on fields such as the Sequence Number field and the Session ID field, thus constructing a dynamic communication template. For other fields that need to be dynamically adjusted, we need to perform some replay analysis to determine whether it affects message replay. If it does, then we need to perform reverse analysis on the semantics of this field. Finally, we also store the communication template in the Json file format.

[0151] The following is one of the original message information:

[0152] da0000ff6a020c000100ea0200100202bc5f7d2e04eda099a8571003

[0153] Based on the analysis and processing using the Netzob framework, we obtain the corresponding segmented format information:

[0154]

[0155]

[0156] It can be seen that the message is segmented into three fields, and there are two field types, namely Number and Binary. The following is a fragment of the constructed communication template:

[0157]

[0158] This fragment indicates that when the request from GX Works2 is 0x5a0000ff, we need to respond or mutate with "0xda0000ff6a020c000100ea0200100202d42b7f1f4b2d5323876c1003". This example shows the dynamic fields.

[0159] Step 5: Use the network communication messages in Step 3 to evaluate the priority weights of each message for mutation as a seed message. The priority weight of a seed message is jointly determined by the length of the message, the interaction depth corresponding to the message, and the coverage information triggered when the message is parsed and processed by the monitoring software, and is evaluated using the following formula:

[0160]

[0161] where N represents the number of deduplicated messages generated by a GUI operation, depth i represents the interaction depth of the i-th message, bb_cnt i represents the number of basic block executions triggered when the i-th message is processed in the monitoring software, fld_cnt i represents the number of fields identified for the i-th message, which is generally positively correlated with the message length. 1 / 3 is used for normalizing the weight of each message in the entire communication process so that its weight sum is 1, and is positively correlated with the probability of being selected.

[0162] e) Define the probability of each seed message being selected for mutation using the priority weights of the seed messages obtained in step d). Provide a probability-based seed message selection algorithm to select seed messages in real time. For the selected seed messages, generate a mutation template based on the format information of the messages in step d), and then generate mutated messages in real time. Among them, use the boofuzz fuzz testing framework to read the format information of the messages, automatically generate a mutation template, and call the seed.mutate method and seed.render method during real-time Fuzzing to generate mutated test cases.

[0163] f) Automatically input the mutated messages generated in real time into the monitoring software. Refer to Figure 2 , construct an agent-based automated communication message input mechanism. Specifically, design GUIProxy to provide automated control of the GUI operations of the monitoring software, and design TrafficProxy to provide automated control of the communication behavior of the monitoring software. During the actual Fuzzing process, the sequence of the entire automated input data operation is as Figure 3As shown in the figure, the main Fuzzing program is the Controller. It initializes and sends a command to start the monitoring software to the GUIProxy, and then the GUI Proxy runs the monitoring software. Next, the Controller sends a command to the GUIProxy to control the GUI operation to trigger network communication behavior. At this time, the GUIProxy calls the GUI operation applet prepared in the previous step b), which will trigger the monitoring software to send a request to the Traffic Proxy. At the same time, the Controller periodically requests the Traffic Proxy whether there is a request from the monitoring software. If it is found that there is, it will provide a mutated message according to the specific situation, and the Traffic Proxy will respond this message to the monitoring software to complete the input of malformed data. This process is completely automated and can input the mutated message to the monitoring software for processing.

[0164] g) After completing step f), the Controller sends a command to the GUIProxy to detect the status of the monitoring software and confirm whether a crash has occurred. If the monitoring software crashes, the GUIProxy will look for the exception log in the Event Log service of the Windows system. If a crash is found, it will return the exception information to the Controller, and then a POC script can be written based on the malformed data packet to verify the vulnerability, so as to verify the security vulnerability existing in the target device.

[0165] h) Repeat step e), step f), and step g) to continue the automated fuzz testing of the monitoring software. If the test time limit is reached or no new mutated data packets can be generated, the test process stops.

[0166] The beneficial effects of this embodiment are as follows:

[0167] Effectively discover the security vulnerabilities existing in the protocol implementation module of the industrial control system monitoring software, solve the problems that traditional vulnerability mining tools do not support the automated management of the GUI operation process during the testing of passive communication monitoring software, and it is difficult to automatically input malformed data to the monitoring software, as well as the problem of low vulnerability mining efficiency caused by the unknown private protocol format and interaction process of the industrial control system.

[0168] This embodiment can effectively discover the security defects in the protocol implementation module of the industrial control system monitoring software. Multiple 0day vulnerabilities have been discovered in commercial products in the real environment, which has strong practical value.

[0169] Next, the passive fuzz testing system provided by the present invention will be described. The passive fuzz testing system described below can be correspondingly referred to the fuzz testing method described above.

[0170] An embodiment of the present invention provides a passive fuzz testing system, including:

[0171] A mutation module that instantiates dynamic fields in a seed message according to a test protocol and retains fixed fields to form at least one mutated message, where the seed message is generated according to a communication protocol between a device and a program under test, and the field values corresponding to the dynamic fields are configurable device operating parameters or user parameters;

[0172] A test module that runs the program under test according to the mutated message, monitors the state of the program under test, and obtains a test result, where the test result includes the correspondence between the mutated message and the state of the program under test.

[0173] The beneficial effects of this embodiment are as follows:

[0174] By determining the dynamic fields of the seed message and adjusting the dynamic fields to form mutated messages, the step of adjusting the fixed fields is omitted, effectively improving the formation efficiency of the mutated messages, providing a basis for the testing and vulnerability mining processes, and thus achieving the beneficial effects of simple testing and improved vulnerability mining efficiency.

[0175] Figure 5 An example of the physical structure diagram of an electronic device is shown as Figure 5 shown. The electronic device may include: a processor 510, a communication interface 520, a memory 530, and a communication bus 540. Among them, the processor 510, the communication interface 520, and the memory 530 complete mutual communication through the communication bus 540. The processor 510 can call the logical instructions in the memory 530 to execute a fuzz testing method, which includes: determining a seed message and the dynamic fields in the seed message; adjusting the dynamic fields in the seed message to form a mutated message; inputting the mutated message into the program under test, monitoring the state of the program under test, and obtaining a test result.

[0176] In addition, when the logical instructions in the above-mentioned memory 530 are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0177] On the other hand, the present invention also provides a computer program product. The computer program product includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the fuzz testing method provided by the above-mentioned various methods. The method includes: determining a seed message and dynamic fields in the seed message; adjusting the dynamic fields in the seed message to form a mutated message; inputting the mutated message into the program under test, monitoring the state of the program under test, and obtaining a test result.

[0178] In yet another aspect, the present invention also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it is configured to execute the fuzz testing method provided by the above-mentioned various methods. The method includes: determining a seed message and dynamic fields in the seed message; adjusting the dynamic fields in the seed message to form a mutated message; inputting the mutated message into the program under test, monitoring the state of the program under test, and obtaining a test result.

[0179] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without creative efforts.

[0180] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the essence of the above technical solution, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0181] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fuzz testing method for a protocol implementation module of an industrial control system monitoring software, characterized in that, it includes: Set logic or code according to the GUI interface of the monitoring software to obtain the operation process that can generate network communication behavior; Use each obtained operation process to generate a small program for automatically triggering GUI operations based on the AutoIT framework. The functions implemented by the GUI operation small program include: monitoring software startup command, button click, mouse coordinate click, selection box selection, Menu selection, shortcut key input, text box filling, and killing the monitoring software process; Obtain the network data packet set of the communication between the monitoring software and the device, analyze the private protocol, and obtain the format information of the private protocol and the protocol communication template; among them, the format information of the protocol includes: field type and field content; the protocol communication template includes: the correspondence between the request message and the response message in the protocol communication process, and the dynamic fields in the response message; the dynamic fields are determined by comparing the different fields of the messages generated by repeated operations, and are a set of fields with different field values in multiple seed messages, including: Sequence Number field, SessionID field, and Checksum field. The field values corresponding to the dynamic fields are configurable device operating parameters or user parameters; the protocol is a private protocol with unknown format and unknown communication process; Use the obtained network communication messages to evaluate the priority weights of each message as a seed message, and select the seed message; the seed message is selected from multiple communication messages according to the priority weight. The multiple communication messages are response messages obtained from the device, and the response message is generated by the device under the trigger of the program under test; the priority weight is determined by the combination of the communication message length, the communication message interaction depth, and the number of program basic blocks executed by the program under test for processing the communication message; Instantiate the dynamic fields in the seed message according to the test protocol and retain the fixed fields to form at least one mutant message; the instantiation of the dynamic fields in the seed message according to the test protocol includes: extracting the format information of the dynamic fields in the seed message; the format information includes the communication protocol corresponding to the seed message; instantiate the dynamic fields in the seed message according to the format information of the dynamic fields in the seed message; Build an automated communication message input mechanism based on a proxy to automatically input the real-time generated mutant message into the monitoring software, including: building a GUIProxy for providing automated control of the GUI operations of the monitoring software; building a TrafficProxy for automated control of the communication behavior of the monitoring software; When the fuzz testing controller is initialized, it sends a command to start the monitoring software to GUIProxy, and GUIProxy runs the monitoring software; the controller sends a command to control GUI operations to trigger network communication behaviors to GUIProxy, and GUIProxy calls the GUI operation applet to trigger the monitoring software to initiate a request to TrafficProxy; the controller periodically requests TrafficProxy whether there is a request from the monitoring software currently. If so, it provides a mutated packet, and TrafficProxy responds the mutated packet to the monitoring software to complete the input of the mutated packet. Run the program under test according to the mutated packet, monitor the status of the program under test based on the EventLog service of the Windows system, and obtain the test result, where the test result includes the correspondence between the mutated packet and the status of the program under test. The step of obtaining the test result includes: determining that the program under test runs abnormally, then taking the abnormal result of the program under test and the corresponding mutated packet as the test result, and restarting the program under test; determining that the program under test runs normally, then updating the mutated packet, and returning to input the mutated packet into the program under test and monitoring the status of the program under test.

2. A passive fuzz testing system for a protocol implementation module of an industrial control system monitoring software Characterized in that It includes: The passive fuzz testing system is used to: set logic or code according to the GUI interface of the monitoring software, and obtain the operation process capable of generating network communication behaviors; Using each obtained operation process, generate an applet for automatically triggering GUI operations based on the AutoIT framework. The functions implemented by the GUI operation applet include: monitoring software start command, button click, mouse coordinate click, checkbox selection, Menu selection, shortcut key input, text box filling, and killing the monitoring software process; The passive fuzz testing system is used to: obtain the network data packet set for the communication between the monitoring software and the device, analyze the private protocol, and obtain the format information of the private protocol and the protocol communication template; wherein, the format information of the protocol includes: field type and field content; the protocol communication template includes: the correspondence between the request packet and the response packet in the protocol communication process, and the dynamic fields in the response packet; the dynamic fields are determined by comparing the different fields of the packets generated by repeated operations, and are a set of fields with different field values in multiple seed packets, including: SequenceNumber field, Session ID field, and Checksum field. The field values corresponding to the dynamic fields are configurable device operation parameters or user parameters; the protocol is a private protocol with unknown format and unknown communication process. The passive fuzz testing system is used for: evaluating the priority weight of each network communication message as a seed message by using the obtained network communication messages, and selecting the seed message; the seed message is selected from multiple communication messages according to the priority weight, the multiple communication messages are response messages obtained from the device, and the response messages are generated by the device under the trigger of the program under test; the priority weight is determined by a combination of the communication message length, the communication depth of the communication message, and the number of program basic blocks executed by the program under test for processing the communication message. It includes a mutation module for instantiating the dynamic fields in the seed message according to the test protocol and retaining the fixed fields to form at least one mutated message; the instantiating of the dynamic fields in the seed message according to the test protocol includes: extracting the format information of the dynamic fields in the seed message; the format information includes the communication protocol corresponding to the seed message; instantiating the dynamic fields in the seed message according to the format information of the dynamic fields in the seed message. It includes a testing module for constructing an automated communication message input mechanism based on an agent to automatically input the real-time generated mutated message into the monitoring software, including: constructing a GUIProxy for providing automated control of the GUI operations of the monitoring software; constructing a TrafficProxy for automated control of the communication behavior of the monitoring software; when the fuzz testing controller is initialized, sending a command to start the monitoring software to the GUIProxy, and the GUIProxy runs the monitoring software; the controller sends a command to control the GUI operation to trigger the network communication behavior to the GUIProxy, and the GUIProxy calls the GUI operation applet to trigger the monitoring software to send a request to the TrafficProxy; the controller periodically requests whether there is a request from the monitoring software at the TrafficProxy, if so, provides the mutated message, and the TrafficProxy responds the mutated message to the monitoring software to complete the input of the mutated message; running the program under test according to the mutated message, monitoring the state of the program under test, and obtaining a test result, where the test result includes the corresponding relationship between the mutated message and the state of the program under test; the step of obtaining the test result includes: determining that the program under test runs abnormally, then taking the abnormal result of the program under test and the corresponding mutated message as the test result, and restarting the program under test; determining that the program under test runs normally, then updating the mutated message, and returning to input the mutated message into the program under test and monitoring the state of the program under test.

3. An electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein, when the processor executes the program, it implements the steps of the fuzz testing method of the protocol implementation module for the industrial control system monitoring software as described in claim 1.

4. A non-transitory computer-readable storage medium, on which a computer program is stored, wherein, When the computer program is executed by a processor, it implements the steps of the fuzz testing method for the protocol implementation module of the industrial control system monitoring software as described in claim 1.

Images