Internet of Things equipment vulnerability detection method and system based on sensitive target guidance

Abstract

The invention relates to the technical field of Internet of Things equipment security detection, in particular to an Internet of Things equipment vulnerability detection method and system based on sensitive target guidance, and the method comprises the steps: extracting firmware key information of to-be-detected equipment; obtaining potential sensitive targets and paths in firmware of the to-be-detected equipment and basic block positions corresponding to the sensitive targets and the paths through reachable data streams in decompilation code execution; performing pruning operation on the control flow diagram in the key information according to the positions of the basic blocks corresponding to the sensitive target and the path, and obtaining a test space related to the sensitive target and the path; variation is carried out on request processing information, parameter information and control information in the test space, and the test case is guided to be executed to a sensitive target; and performing collapse variation on the sensitive function parameters in the test space, triggering the firmware vulnerability of the to-be-detected equipment in the execution process of the test case, and generating a test result. According to the method, the blindness of fuzzy testing is reduced, and the method has good adaptability to firmware analysis of embedded equipment.

Description

Technical Field

[0001] The present invention relates to the technical field of security detection of Internet of Things devices, and in particular to a method and system for vulnerability detection of Internet of Things devices based on sensitive target orientation. Background Art

[0002] IoT devices are increasingly used in people's daily lives, including smart watches, electronic cars, smart homes, etc. However, due to limited device resources and difficulty in firmware updates, IoT devices have become the main target of cyber attacks. Among all IoT devices, wireless routers and network cameras suffer more attacks than other embedded devices, mainly because the web services they provide expose exploitable vulnerabilities.

[0003] Existing vulnerability mining technologies mainly include static analysis and fuzz testing, and fuzz testing can be divided into black-box fuzz testing and gray-box fuzz testing. Static analysis is a technology that detects potential vulnerabilities by analyzing the source code or binary code of the target system. It does not need to run the target program, but identifies security vulnerabilities in the code through symbolic execution, data flow analysis, control flow analysis, etc. Static analysis can detect problems such as buffer overflow, command injection, format string vulnerabilities, etc. Static analysis is often used to analyze the firmware code of embedded devices, especially the back-end code for Web service programs. By analyzing dangerous function calls (such as strcpy, sscanf, etc.) in the firmware, static analysis can identify potential vulnerability points. It can analyze the entire code base, covering all possible execution paths, and is suitable for resource-constrained embedded devices. Black-box fuzz testing is a testing method that does not rely on the internal structure of the target system. It generates a large amount of random or semi-random input data, sends it to the target system, and observes the response behavior of the system to discover potential vulnerabilities. Black-box fuzz testing does not require access to the source code or binary code of the target system, and is suitable for testing unknown systems. Black-box fuzz testing is often used to test the Web service interface of IoT devices (such as HTTP request processing). Since the firmware of embedded devices is usually difficult to obtain or analyze, black-box testing has become a common vulnerability discovery method. It does not require access to the internal structure of the target system, is suitable for testing unknown systems, is simple to implement, and is easy to deploy. Gray-box fuzz testing combines the advantages of black-box testing and static analysis, and generates more targeted test inputs by partially understanding the internal structure of the target system (such as control flow graphs, coverage information, etc.). Gray-box testing usually relies on instrumentation technology to collect execution path information of the target program and adjust the test strategy based on coverage feedback. The application of gray-box fuzz testing in embedded devices usually relies on firmware rehosting technology, that is, running the firmware in a simulation environment to insert stubs and collect coverage information. Common gray-box testing tools include AFL (American Fuzzy Lop) and its variants (such as Firm-AFL). It can more effectively explore the execution path of the target system through coverage feedback.

[0004] Existing vulnerability detection technologies have their own advantages and disadvantages on embedded devices. Black-box testing is simple and easy to use, but inefficient; static analysis is comprehensive but has a high false alarm rate; gray-box testing is efficient, but relies on firmware re-hosting and has limited adaptability. Black-box fuzz testing does not rely on program simulation, but lacks detailed program execution guidance information and is highly blind. Black-box fuzz testing can be carried out directly on real devices and can test firmware that cannot be re-hosted. It infers the device status based on device responses. This method lacks detailed program execution guidance information, such as coverage, and is blind. Therefore, existing work mainly focuses on how to obtain more feedback information, such as inferring program execution coverage through responses, but this inference is rough and is not applicable to devices with less response information. Gray-box fuzz testing relies on firmware simulation and cannot test devices that cannot be simulated. Gray-box fuzz testing for firmware programs is highly dependent on firmware simulation, and firmware simulation is also a challenging task due to the high dependence of firmware on hardware. Therefore, existing work mainly focuses on how to simulate firmware with high fidelity and increase scalability, thereby improving fuzz testing efficiency. For firmware or real devices that cannot be simulated, it is impossible to collect program execution information such as program coverage, so this gray box method cannot be used for testing. Moreover, gray box fuzz testing is mainly based on AFL, which cannot effectively mutate structured service program data packets. Existing gray box fuzz testing is mainly based on AFL, which was originally used to test standard input and output programs, and its mutation strategy is random. However, network service programs usually need to send network data packets and are structured. Using AFL to directly perform fuzz testing usually destroys the data packet structure and cannot trigger deeper paths of the program. In terms of static analysis, most of the current research focuses on taint analysis technology. The current challenges are to identify external input entry points and design taint propagation engines for firmware programs. There are problems such as low analysis efficiency and high false positive rate. For example, Karonte and SaTC use taint analysis technology, but their inaccurate identification of pollution sources leads to a large number of data flows to be analyzed. Secondly, they use symbolic execution based on Angr. Due to the limitations of this technology itself, their taint analysis efficiency is low and the false positive rate is high. Therefore, there is an urgent need for an efficient, accurate and adaptable IoT device vulnerability detection and analysis solution to address the shortcomings of existing technologies in vulnerability detection of IoT embedded devices. Summary of the invention

[0005] To this end, the present invention provides a sensitive target-oriented vulnerability detection method and system for Internet of Things devices to solve the problems of low efficiency, high false alarm rate and limited applicability of existing vulnerability detection.

[0006] According to the design scheme provided by the present invention, on the one hand, a method for detecting vulnerability of IoT devices based on sensitive target orientation is provided, comprising:

[0007] Perform static analysis on the firmware of the device to be tested and extract key information in the firmware, including: external input source parameter parsing function, request processing information, parameter information, control information, sensitive functions and control flow graph;

[0008] Based on the key information and the reachable data flow in the decompiled code execution, the potential sensitive targets and paths in the firmware of the device to be detected are obtained, and the basic block locations corresponding to the sensitive targets and paths are obtained;

[0009] Prune the control flow graph in the key information according to the basic block positions corresponding to the sensitive targets and paths, and obtain the test space related to the sensitive targets and paths;

[0010] The request processing information, parameter information and control information in the test space are mutated to guide the test case execution to the sensitive target; and the sensitive function parameters in the test space are crash-mutated to trigger the firmware vulnerability of the device to be tested during the test case execution and generate test results.

[0011] As a sensitive target-oriented IoT device vulnerability detection method of the present invention, further, static analysis is performed on the firmware of the device to be detected, including:

[0012] Identify the parameter parsing function in the firmware based on multi-feature matching, the parameter parsing function is a function that is frequently called in the request processing function, the multi-feature matching includes: parameter string features shared by the front-end and back-end and structure variable features that store request data, the high-frequency call is a function call whose number of function calls is greater than a preset value;

[0013] Starting from the starting basic block of the request processing function, obtain the basic block and its subsequent basic block information in the firmware binary program, build a control flow graph based on the node and edge information of the basic block, and extract key values ​​and constraint information affecting the control flow based on the function call in the basic block, wherein the key value is a parameter of the external input source parameter parsing function;

[0014] Obtain sensitive functions in the firmware, use a decompilation tool to generate the decompiled code of the firmware, and obtain the function call location mapping relationship in the decompiled code.

[0015] As a sensitive target-oriented IoT device vulnerability detection method of the present invention, further, a parameter parsing function in the firmware is identified based on multi-feature matching, including:

[0016] Extract the parameter string shared by the frontend and backend;

[0017] Locate the function call position with the shared parameter string as a parameter within the scope of influence of the request processing function according to the shared parameter string, and determine whether there is another parameter of variable type in the function;

[0018] If there is another parameter of variable type, count and record the functions with loop and strcmp-like string features and the number of function calls within the scope of influence of the request processing function;

[0019] Sort the recorded functions according to the number of function calls, and use the function with the highest frequency of function calls as the parameter parsing function.

[0020] As a sensitive target-oriented IoT device vulnerability detection method of the present invention, further, the potential sensitive targets and paths in the firmware of the device to be detected are obtained by decompiling the reachable data flow in the code execution, including:

[0021] The parameter values ​​in the parameter parsing function are used as the external parameter input source, and the parameters of the sensitive function are used as the sensitive function call sink point. The static data flow analysis tool is used to obtain the sensitive function call location and the sensitive data flow path and dependency relationship between the sink point and the external parameter input source.

[0022] Sensitive data flow paths and dependencies are classified, and each type of sensitive data flow path information is aggregated based on the classification results. The path between the external parameter input source and the sink point is converted into the path between the starting point of the operation processing function and the sink point, so as to obtain the basic block position corresponding to the sensitive target and the path based on the path between the starting point of the operation processing function and the sink point.

[0023] As a sensitive target-oriented IoT device vulnerability detection method of the present invention, further, the path between the external parameter input source and the sink point is converted into a path between the starting point of the operation processing function and the sink point, including:

[0024] According to whether the external parameter input source and the sink point belong to the same function and the relationship between the two and the operation processing function, the sensitive data flow path is classified into four analysis types, which include: the external parameter input source and the sink point belong to the same function and are both located in the operation processing function; the external parameter input source and the sink point do not belong to the same function, but the external parameter input source is located in the operation processing function; the external parameter input source and the sink point belong to the same function, but neither of them is located in the operation processing function; the external parameter input source and the sink point do not belong to the same function, and the external parameter input source is not located in the operation processing function;

[0025] When the external parameter input source is located in the starting point function, the intra-process and inter-process path exploration is performed according to the data flow analysis path. When the external parameter input source is not located in the starting point function, the cross-reference and breadth-first strategy is used to recursively search upward for the operation processing function until the starting point function is encountered. The complete path from the starting point function to the sink point is obtained through path recursive exploration to achieve the conversion from the external parameter input source and sink point path to the operation processing function starting point and sink point path, and the entry point and exit point in the function in the path are retained during the exploration to convert the entry point and exit point positions into the basic block positions of the firmware binary program, the entry point is the starting position of the corresponding function in the path, and the exit point is the function call position to the next function in the path or the final sensitive function call position.

[0026] As a sensitive target-oriented IoT device vulnerability detection method of the present invention, further, a control flow graph in key information is pruned according to the basic block position corresponding to the sensitive target and the path, including:

[0027] Obtain the function call path and the local starting point and local target point in each function according to the basic block position corresponding to the sensitive target and the path, wherein the local starting point is the function start basic block, and the local target point is the basic block where the function call is located when the current function enters the next function;

[0028] Based on the function call path and by traversing the reverse control flow graph, the basic blocks contained in all paths from the local starting point to the local target point in each function in the path are obtained, and the basic block sets and edge basic blocks of the path from the external parameter input source to the sink point are obtained by taking the union of the basic blocks, so as to construct the pruned control flow graph based on the obtained basic block set.

[0029] As the vulnerability detection method of IoT devices based on sensitive target orientation of the present invention, further, the request processing information, parameter information and control information in the test space are mutated, including:

[0030] For each request processing information and the corresponding request processing function, obtaining test data for the current processing information, wherein the test data includes all basic block spaces, basic block key value unions and all constraint unions for targeted testing, wherein the basic block key value is a parameter of an external input source parameter parsing function in the basic block;

[0031] The union of all constraints is used as a subset of the targeted test parameter value variation dictionary, and the breakpoint position of the targeted test is set according to the basic block space, so as to guide the test program to execute to the target basic block by using the breakpoint;

[0032] The parameter values ​​are mutated and the program path is explored according to a mutation strategy, wherein the mutation strategy includes numerical value mutation within a limited range and / or string length mutation.

[0033] As the vulnerability detection method of IoT devices based on sensitive target orientation of the present invention, further, a crash mutation is performed on sensitive function parameters in the test space, including:

[0034] Mutating the parameters of the sensitive function according to a crash mutation strategy, wherein the crash mutation strategy includes: setting the parameter to a string of a specified length and / or replacing an integer parameter with a specified value and / or injecting a command execution string into the parameter;

[0035] The breakpoint position of the crash test is set according to the basic block space. Based on the mutated sensitive function parameters and using the breakpoints, the test program is guided to execute to the target basic block to trigger the sensitive function crash test. The program exception detection results are executed and recorded. The program exception detection includes: stack overflow detection, command execution detection and request response detection.

[0036] On the other hand, the present invention also provides an IoT device vulnerability detection system based on sensitive target orientation, comprising: an information extraction module, a path construction module, a program pruning module and a mutation testing module, wherein:

[0037] An information acquisition module is used to perform static analysis on the firmware of the device to be detected and extract key information from the firmware, wherein the key information includes: external input source parameter parsing function, request processing information, parameter information, control information, sensitive functions and control flow graph;

[0038] A path building module is used to obtain potential sensitive targets and paths in the firmware of the device to be detected based on key information and through the reachable data flow in the decompiled code execution, and obtain the basic block locations corresponding to the sensitive targets and paths;

[0039] A program pruning module is used to prune the control flow graph in the key information according to the basic block positions corresponding to the sensitive targets and paths, and obtain the test space related to the sensitive targets and paths;

[0040] The mutation test module is used to mutate the request processing information, parameter information and control information in the test space to guide the test case execution to the sensitive target; and to perform crash mutation on the sensitive function parameters in the test space to trigger the firmware vulnerability of the device to be tested during the test case execution and generate test results.

[0041] Beneficial effects of the present invention:

[0042] 1. The present invention utilizes multiple features to identify the entry point of external input, and based on the sensitive data flow analysis of the decompiled code, quickly finds the sensitive targets and paths affected by the external input source, and uses them as test objects, and utilizes the debugging interface to collect program execution feedback information. Based on the program pruning method, the program is guided to reach the sensitive target and perform efficient, accurate and adaptable fuzz testing, thereby reducing the blindness of fuzz testing, effectively solving the deficiencies of the prior art in vulnerability detection of IoT embedded devices, and having good adaptability to firmware analysis of embedded devices.

[0043] 2. The present invention significantly improves the accuracy of external input source identification by introducing more features (such as loop structures, string comparison functions, etc.), and can more accurately locate external input sources; by decompiling firmware code and combining sensitive data flow analysis, external input sources (sources) and dangerous function call points (sinks) can be quickly identified, and potential dangerous paths can be extracted. Compared with traditional static analysis methods (such as symbolic execution), decompiled code analysis significantly reduces computational complexity and improves analysis efficiency.

[0044] 3. The present invention uses a debugging interface to collect coverage, and guides program execution to a specified target and performs testing based on program tailoring and high-quality mutation strategies. It does not rely on firmware rehosting technology, can be flexibly applied in real devices and simulation environments, and has good scalability; and by pruning the control flow graph (CFG), only paths related to sensitive targets are retained, which significantly reduces the exploration space of fuzz testing. Fuzz testing is divided into two stages: path exploration and vulnerability triggering. In the path exploration stage, the program is guided to execute to sensitive targets by mutating input parameters; in the vulnerability triggering stage, dangerous parameters are subjected to crash mutations to trigger vulnerabilities and generate PoC (Proof of Concept, often referring to a piece of code that proves a vulnerability). Compared with traditional random mutation strategies, the phased strategy of the present invention significantly improves the efficiency of vulnerability triggering. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 The following is a schematic diagram of a vulnerability detection process of an IoT device based on sensitive target orientation in an embodiment;

[0046] Figure 2 The following is a schematic diagram of the principle of the vulnerability detection algorithm for the Web service program of the Internet of Things device in the embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of the present invention clearer and more understandable, the present invention is further described in detail below in conjunction with the accompanying drawings and technical solutions.

[0048] In view of the deficiencies in the detection of IoT embedded devices in the prior art, the embodiments of the present invention refer to Figure 1As shown, a vulnerability detection method for IoT devices based on sensitive target orientation is provided by combining static analysis and dynamic analysis, including:

[0049] S101, statically analyzing the firmware of the device to be detected, and extracting key information in the firmware, wherein the key information includes: external input source parameter parsing function, request processing information, parameter information, control information, sensitive functions and control flow graph.

[0050] Specifically, static analysis of the firmware of the device to be tested can be designed to include:

[0051] Identify the parameter parsing function in the firmware based on multi-feature matching, the parameter parsing function is a function that is frequently called in the request processing function, the multi-feature matching includes: parameter string features shared by the front-end and back-end and structure variable features that store request data, the high-frequency call is a function call whose number of function calls is greater than a preset value;

[0052] Starting from the starting basic block of the request processing function, obtain the basic block and its subsequent basic block information in the firmware binary program, build a control flow graph based on the node and edge information of the basic block, and extract key values ​​and constraint information affecting the control flow based on the function call in the basic block, wherein the key value is a parameter of the external input source parameter parsing function;

[0053] Obtain sensitive functions in the firmware, use a decompilation tool to generate the decompiled code of the firmware, and obtain the function call location mapping relationship in the decompiled code.

[0054] like Figure 2 As shown in the figure, multiple features are used to identify external input entry points, and then sensitive targets and paths affected by external input sources are quickly found based on sensitive data flow analysis of decompiled code, and they are used as test objects. Finally, the debugging interface is used to collect program execution feedback information, and the program is guided to reach sensitive targets and perform fuzz testing based on the program pruning method. Among them, static information extraction is performed on the firmware program to be analyzed, including request and processing function mapping information, external input parameter parsing function, basic block information, parameter and value information, etc., to assist the subsequent sensitive target extraction and fuzz testing stage. The recognition accuracy can be improved by using parameter parsing function recognition based on shared keywords and multi-feature matching.

[0055] Among them, the parameter parsing function in the firmware based on multi-feature matching recognition may include:

[0056] Extract the parameter string shared by the frontend and backend;

[0057] Locate the function call position with the shared parameter string as a parameter within the scope of influence of the request processing function according to the shared parameter string, and determine whether there is another parameter of variable type in the function;

[0058] If there is another parameter of variable type, count and record the functions with loop and strcmp-like string features and the number of function calls within the scope of influence of the request processing function;

[0059] Sort the recorded functions according to the number of function calls, and use the function with the highest frequency of function calls as the parameter parsing function.

[0060] The existing method locates the shared keywords between the front-end and back-end as references to function call parameters on the back-end, and uses the most frequently appearing function as an external parameter parsing function. However, some settings or comparison functions of the back-end program will also use this keyword as a calling parameter, resulting in false positives. On this basis, in the embodiment of this case, the accuracy is further improved by introducing more features for identification. Specifically, one parameter of the parameter parsing function is a structure variable that stores the request data, another parameter is a shared keyword between the front-end and back-end, and there is usually a third parameter set as a default value, but it is not used as a necessary feature. Inside the parameter parsing function, there will be loops and string comparisons like strcmp, which are used to match the parsed parameter value with the requested parameter list and extract its value. Finally, the parameter parsing function is usually called frequently within the request processing function.

[0061] The specific algorithm content of parameter parsing function identification may include the following steps: First, perform static analysis on the front-end page file to extract the parameter string shared by the front-end and back-end. Then, locate the position of the function call with the shared parameter string as a parameter within the scope of influence of the request processing function, and determine whether there is another parameter of variable type. If satisfied, further determine whether there are loops and strcmp-like functions inside the function, and count the functions and call times that meet this feature. Record each analyzed function to reduce the time overhead when the same function is analyzed next time. Finally, sort the function calls that meet the requirements, and identify the function with the highest call frequency as the parameter parsing function.

[0062] In order to achieve subsequent path exploration and vulnerability verification, it is necessary to extract binary basic blocks and mutation auxiliary information. In this embodiment, the analysis starts from the request processing function start basic block, obtains the basic block and its subsequent basic block information, and constructs a CFG graph based on the node and edge information of the basic block.

[0063] When the backend processing function processes the user request, different processing is performed according to the parameters passed in by the user and their values. Therefore, the program can be guided to different locations by controlling the parameter settings in the data packet. The keys and possible value constraints required for this request are extracted in static analysis. While analyzing the basic block, the key-value relationship and constraints are extracted based on the function calls in the basic block.

[0064] The key-value parameters are parsed by the external input parameter parsing function identified previously. By tracing the function call of the function, the parameters it parses, i.e., the key values, are extracted. Then, the constraint information about the HTTP request parameters affecting the control flow under the processing function is further collected. The solution in this case does not accurately identify the detailed constraint information of each parameter, but simply collects the key strings and values ​​that affect the control flow, and adds them to the mutation of the later exploration part to bypass the key control nodes. Specifically, the conditions for processing basic block branch jump statements are collected, the constant strings used when the strcmp-like function is compared, and the values ​​used when comparing values. For the parameter parsing function, it usually provides a default value parameter, indicating that this default value is used instead when the specified parameter is not set. It can also be collected as a subset of the parameter value constraint combination.

[0065] The decompiled code of the original firmware program is generated based on the existing decompilation tools. At the same time, during the generation process, the mapping relationship between the function call line number in the decompiled code and the function call address in the program is obtained. The mapping relationship between the function call and the basic block in which it is located will also be extracted during the subsequent static analysis of the binary program.

[0066] S102, based on the key information and through the reachable data flow in the decompiled code execution, obtain the potential sensitive targets and paths in the firmware of the device to be detected, and obtain the basic block positions corresponding to the sensitive targets and paths.

[0067] Specifically, the potential sensitive targets and paths in the firmware of the device to be detected are obtained by decompiling the reachable data flow in the code execution, which may include:

[0068] The parameter values ​​in the parameter parsing function are used as the external parameter input source, and the parameters of the sensitive function are used as the sensitive function call sink point. The static data flow analysis tool is used to obtain the sensitive function call location and the sensitive data flow path and dependency relationship between the sink point and the external parameter input source.

[0069] Sensitive data flow paths and dependencies are classified to aggregate the information of each type of sensitive data flow path based on the classification results, and the path between the external parameter input source and the sink point is converted into the path between the starting point of the operation processing function and the sink point, so as to obtain the basic block position corresponding to the sensitive target and the path based on the path between the starting point of the operation processing function and the sink point.

[0070] The parameter values ​​extracted from the parameter parsing function identified in the previous stage are used as the source point of data flow analysis, and the dangerous parameters of common dangerous functions are used as sink points. Then, data reachability analysis is performed based on the existing source code-based static data flow analysis tool Joern, which allows the dangerous function call locations that may have security risks to be obtained, as well as the dependency relationship between their dangerous parameters and external input sources.

[0071] For the subsequent dynamic automatic verification, the analysis results need to be sorted out. The dangerous data flow analysis results are divided into four categories: a. source and sink belong to the same function, and both are operation processing functions; b. source and sink are not the same function, but the source is in the operation processing function; c. source and sink are in the same function, but not the operation processing function; d. source and sink are not the same function, and the source is not in the operation processing function.

[0072] The starting point of dynamic analysis can be set to the handle function. Therefore, when the source is located in the handle function, the intra-procedural and inter-procedural paths can be directly explored according to the data flow analysis path. When the source is not located in the handle function, it is necessary to find a path from the entrance of a handle function to the function where the source is located, and then connect the path from the source to the sink in the data flow analysis to form a complete path from the handle function to the sink. For this, the cross-reference method can be used to recursively search upwards for calling functions containing the source according to the breadth-first strategy until the handle function is encountered. The depth of recursion can be defined to prevent continuous exploration of unreachable paths.

[0073] When the source and sink are in the same function, only the sink point position needs to be retained. When they are not in the same function, the calling relationship between the processes needs to be considered. Only the entry point and exit point in the function in the data flow analysis path are retained. The entry point is the starting position of the function, and the exit point is the function call to the next function or the final dangerous function call. And the positions of the entry point and exit point are converted to the basic block positions in the binary based on the mapping relationship constructed previously.

[0074] S103, performing pruning operations on the control flow graph in the key information according to the basic block positions corresponding to the sensitive targets and paths, and obtaining the test space related to the sensitive targets and paths.

[0075] Specifically, the control flow graph in the key information is pruned according to the basic block positions corresponding to the sensitive targets and paths, which may include:

[0076] Obtain the function call path and the local starting point and local target point in each function according to the basic block position corresponding to the sensitive target and the path, wherein the local starting point is the function start basic block, and the local target point is the basic block where the function call is located when the current function enters the next function;

[0077] Based on the function call path and by traversing the reverse control flow graph, the basic blocks contained in all paths from the local starting point to the local target point in each function in the path are obtained, and the basic block sets and edge basic blocks of the path from the external parameter input source to the sink point are obtained by taking the union of the basic blocks, so as to construct the pruned control flow graph based on the obtained basic block set.

[0078] In the embodiment of this case, the debugging interface can be used to collect program execution information, and the target program can be connected based on GDB. Dynamic instrumentation can be achieved through the setting and processing of breakpoints during program execution. The solution does not rely on firmware re-hosting technology and can also be used on real devices, with good scalability.

[0079] In order to guide the program to execute from the entry point of the processing function to the target point, the program can be "pruned" to keep only the basic blocks related to the dangerous path. For each processing function, the entry point is the starting basic block, and the last node becomes the basic block containing the target point or the basic block leading to the next function in the call chain, and the intermediate paths all lead to the last node. Therefore, for all sets of these basic blocks, each increase in their coverage means that the distance to the sink basic block is closer. Therefore, the reduction in the distance to the target basic block can be converted into an increase in the coverage of the pruned program.

[0080] Since the path from the entry basic block of the processing function to the target sink point basic block may be cross-function, the path pruning and the acquisition of related basic blocks are divided into intra-procedural and inter-procedural. First, based on the data flow analysis results of the previous process, the function call and the location of the function call point in the process from the source point to the target node can be obtained, and then the function call path and the local starting point and local target point in each function can be obtained. The local starting point is the starting basic block of this function, and the local target point is the basic block where the function calls from this function to the next function. Solve the basic blocks contained in all paths from the local starting point to the local target point in each function in the function call path. Finally, the union of these basic blocks is the set of all basic blocks from the source to the sink point, which constitute the pruned CFG.

[0081] For each function, all paths from the local starting point to the local target point include the acquisition of basic blocks, which are obtained by traversing the reverse CFG. The target basic block in the reverse CFG is used as the starting point, and the basic blocks in the process of reaching the function entry basic block are explored through the breadth-first algorithm. These basic blocks are the basic block sets on all possible paths from the function entry basic block to the target basic block. Since all basic blocks start from the function entry basic block, searching for these basic block sets through the reverse CFG instead of the CFG can greatly reduce the exploration overhead, because the latter will explore all nodes in the CFG from the starting node, while the former is only a related part.

[0082] Collect coverage at the granularity of basic blocks. Get all the basic blocks extracted above as the coverage space, extract their addresses and save them as allow_addrs. In addition, you can get edge basic blocks, which are the successors of the relevant basic blocks and are not in the relevant basic block set. That is, when you reach the edge basic block, it means that you have exceeded the space to be explored. Collect their addresses and save them as avoid_addrs.

[0083] S104, mutate the request processing information, parameter information and control information in the test space to guide the test case execution to the sensitive target; and perform crash mutation on the sensitive function parameters in the test space to trigger the firmware vulnerability of the device to be tested during the test case execution and generate test results.

[0084] Specifically, mutating the request processing information, parameter information, and control information in the test space may include:

[0085] For each request processing information and the corresponding request processing function, obtaining test data for the current processing information, wherein the test data includes all basic block spaces, basic block key value unions and all constraint unions for targeted testing, wherein the basic block key value is a parameter of an external input source parameter parsing function in the basic block;

[0086] The union of all constraints is used as a subset of the targeted test parameter value variation dictionary, and the breakpoint position of the targeted test is set according to the basic block space, so as to guide the test program to execute to the target basic block by using the breakpoint;

[0087] The parameter values ​​are mutated and the program path is explored according to a mutation strategy, wherein the mutation strategy includes numerical value mutation within a limited range and / or string length mutation.

[0088] Based on the method of mutating the input data parameter value, the program path is explored, and the program execution is guided to the target basic block by setting the exploration space through breakpoints. In the test data generation and mutation, the embodiment of this case does not collect seeds, but generates input requests in an automated way. Since the main information affecting the execution of the back-end program is the request URL and parameter settings, the relationship between different request URLs and their corresponding processing functions is collected in the front, and the information of the parameter key values ​​contained in the basic block is collected. For each test, for a URL and a processing function, the union of the key values ​​in all basic blocks related to this test is used as the key value of this test, and the union of all constraints is used as a subset of the parameter value mutation dictionary for this test. In addition, common data types in SOHO devices can also be added, such as time, IP address, Mac address, etc. This part of the mutation is only for exploring the path, and the program crash is not expected. Therefore, the mutation only needs to provide some normal values ​​and simple mutation strategies, such as changes in digital values ​​and string lengths within a limited range.

[0089] Breakpoint setting and processing. Based on the basic block space of this test, set breakpoints at the addresses in allow_addrs and avoid_addrs. Take allow_addrs as the total exploration space with a coverage rate of 1. During the test, when an address in avoid_addrs is encountered, stop the tracking program. When an address in allow_addrs is encountered, determine whether it is the first access, that is, the increase in coverage. If so, record the parameters and values ​​of the newly added mutation. Finally, when the target address is encountered, record the test data and end the exploration.

[0090] Specifically, performing a crash mutation on sensitive function parameters in the test space may include:

[0091] Mutating the parameters of the sensitive function according to a crash mutation strategy, wherein the crash mutation strategy includes: setting the parameter to a string of a specified length and / or replacing an integer parameter with a specified value and / or injecting a command execution string into the parameter;

[0092] The breakpoint position of the crash test is set according to the basic block space. Based on the mutated sensitive function parameters and using the breakpoints, the test program is guided to execute to the target basic block to trigger the sensitive function crash test. The program exception detection results are executed and recorded. The program exception detection includes: stack overflow detection, command execution detection and request response detection.

[0093] Based on the previous sensitive data flow analysis, the parameters that affect the target dangerous function have been obtained. At this stage, the parameter value is mutated to trigger a crash. For example, an overlong string is set, an integer is replaced with a special integer value, and some command execution strings are injected.

[0094] Breakpoint processing. The breakpoints in this stage are set and processed as in the previous stage, but when the target point is reached, it does not end directly, but continues to execute and perform the exception detection mentioned below. In addition, the stack frame status of the current function will be recorded in this stage to help detect stack overflow vulnerabilities later. Among them, in the exception detection, the program exceptions can be detected as follows:

[0095] a. Stack overflow detection: Based on the debugging interface, the function stack frame information is established when each function is executed. During the program execution, whether the function stack frame is destroyed is detected to detect whether a buffer overflow occurs.

[0096] b. Command execution detection: Using a proxy server, after executing the basic block that may have a command execution vulnerability, it detects whether the proxy server is triggered to detect whether there is a command execution vulnerability.

[0097] c. Request response detection: Determine whether the program is abnormal by checking whether the request data packet is responded to and whether the program crashes.

[0098] Furthermore, based on the above method, the present invention also provides an IoT device vulnerability detection system based on sensitive target orientation, comprising: an information extraction module, a path construction module, a program pruning module and a mutation testing module, wherein:

[0099] An information acquisition module is used to perform static analysis on the firmware of the device to be detected and extract key information from the firmware, wherein the key information includes: external input source parameter parsing function, request processing information, parameter information, control information, sensitive functions and control flow graph;

[0100] A path building module is used to obtain potential sensitive targets and paths in the firmware of the device to be detected based on key information and through the reachable data flow in the decompiled code execution, and obtain the basic block locations corresponding to the sensitive targets and paths;

[0101] A program pruning module is used to prune the control flow graph in the key information according to the basic block positions corresponding to the sensitive targets and paths, and obtain the test space related to the sensitive targets and paths;

[0102] The mutation test module is used to mutate the request processing information, parameter information and control information in the test space to guide the test case execution to the sensitive target; and to perform crash mutation on the sensitive function parameters in the test space to trigger the firmware vulnerability of the device to be tested during the test case execution and generate test results.

[0103] Unless otherwise specifically stated, the relative steps, numerical expressions and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present invention.

[0104] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0105] The units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person of ordinary skill in the art may use different methods to implement the described functions for each specific application, but such implementation is not considered to be beyond the scope of the present invention.

[0106] Those skilled in the art will appreciate that all or part of the steps in the above method can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a disk or an optical disk. Optionally, all or part of the steps in the above embodiment can also be implemented using one or more integrated circuits, and accordingly, each module / unit in the above embodiment can be implemented in the form of hardware or in the form of software function modules. The present invention is not limited to any specific form of combination of hardware and software.

[0107] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes 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, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for detecting vulnerability of IoT devices based on sensitive target orientation, characterized in that: Include: Perform static analysis on the firmware of the device to be tested and extract key information in the firmware, including: external input source parameter parsing function, request processing information, parameter information, control information, sensitive functions and control flow graph; Based on the key information and through the reachable data flow in the decompiled code execution, the potential sensitive targets and paths in the firmware of the device to be detected are obtained, and the basic block locations corresponding to the sensitive targets and paths are obtained; Prune the control flow graph in the key information according to the basic block positions corresponding to the sensitive targets and paths, and obtain the test space related to the sensitive targets and paths; The request processing information, parameter information and control information in the test space are mutated to guide the test case execution to the sensitive target; and the sensitive function parameters in the test space are crash-mutated to trigger the firmware vulnerability of the device to be tested during the test case execution and generate test results.

2. The method for detecting vulnerability of IoT devices based on sensitive target orientation according to claim 1 is characterized in that: Perform static analysis on the firmware of the device to be tested, including: Identify the parameter parsing function in the firmware based on multi-feature matching, the parameter parsing function is a function that is frequently called in the request processing function, the multi-feature matching includes: parameter string features shared by the front-end and back-end and structure variable features that store request data, the high-frequency call is a function call whose number of function calls is greater than a preset value; Starting from the starting basic block of the request processing function, obtain the basic block and its subsequent basic block information in the firmware binary program, build a control flow graph based on the node and edge information of the basic block, and extract key values ​​and constraint information affecting the control flow based on the function call in the basic block, wherein the key value is a parameter of the external input source parameter parsing function; Obtain sensitive functions in the firmware, use a decompilation tool to generate the decompiled code of the firmware, and obtain the function call location mapping relationship in the decompiled code.

3. The method for detecting vulnerability of IoT devices based on sensitive target orientation according to claim 2 is characterized in that: Identify parameter parsing functions in firmware based on multi-feature matching, including: Extract the parameter string shared by the frontend and backend; Locate the function call position with the shared parameter string as a parameter within the scope of influence of the request processing function according to the shared parameter string, and determine whether there is another parameter of variable type in the function; If there is another parameter of variable type, count and record the functions with loop and strcmp-like string features and the number of function calls within the scope of influence of the request processing function; Sort the recorded functions according to the number of function calls, and use the function with the highest frequency of function calls as the parameter parsing function.

4. The method for detecting vulnerability of IoT devices based on sensitive target orientation according to claim 1 is characterized in that: By decompiling the reachable data flow in the code execution, we can obtain the potential sensitive targets and paths in the firmware of the device to be detected, including: The parameter values ​​in the parameter parsing function are used as the external parameter input source, and the parameters of the sensitive function are used as the sensitive function call sink point. The static data flow analysis tool is used to obtain the sensitive function call location and the sensitive data flow path and dependency relationship between the sink point and the external parameter input source. Sensitive data flow paths and dependencies are classified, and each type of sensitive data flow path information is aggregated based on the classification results. The path between the external parameter input source and the sink point is converted into the path between the starting point of the operation processing function and the sink point, so as to obtain the basic block position corresponding to the sensitive target and the path based on the path between the starting point of the operation processing function and the sink point.

5. The method for detecting vulnerability of IoT devices based on sensitive target orientation according to claim 4 is characterized in that: Convert the path between the external parameter input source and the sink point into the path between the operation processing function starting point and the sink point, including: According to whether the external parameter input source and the sink point belong to the same function and the relationship between the two and the operation processing function, the sensitive data flow path is classified into four analysis types, which include: the external parameter input source and the sink point belong to the same function and are both located in the operation processing function; the external parameter input source and the sink point do not belong to the same function, but the external parameter input source is located in the operation processing function; the external parameter input source and the sink point belong to the same function, but neither of them is located in the operation processing function; the external parameter input source and the sink point do not belong to the same function, and the external parameter input source is not located in the operation processing function; When the external parameter input source is located in the starting point function, the intra-process and inter-process path exploration is performed according to the data flow analysis path. When the external parameter input source is not located in the starting point function, the cross-reference and breadth-first strategy is used to recursively search upward for the operation processing function until the starting point function is encountered. The complete path from the starting point function to the sink point is obtained through path recursive exploration to achieve the conversion from the external parameter input source and sink point path to the operation processing function starting point and sink point path, and the entry point and exit point in the function in the path are retained during the exploration to convert the entry point and exit point positions into the basic block positions of the firmware binary program, the entry point is the starting position of the corresponding function in the path, and the exit point is the function call position to the next function in the path or the final sensitive function call position.

6. The method for detecting vulnerability of IoT devices based on sensitive target orientation according to claim 1 is characterized in that: Prune the control flow graph in the key information according to the basic block positions corresponding to the sensitive targets and paths, including: Obtain the function call path and the local starting point and local target point in each function according to the basic block position corresponding to the sensitive target and the path, wherein the local starting point is the function start basic block, and the local target point is the basic block where the function call is located when the current function enters the next function; Based on the function call path and by traversing the reverse control flow graph, the basic blocks contained in all paths from the local starting point to the local target point in each function in the path are obtained, and the basic block sets and edge basic blocks of the path from the external parameter input source to the sink point are obtained by taking the union of the basic blocks, so as to construct the pruned control flow graph based on the obtained basic block set.

7. The method for detecting vulnerability of IoT devices based on sensitive target orientation according to claim 1 is characterized in that: Mutate the request processing information, parameter information, and control information in the test space, including: For each request processing information and the corresponding request processing function, obtaining test data for the current processing information, wherein the test data includes all basic block spaces, basic block key value unions and all constraint unions for targeted testing, wherein the basic block key value is a parameter of an external input source parameter parsing function in the basic block; The union of all constraints is used as a subset of the targeted test parameter value variation dictionary, and the breakpoint position of the targeted test is set according to the basic block space, so as to guide the test program to execute to the target basic block by using the breakpoint; The parameter values ​​are mutated and the program path is explored according to a mutation strategy, wherein the mutation strategy includes numerical value mutation within a limited range and / or string length mutation.

8. The method for detecting vulnerability of IoT devices based on sensitive target orientation according to claim 1 is characterized in that: Perform crash mutation on sensitive function parameters in the test space, including: Mutating the parameters of the sensitive function according to a crash mutation strategy, wherein the crash mutation strategy includes: setting the parameter to a string of a specified length and / or replacing an integer parameter with a specified value and / or injecting a command execution string into the parameter; The breakpoint position of the crash test is set according to the basic block space. Based on the mutated sensitive function parameters and using the breakpoints, the test program is guided to execute to the target basic block to trigger the sensitive function crash test. The program exception detection results are executed and recorded. The program exception detection includes: stack overflow detection, command execution detection and request response detection.

9. A sensitive target-oriented IoT device vulnerability detection system, characterized in that: It includes: information extraction module, path construction module, program pruning module and mutation testing module, among which, An information acquisition module is used to perform static analysis on the firmware of the device to be detected and extract key information from the firmware, wherein the key information includes: external input source parameter parsing function, request processing information, parameter information, control information, sensitive functions and control flow graph; A path building module is used to obtain potential sensitive targets and paths in the firmware of the device to be detected based on key information and through the reachable data flow in the decompiled code execution, and obtain the basic block locations corresponding to the sensitive targets and paths; A program pruning module is used to prune the control flow graph in the key information according to the basic block positions corresponding to the sensitive targets and paths, and obtain the test space related to the sensitive targets and paths; The mutation test module is used to mutate the request processing information, parameter information and control information in the test space to guide the test case execution to the sensitive target; and to perform crash mutation on the sensitive function parameters in the test space to trigger the firmware vulnerability of the device to be tested during the test case execution and generate test results.

10. An electronic device, characterized in that: include: at least one processor, and a memory coupled to the at least one processor; The memory stores a computer program, and the computer program can be executed by the at least one processor to implement the method according to any one of claims 1 to 8.

Images