A method and device for vulnerability mining

Abstract

The present application discloses a vulnerability mining method and device, wherein the vulnerability mining device first obtains the traffic information sent by the application on the terminal device to the IoT device through the cloud server; then, based on the traffic information, performs fuzz testing on the client program on the IoT device; finally, monitors the anomalies in the fuzz testing to determine the vulnerabilities of the IoT device. It can be seen that the method provided by the embodiment of the present application provides a reverse (i.e., server-to-client) fuzz test, adopts a black box approach to make the applicability of the test target more extensive, and uses transparent proxy technology to perform traffic middleman hijacking. By hijacking the communication link between the cloud server and the IoT device, it is possible to mine the vulnerabilities in the messages received by the client program on the IoT device side in modes such as message queue communication, thereby improving the security of the communication scenario between the IoT device and the cloud server.

Description

Technical Field

[0001] The present application relates to the field of security technology, and in particular to a method and device for vulnerability mining. Background Art

[0002] The Internet of Things (IoT) has become one of the most popular and practical network platforms. Various sensors and controllers are connected to the Internet to achieve seamless communication between people and things, becoming an important direction for the future development of the global network.

[0003] Currently, users can use applications (APPs) installed on terminal devices (such as mobile phones) to control IoT devices through cloud servers. Cloud servers and IoT devices typically interact using long-terminal connection protocols (such as Message Queuing Telemetry Transport (MQTT)). In this way, the cloud server proactively pushes messages from the APP to the IoT device, and the IoT device directly parses the messages sent by the cloud server. This allows attackers to use the cloud server as a springboard to send malicious messages to IoT devices, thereby triggering vulnerabilities in the IoT device's parsing of malicious messages. This can cause remote denial of service attacks or remote command execution against multiple online IoT devices, overcoming the limitations of existing near-field attacks such as wireless network communication technologies (Wi-Fi) and Bluetooth. This eliminates the need for close-range attacks, resulting in lower attack costs, greater harm, and a wider impact.

[0004] Based on this, there is an urgent need to provide a technical solution for vulnerability mining on the IoT device side that can solve the security issues in the communication scenarios between the above-mentioned IoT devices and cloud servers. Summary of the Invention

[0005] The embodiments of the present application provide a vulnerability mining method and apparatus, which hijacks the communication link between the cloud server and the IoT device, mines the vulnerability of the IoT device based on fuzzing, and improves the security of the communication scenario between the IoT device and the cloud server.

[0006] In a first aspect, an embodiment of the present application provides a vulnerability mining method, comprising:

[0007] Obtain traffic information sent by applications on terminal devices to IoT devices through cloud servers;

[0008] Performing fuzz testing on the client program on the IoT device based on the traffic information;

[0009] Monitor anomalies in the fuzz test to determine vulnerabilities of the IoT device.

[0010] Optionally, the cloud server sends the traffic information to the IoT device through a gateway, and obtaining the traffic information sent by the application on the terminal device to the IoT device through the cloud server includes:

[0011] The traffic information is obtained through the gateway.

[0012] Optionally, the gateway modifies, through a kernel interface, a destination address and a port for sending traffic information from the terminal device to the IoT device, and obtaining the traffic information through the gateway includes:

[0013] receiving, from the gateway, the traffic information sent by the terminal device based on the modified destination address and port;

[0014] After obtaining the traffic information through the gateway, the method further includes:

[0015] Based on the repaired destination address and port, the traffic information is sent to the IoT device through the gateway, wherein the repaired destination address and port are the results after the gateway repairs the destination address and port of the traffic information sent by the terminal device to the IoT device through the kernel interface.

[0016] Optionally, the performing fuzz testing on the client program on the IoT device based on the traffic information includes:

[0017] Using the traffic information as a test set seed, mutating the test set seed to generate test data;

[0018] According to a preset strategy, a fuzz test is performed on the client program on the IoT device based on the test data.

[0019] Optionally, monitoring anomalies in the fuzz test to determine the vulnerability of the IoT device includes:

[0020] Monitoring the connection status between the cloud server and the IoT device;

[0021] Determine whether the IoT device has a memory corruption vulnerability based on the connection status.

[0022] Optionally, the method further includes:

[0023] Send a Ping command to the client program of the IoT device;

[0024] The monitoring of anomalies in the fuzz test and determining the vulnerability of the IoT device includes:

[0025] Monitor whether the IoT device responds to the Ping command;

[0026] According to the response, it is determined that the IoT device has a command injection vulnerability.

[0027] In a second aspect, an embodiment of the present application further provides a vulnerability mining device, comprising:

[0028] An acquisition unit, configured to acquire traffic information sent by an application on a terminal device to an IoT device via a cloud server;

[0029] A testing unit, configured to perform a fuzz test on a client program on the IoT device based on the traffic information;

[0030] The monitoring unit is used to monitor anomalies in the fuzzy test and determine the vulnerabilities of the IoT device.

[0031] Optionally, the cloud server sends the traffic information to the IoT device through a gateway, and the acquiring unit is specifically configured to:

[0032] The traffic information is obtained through the gateway.

[0033] Optionally, the gateway modifies the destination address and port for sending traffic information from the terminal device to the IoT device through a kernel interface, and the acquiring unit is specifically configured to:

[0034] the traffic information sent by the terminal device and received from the gateway based on the modified destination address and port;

[0035] The device further comprises:

[0036] A first sending unit is configured to send the traffic information to the IoT device through the gateway based on the repaired destination address and port after obtaining the traffic information through the gateway, wherein the repaired destination address and port are respectively the results of the gateway repairing the destination address and port of the traffic information sent by the terminal device to the IoT device through the kernel interface.

[0037] Optionally, the testing unit includes:

[0038] a mutation subunit, configured to use the traffic information as a test set seed, mutate the test set seed, and generate test data;

[0039] The testing subunit is used to perform fuzz testing on the client program on the IoT device based on the test data in accordance with a preset strategy.

[0040] Optionally, the monitoring unit includes:

[0041] a first monitoring subunit, configured to monitor the connection status between the cloud server and the IoT device;

[0042] The first determining subunit is configured to determine whether the IoT device has a memory corruption vulnerability according to the connection status.

[0043] Optionally, the device further comprises:

[0044] A second sending unit, configured to send a Ping command to a client program of the IoT device;

[0045] The monitoring unit includes:

[0046] A second monitoring subunit is configured to monitor whether the IoT device responds to the Ping command;

[0047] The second determining subunit is used to determine whether the IoT device has a command injection vulnerability based on the response.

[0048] In a third aspect, an embodiment of the present application further provides a vulnerability mining system, comprising: a middleman traffic proxy module, a fuzz testing engine, and an abnormal information capturer, wherein:

[0049] The middleman traffic proxy module is used to obtain traffic information sent by the application on the terminal device to the IoT device through the cloud server;

[0050] The fuzz testing engine is used to perform fuzz testing on the client program on the IoT device based on the traffic information;

[0051] The abnormal information capturer is used to monitor abnormalities in the fuzzy test and determine the vulnerabilities of the IoT device.

[0052] The cloud server sends the traffic information to the IoT device through a gateway, and the vulnerability mining system is integrated into the gateway.

[0053] Alternatively, the cloud server sends the traffic information to the IoT device via a gateway, and the vulnerability mining system communicates with the gateway. The middleman traffic proxy module, fuzz testing engine, and anomaly information capturer in the vulnerability mining system can be implemented by a single server or multiple servers.

[0054] In a fourth aspect, an embodiment of the present application further provides an electronic device, comprising a processor and a memory:

[0055] The memory is used to store computer programs;

[0056] The processor is configured to execute the method provided in the first aspect according to the computer program.

[0057] In a fifth aspect, an embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store a computer program, and the computer program is used to execute the method provided in the first aspect above.

[0058] It can be seen that the embodiments of the present application have the following beneficial effects:

[0059] The embodiment of the present application provides a method for vulnerability mining, in which the vulnerability mining device first obtains the traffic information sent by the application on the terminal device to the IoT device through the cloud server; then, based on the traffic information, the client program on the IoT device is fuzz tested; finally, the anomalies in the fuzz test are monitored to determine the vulnerabilities of the IoT device. It can be seen that the method provided by the embodiment of the present application provides a reverse (i.e., server-to-client) fuzz test, adopts a black box approach to make the applicability of the test target more extensive, and uses transparent proxy technology to perform traffic middleman hijacking. By hijacking the communication link between the cloud server and the IoT device, it is possible to mine the vulnerabilities in the messages received by the client program on the IoT device side in modes such as message queue communication, thereby improving the security of the communication scenario between the IoT device and the cloud server. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments described in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0061] Figure 1 A schematic diagram of a communication architecture of an IoT device provided in an embodiment of the present application;

[0062] Figure 2 A schematic diagram of the structure of a vulnerability mining system in a scenario applicable to an embodiment of the present application;

[0063] Figure 3 A flowchart of a vulnerability discovery method provided in an embodiment of the present application;

[0064] Figure 4A schematic diagram of the structure of a vulnerability mining device provided in an embodiment of the present application;

[0065] Figure 5 A schematic diagram of the structure of a vulnerability mining system provided in an embodiment of the present application;

[0066] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0067] To make the above-mentioned objects, features, and advantages of the present application more clearly understood, the following further describes the embodiments of the present application in detail with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the present application and are not intended to limit the present application. In addition, it should be noted that, for ease of description, the drawings only show portions relevant to the present application, not all structures.

[0068] For smart home scenarios, the communication architecture of IoT devices is usually as follows Figure 1 shown.

[0069] As an example, a user uses an app 110 installed on a terminal device 100 (such as a mobile phone) to control an IoT device 300 through a cloud server 200. Cloud server 200 and IoT device 300 communicate via a gateway 400. For example, in the case of a speaker 300, the user can send a control message through the app 110 installed on the mobile phone 100 for controlling the speaker 300. The control message is then sent to the speaker 300 via the cloud server 200. The speaker 300 then executes the control message to control the speaker 300.

[0070] As another example, a user can directly control an IoT device 300 using an app 110 installed on a terminal device 100 (e.g., a mobile phone). The terminal device 100 and the IoT device 300 communicate via a gateway 400. For example, if the IoT device 300 is a speaker 300, the user can send a control message using the app 110 installed on the mobile phone 100 for controlling the speaker 300. The control message is directly sent to the speaker 300, which then executes the control message to control the speaker 300.

[0071] It should be noted that, in order to more clearly illustrate the vulnerability mining method provided by the present application, the embodiments of the present application take the vulnerability mining in the process of the cloud server 200 sending a control message to the IoT device 300 through the gateway 400 as an example for illustration. As for the vulnerability mining in the process of the terminal device 100 sending a control message to the IoT device 300 through the gateway 400, since the principle is the same, it will not be repeated.

[0072] based on Figure 1 In the IoT architecture shown, cloud servers and IoT devices typically interact using a persistent connection protocol (such as MQTT). Therefore, the cloud server proactively pushes messages from the app to the IoT device, which then directly parses the messages from the cloud server. This creates a new attack model: using the cloud server as a springboard to send malicious messages to the IoT device, thereby triggering vulnerabilities in the IoT device's parsing of the malicious messages. This allows remote denial of service attacks or remote command execution against multiple online IoT devices, overcoming the limitations of existing near-field attacks such as Wi-Fi or Bluetooth. This eliminates the need for close-range attacks, resulting in lower attack costs, greater harm, and a wider impact.

[0073] However, current vulnerability mining methods cannot directly access the reverse communication tunnel formed by the cloud server actively communicating with the IoT device, and thus cannot achieve effective IoT device-side vulnerability mining in this scenario.

[0074] Based on this, in order to improve the security of the cloud and device combination scenario in the Internet of Things, an embodiment of the present application provides a method for vulnerability mining on the IoT device side, which hijacks the communication link between the cloud server and the IoT device to automatically perform fuzz testing on the device program and mine zero-day (0day) vulnerabilities.

[0075] The vulnerability mining method provided in the embodiment of the present application may, for example, include: the vulnerability mining device first obtains the traffic information sent by the application on the terminal device to the IoT device through the cloud server; then, based on the traffic information, a fuzz test is performed on the client program on the IoT device; finally, anomalies in the fuzz test are monitored to determine the vulnerability of the IoT device.

[0076] It can be seen that the method provided in the embodiment of the present application provides a reverse (i.e., server to client) fuzz test, adopts a black box approach to make the applicability of the test target more extensive, and uses transparent proxy technology to perform traffic middleman hijacking. By hijacking the communication link between the cloud server and the IoT device, it is possible to exploit vulnerabilities in the messages received by the client program on the IoT device side in modes such as message queue communication, thereby improving the security of the communication scenarios between the IoT device and the cloud server.

[0077] In order to make the solutions provided by the embodiments of the present application clearer, some of the terms mentioned in the embodiments of the present application are explained below.

[0078] Message queue communication: This allows apps to communicate through services. Message queues temporarily store messages when the app is offline and send them back when the app is online. This ensures that message data is not lost when IoT devices are offline. This provides an asynchronous communication method, placing data in a message queue without requiring an immediate response.

[0079] Fuzz testing is a method for discovering software vulnerabilities by providing unexpected inputs to a target system and monitoring for abnormal results. It is widely used by major software vendors to identify vulnerabilities in their products, thereby reducing their vulnerability burden. The core concept is to input automatically or semi-automatically generated random data into a program and monitor for program anomalies, such as crashes and assertion failures, to identify possible program errors, such as memory leaks. Fuzz testing is often used to detect security vulnerabilities in software or computer systems.

[0080] MQTT: A lightweight, open-source protocol for transmitting data between users or IoT devices. Unlike other protocols based on a request / response model, MQTT adopts a Pub / Sub communication model. In the IoT communication architecture, IoT devices generally act as subscribers to receive instructions, and users act as publishers to publish instructions, with the transmission being relayed through the MQTT protocol service.

[0081] Seed: Test case. Since the test case is used as the starting point for mutation during the fuzzing process, it is also called a seed.

[0082] Mutation: In the seed mutation phase, the input is changed by mutating the seed, so that the test data enters different program paths, increasing the chance of vulnerability discovery.

[0083] To facilitate understanding of the specific implementation of the vulnerability mining method provided in the embodiment of the present application, the following will be described with reference to the accompanying drawings.

[0084] It should be noted that the subject of the vulnerability mining method can be the vulnerability mining device provided in the embodiment of the present application, and the device can be carried in an electronic device or a functional module of an electronic device. The electronic device in the embodiment of the present application can be any device that can implement the vulnerability mining method in the embodiment of the present application. Alternatively, the subject of the vulnerability mining method can be the vulnerability mining system provided in the embodiment of the present application, and the various modules of the system can be carried in one or more physical devices, for example, it can be carried on a gateway between a cloud server and an IoT device.

[0085] Before introducing the embodiments of the present application, we first take the vulnerability mining device carried by a vulnerability mining system composed of multiple servers connected to a gateway as an example to introduce the applicable scenario. Figure 2 shown.

[0086] See also Figure 2 In this scenario, the vulnerability mining system 1 may include: a middleman traffic proxy module 10, a fuzz testing engine 20, and an exception information capturer 30. The middleman traffic proxy module 10 is used to obtain traffic information sent by an application on a terminal device to an IoT device via a cloud server; the fuzz testing engine 20 is used to perform fuzz testing on the client program on the IoT device based on the traffic information; and the exception information capturer 30 is used to monitor anomalies in the fuzz testing and identify vulnerabilities in the IoT device.

[0087] Regarding the middleman traffic proxy module 10, considering the difficulty of fuzzing reverse communication, how to actively send test data to the client program of the IoT device in black box mode. Through research, it was found that in IoT device communication, IoT devices need to use gateway devices such as Wi-Fi routers to access the Internet, which provides the possibility of traffic middleman hijacking. In the embodiment of the present application, the communication session is hijacked by the middleman proxy method. During the test data generation stage, the traffic information can be recorded and stored as a mutation seed. And in the fuzzing stage, the communication session is intervened to send test data to the client program.

[0088] As an example, the middleman traffic proxy module 10 may include a middleman hijacking submodule 11 and a traffic recorder 12 .

[0089] Considering the communication architecture of common IoT devices such as Figure 1 As shown. The user communicates with the IoT device through the cloud side or the local area network through a peripheral system, such as an application of a terminal device. Then, the uplink communication path between the IoT device and the cloud server is ⑥-③, the downlink communication path between the IoT device and the cloud server is ④-⑤, and the communication path between the terminal device and the IoT device is ①-⑤ and ⑥-②. These communication paths all need to pass through the gateway. Therefore, the middleman hijacking submodule 11 in the embodiment of the present application can modify the destination address and port of the device communication through the kernel interface at the gateway, forward the traffic message to the agent, and then call the kernel interface to repair the destination address and port, thereby hijacking the communication session. The middleman hijacking submodule 11 can maintain the uplink and downlink communication sessions of the IoT device, and also provides an interface for sending test data for Fuzzing.

[0090] Considering the aforementioned intermediary approach, the proxy can hijack the communication session. In this way, the traffic recorder 12 can passively record the communication data between the IoT device and the cloud server, or between the IoT device and the app on the terminal device, and use this as a mutation seed for fuzzing. To improve the efficiency of seed data collection, a manual method can be used to traverse the controls of the peripheral system (such as the app or web on the terminal device) to trigger interactive communication with the IoT device and obtain more comprehensive mutation seed data.

[0091] The fuzzy test engine 20 also needs mutation data and formulates a strategy for testing based on the feedback information. To this end, the fuzzy test engine 20 of the present application embodiment has two main functions: test data generation and task scheduling.

[0092] As an example, the fuzz testing engine 20 may include a test data generator 21 and a task scheduler 22 .

[0093] Among them, the test data generator 21 is used to perform mutation processing on the data of the traffic record. The specific process may include: first, reading the traffic information as a mutation seed, and performing traffic protocol identification, that is, pre-processing and parsing the values ​​of the corresponding fields of the protocol, especially pre-processing and parsing the message payload (for example: code 1). A blacklist mechanism can be established to filter some fields. For example, for fields such as the Topic field in the MQTT protocol, the Topic field is used to identify the target of the message queue forwarding and is generally not processed. Identify field value types such as JSON objects, binary and key-value pairs, and perform targeted mutations according to the identified field value types according to the preset strategy. For example, in the JSON object of code 1, the test data generator 21 traverses the value identification type in the JSON object. The preset strategy can mutate according to strings, integers, floating-point numbers, etc. to generate test data to be sent.

[0094] The task scheduler 22 can use the session management interface provided by the middleman traffic proxy module 10 to send the data required for fuzzing to the client program of the IoT device. The task scheduler 22 can formulate a strategy to initiate the test data sending task and monitor the received exception information feedback to determine whether an exception has been triggered. As an example, for command injection vulnerability types, the fuzzing method is used to inject the ping command (for example: ping -c 1 192.168.1.1). The advantage of this method is that it monitors through the Internet Control Message Protocol (ICMP) server and does not block the fuzzing process. As another example, for memory corruption vulnerability types, these may include buffer overflow and null pointer reference vulnerabilities. When triggered, these vulnerabilities usually cause the application to crash, so they are also called crash vulnerability types. If a crash vulnerability message notification is received, the exception information will be recorded and the fuzzing execution will be suspended because the subscriber is temporarily offline. In this case, it is necessary to wait for the daemon process to restart before restarting the test task.

[0095] For example, the test data for parm value mutation command injection vulnerability detection can be as follows:

[0096]

[0097] The exception information capturer 30 is responsible for collecting feedback information about exceptions during fuzzing. Traditional fuzz testing systems often use restarting or shutting down the system to test command execution vulnerabilities. This paper proposes an optimization solution that injects a PING command to prevent the device from stopping, allowing the test task to execute continuously and improving the efficiency of fuzz testing. Therefore, according to the vulnerability type, the exception information is mainly divided into crash-type exception information and command injection-type exception information, and different detection methods are used.

[0098] As an example, the abnormal information collector 30 may include a session status monitor 31 and an ICMP server 32 .

[0099] Among them, the session status monitor 31 can be used to obtain abnormal information of crash-type vulnerabilities. Through the protocol mechanism unique to IoT devices, it is possible to determine whether the client program has crashed based on the state of the heartbeat packet or the communication session. It should be noted that the embodiment of the present application proposes a method for monitoring the session status to determine vulnerabilities, that is, when the communication program crashes, the client program will send a Transmission Control Protocol (TCP) message of RST or FIN to terminate the current session, thereby determining whether it is an abnormal mechanism. Among them, in the embodiment of the present application, the uplink and downlink sessions are hijacked by a middleman agent, which provides the possibility of monitoring the session status.

[0100] Among them, the ICMP server 32 can be used to obtain command injection exception information. Traditional fuzzing monitors the status of services by injecting system shutdown or restart commands, but this method has the following shortcomings: First, because it cannot detect the status of the client program, it is not suitable for reverse fuzzing methods; second, it will hinder the progress of fuzzing. Based on this, the embodiment of the present application adopts the method of sending Ping packets, such as the test data in the above example, to monitor whether there are messages sent by IoT devices through the ICMP server 32 to determine whether there is a command injection vulnerability.

[0101] It should be noted that Figure 2 The functions of each module and the steps performed in the embodiments of the present application can be found in the following Figure 3 Introduction in the illustrated embodiment.

[0102] Figure 3 A flowchart of a vulnerability mining method provided in an embodiment of the present application is provided. This method can be applied to Figure 2 In the vulnerability mining system 1 shown, the vulnerability mining system 1 can be hosted on at least one server. If the vulnerability mining system 1 is hosted on a server, then the server can be Figure 1 The gateway 400 in the Figure 1 Other servers having the functions of the vulnerability mining system 1 connected to the network 400 in the network; if the vulnerability mining system 1 is hosted on multiple servers, then at least one module in the multiple servers can be integrated into Figure 1 On the gateway 400 in the Figure 1 A physical module connected to the network 400 in and independent of the gateway 400.

[0103] like Figure 3 As shown, the method may include the following S301 to S303:

[0104] S301, obtaining traffic information sent by an application on a terminal device to an IoT device via a cloud server.

[0105] In an embodiment of the present application, a method is designed to hijack the communication session between an IoT device and a cloud server, or between an IoT device and a terminal device where an app for controlling the IoT device is installed, through a middleman traffic proxy. As an example, the middleman traffic proxy hijacking can be implemented through a gateway between the IoT device and the cloud server, or between the IoT device and the terminal device where an app for controlling the IoT device is installed. For example, the gateway can modify the destination address and port of device communication through a kernel interface and forward the traffic to the proxy. Then, in order to avoid affecting the terminal device's app's control over the IoT device, the kernel interface can be called again to repair the destination address and port, so that the traffic is forwarded from the gateway to the IoT device.

[0106] As an example, the cloud server sends the traffic information to the IoT device through the gateway. Then, obtaining the traffic information sent by the application on the terminal device to the IoT device through the cloud server in S301 may include: obtaining the traffic information through the gateway.

[0107] S302: Perform a fuzzy test on the client program on the IoT device based on the traffic information.

[0108] In specific implementation, the fuzzy test of the client program on the IoT device based on the traffic information in S302 may include: S3021, using the traffic information as a test set seed, mutating the test set seed, and generating test data; S3022, performing fuzzy testing on the client program on the IoT device based on the test data according to a preset strategy.

[0109] S303: Monitor anomalies in the fuzzy test to determine vulnerabilities of the IoT device.

[0110] As an example, monitoring anomalies in the fuzzy test and determining the vulnerability of the IoT device in S303 may include: monitoring the connection status between the cloud server and the IoT device; and determining whether the IoT device has a memory corruption vulnerability based on the connection status.

[0111] As another example, the method may further include sending a Ping command to the client program of the IoT device. Then, monitoring anomalies in the fuzz test and determining a vulnerability in the IoT device in S303 may include monitoring whether the IoT device responds to the Ping command; and determining, based on the response, that the IoT device has a command injection vulnerability.

[0112] It is understandable that by hijacking the communication session between the IoT device and the cloud server or the terminal device where the APP is located through the middleman traffic proxy, the vulnerability mining device or vulnerability mining system provided in the embodiment of the present application can provide three capabilities: 1. The ability to send traffic to the client program; 2. The ability to record the data exchanged between the IoT device and the cloud server, and between the IoT device and the terminal device where the APP that controls the IoT device is located; 3. The ability to monitor the status of the communication session initiated by the client program. Using these capabilities, first, the traffic information of the communication between the IoT device and the cloud server can be collected as the test set seed, and test data can be generated by mutating these seeds; second, the middleman proxy can be used to formulate a strategy to send test data; finally, the client communication session status and other information can be monitored to capture abnormal information and discover vulnerabilities.

[0113] The above detection method can detect two types of vulnerabilities: memory corruption and command injection. Memory corruption vulnerabilities can include buffer overflows and null pointer dereference vulnerabilities, which typically cause the application to crash when triggered. Therefore, when exception information is captured, the TCP connection status between the IoT device and the cloud server is monitored to infer whether the process is still running. If the TCP connection is interrupted, a memory corruption vulnerability is confirmed. For command injection vulnerabilities, the Ping command can be inserted into the fuzzing data payload to monitor whether an ICMP Echo message is triggered to determine whether this type of vulnerability exists. If an ICMP Echo message is detected, a command injection vulnerability is considered to exist.

[0114] It can be seen that the method provided in the embodiment of the present application provides a reverse (i.e., server to client) fuzz test, adopts a black box approach to make the applicability of the test target more extensive, and uses transparent proxy technology to perform traffic middleman hijacking. By hijacking the communication link between the cloud server and the IoT device, it is possible to exploit vulnerabilities in the messages received by the client program on the IoT device side in modes such as message queue communication, thereby improving the security of the communication scenarios between the IoT device and the cloud server.

[0115] Accordingly, the embodiment of the present application also provides a vulnerability mining device 400, see Figure 4 The device 400 includes:

[0116] An acquiring unit 401 is configured to acquire traffic information sent by an application on a terminal device to an IoT device via a cloud server;

[0117] A testing unit 402 is configured to perform a fuzz test on a client program on the IoT device based on the traffic information;

[0118] The monitoring unit 403 is configured to monitor anomalies in the fuzzy test and determine vulnerabilities of the IoT device.

[0119] As an example, the cloud server sends the traffic information to the IoT device through a gateway, and the acquiring unit 401 is specifically configured to:

[0120] The traffic information is obtained through the gateway.

[0121] For example, the gateway modifies the destination address and port of the traffic information sent by the terminal device to the IoT device through the kernel interface. The acquiring unit 401 is specifically configured to:

[0122] receiving, from the gateway, the traffic information sent by the terminal device based on the modified destination address and port;

[0123] The apparatus 400 further includes:

[0124] A first sending unit is configured to send the traffic information to the IoT device through the gateway based on the repaired destination address and port after obtaining the traffic information through the gateway, wherein the repaired destination address and port are respectively the results of the gateway repairing the destination address and port of the traffic information sent by the terminal device to the IoT device through the kernel interface.

[0125] As an example, the testing unit 402 includes:

[0126] a mutation subunit, configured to use the traffic information as a test set seed, mutate the test set seed, and generate test data;

[0127] The testing subunit is used to perform fuzz testing on the client program on the IoT device based on the test data in accordance with a preset strategy.

[0128] As an example, the monitoring unit 403 includes:

[0129] a first monitoring subunit, configured to monitor the connection status between the cloud server and the IoT device;

[0130] The first determining subunit is configured to determine whether the IoT device has a memory corruption vulnerability according to the connection status.

[0131] As another example, the apparatus 400 further includes:

[0132] A second sending unit, configured to send a Ping command to a client program of the IoT device;

[0133] The monitoring unit 403 includes:

[0134] A second monitoring subunit is configured to monitor whether the IoT device responds to the Ping command;

[0135] The second determining subunit is used to determine whether the IoT device has a command injection vulnerability based on the response.

[0136] In addition, the embodiment of the present application also provides a vulnerability mining system 500, such as Figure 5 As shown, the system 500 includes: a middleman traffic proxy module 501, a fuzzy testing engine 502 and an abnormal information capturer 503, wherein:

[0137] The middleman traffic proxy module 501 is used to obtain traffic information sent by the application on the terminal device to the IoT device through the cloud server;

[0138] The fuzz testing engine 502 is used to perform fuzz testing on the client program on the IoT device based on the traffic information;

[0139] The exception information capturer 503 is used to monitor exceptions in the fuzz test and determine the vulnerabilities of the IoT device.

[0140] It should be noted that the middleman traffic proxy module 501, the fuzzy test engine 502 and the abnormal information capturer 503 in this embodiment can be specifically referred to above. Figure 2 The relevant descriptions of the middleman traffic proxy module 10, the fuzzy testing engine 20 and the abnormal information capturer 30 are not repeated here.

[0141] As an example, the cloud server sends the traffic information to the IoT device through a gateway, and the vulnerability mining system 500 is integrated into the gateway.

[0142] As another example, the cloud server sends the traffic information to the IoT device through a gateway, and the vulnerability mining system 500 communicates with the gateway.

[0143] In addition, the embodiment of the present application further provides an electronic device 600, such as Figure 6 As shown, the electronic device 600 includes a processor 601 and a memory 602:

[0144] The memory 602 is used to store computer programs;

[0145] The processor 601 is configured to execute the method provided in the embodiment of the present application according to the computer program.

[0146] In addition, an embodiment of the present application further provides a computer-readable storage medium, which is used to store a computer program, and the computer program is used to execute the method provided by the embodiment of the present application.

[0147] Through the description of the above embodiments, it can be known that those skilled in the art can clearly understand that all or part of the steps in the above embodiment methods can be implemented by means of software plus a general hardware platform. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a storage medium, such as a read-only memory (ROM) / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network communication device such as a router) to execute the methods described in each embodiment or certain parts of the embodiments of the present application.

[0148] Each embodiment in this specification is described in a progressive manner. The same or similar parts between the embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments and device embodiments, since they are basically similar to method embodiments, the description is relatively simple. For relevant parts, refer to the partial description of the method embodiment. The device and system embodiments described above are merely schematic. The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place or distributed on 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 making any creative effort.

[0149] The above description is only a preferred embodiment of the present application and is not intended to limit the scope of protection of the present application. It should be noted that those skilled in the art may make several improvements and modifications without departing from the scope of protection of the present application, and such improvements and modifications should also be considered as within the scope of protection of the present application.

Claims

1. A vulnerability mining method, characterized in that: include: Obtaining traffic information sent by an application on a terminal device to an IoT device via a cloud server through a middleman proxy; wherein the cloud server and the IoT device interact via a persistent connection protocol; Using the traffic information as a test set seed, mutating the test set seed to generate test data, sending the test data to a client program on the IoT device, and performing a fuzz test on the client program on the IoT device based on the test data; Monitor anomalies in the fuzz test to determine vulnerabilities of the IoT device.

2. The method according to claim 1, characterized in that The cloud server sends the traffic information to the IoT device through the gateway, and the acquiring of the traffic information sent by the application on the terminal device to the IoT device through the cloud server includes: The traffic information is obtained through the gateway.

3. The method according to claim 2, characterized in that The gateway modifies, through a kernel interface, a destination address and a port for sending traffic information from the terminal device to the IoT device, wherein obtaining the traffic information through the gateway includes: receiving, from the gateway, the traffic information sent by the terminal device based on the modified destination address and port; After obtaining the traffic information through the gateway, the method further includes: Based on the repaired destination address and port, the traffic information is sent to the IoT device through the gateway, wherein the repaired destination address and port are the results after the gateway repairs the destination address and port of the traffic information sent by the terminal device to the IoT device through the kernel interface.

4. The method according to claim 1, wherein The monitoring of anomalies in the fuzz test and determining the vulnerability of the IoT device includes: Monitoring the connection status between the cloud server and the IoT device; Determine whether the IoT device has a memory corruption vulnerability based on the connection status.

5. The method according to claim 1, wherein The method further comprises: Send a Ping command to the client program of the IoT device; The monitoring of anomalies in the fuzz test and determining the vulnerability of the IoT device includes: Monitor whether the IoT device responds to the Ping command; According to the response, it is determined that the IoT device has a command injection vulnerability.

6. A device for vulnerability mining, characterized in that: include: An acquisition unit, configured to acquire traffic information sent by an application on a terminal device to an IoT device via a cloud server; wherein the cloud server and the IoT device interact via a persistent connection protocol; a testing unit, configured to use the traffic information as a test set seed, mutate the test set seed to generate test data, send the test data to a client program on the IoT device, and perform a fuzz test on the client program on the IoT device based on the test data; The monitoring unit is used to monitor anomalies in the fuzzy test and determine the vulnerabilities of the IoT device.

7. A vulnerability mining system, characterized in that: include: The middleman traffic proxy module, fuzz testing engine and abnormal information capturer, including: The middleman traffic proxy module is used to obtain traffic information sent by the application on the terminal device to the IoT device through the cloud server; wherein the cloud server and the IoT device interact with each other through a long connection protocol; The fuzz testing engine is configured to use the traffic information as a test set seed, mutate the test set seed to generate test data, send the test data to the client program on the IoT device, and perform fuzz testing on the client program on the IoT device based on the test data; The abnormal information capturer is used to monitor abnormalities in the fuzzy test and determine the vulnerabilities of the IoT device.

8. The system according to claim 7, characterized in that The cloud server sends the traffic information to the IoT device through a gateway, and the vulnerability mining system is integrated into the gateway.

9. The system according to claim 7, wherein: The cloud server sends the traffic information to the IoT device through a gateway, and the vulnerability mining system communicates with the gateway.

10. An electronic device, characterized in that: The electronic device includes a processor and a memory: The memory is used to store computer programs; The processor is configured to execute the method according to any one of claims 1 to 5 according to the computer program.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium is used to store a computer program, and the computer program is used to execute the method according to any one of claims 1 to 5.

Images