Firmware vulnerability mining method, device, equipment and storage medium

Abstract

The present invention provides a method, apparatus, device, and storage medium for firmware vulnerability mining. The method includes: extracting a front-end and back-end shared keyword set, wherein the front-end and back-end shared keyword set includes multiple front-end and back-end shared keywords; extracting the characteristics of each function in the program, locating intermediate taint sources based on the proportion of different function parameter strings in the front-end and back-end shared keyword set in the characteristics of each function, and using the located intermediate taint sources as the starting point of taint analysis; analyzing the types of function parameters of dangerous function call points based on static backtracing, filtering safe dangerous function call points, determining risky dangerous function call points, and using the risky dangerous function call points as the end point of taint analysis; and performing vulnerability mining based on the starting point and end point of taint analysis. The present invention can improve the speed of firmware vulnerability mining.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a method, apparatus, device and storage medium for firmware vulnerability mining. Background Art

[0002] As society continues to develop, IoT devices are becoming increasingly popular, greatly facilitating people's daily lives. However, at the same time, design flaws in IoT device firmware are becoming targets of various cyberattacks.

[0003] Among all IoT devices, internet-connected embedded devices, such as routers and webcams, are more vulnerable than other devices. The firmware of these devices is directly exposed to complex internet services with which users interact, and therefore often contains exploitable vulnerabilities. Furthermore, these devices serve as entry points into local networks, making them common targets for attacks against other IoT devices on the same network, such as smart plugs and robot vacuums.

[0004] Currently, the main method for detecting vulnerabilities in embedded firmware is through dynamic firmware analysis. However, dynamic firmware analysis methods mainly identify vulnerabilities by executing firmware programs, which has achieved good results. However, due to the wide variety of embedded devices (such as routers, network cameras, etc.) and their extreme dependence on different types of peripherals (such as sensors, timers, bus controllers, etc.), dynamic analysis methods are difficult to maintain effectiveness in multiple devices. Although static analysis methods are also used to detect vulnerabilities in embedded firmware, the inventors found that the vulnerability discovery time of existing static analysis methods is relatively long and cannot meet the current detection requirements. Summary of the Invention

[0005] Embodiments of the present invention provide a method, apparatus, device, and storage medium for firmware vulnerability mining to solve the problem that current static analysis methods require a long time for vulnerability mining.

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

[0007] Extracting a front-end and back-end shared keyword set, wherein the front-end and back-end shared keyword set includes a plurality of front-end and back-end shared keywords;

[0008] Extract the features of each function in the program. Based on the proportion of different function parameter strings in the shared keyword set between the front-end and back-end, locate the intermediate taint source. Use the located intermediate taint source as the starting point for taint analysis.

[0009] Based on static backtracing, the types of function parameters of dangerous function call points are analyzed, safe dangerous function call points are filtered, risky dangerous function call points are determined, and risky dangerous function call points are used as the end point of taint analysis;

[0010] Vulnerability mining is performed based on the starting point and end point of the taint analysis.

[0011] In one possible implementation, the characteristics of a function include the function name, the number of times the function is called in the embedded Web program, the number of different parameter strings in all calls to the function in the embedded Web program, the proportion of the different parameter strings of the function in the keyword set shared by the front-end and back-end, and a list of all parameter strings of the function.

[0012] In one possible implementation, the features of each function in the program are extracted, including:

[0013] Definition reachability analysis and call site analysis are performed based on the control flow graph and call graph generated by underconstrained symbolic execution to extract the characteristics of each function in the program.

[0014] In one possible implementation, based on the proportion of different strings in the function parameters in the front-end and back-end shared keyword sets in each function's signature, before locating the intermediate taint source, the following steps are also performed:

[0015] Based on the characteristics of each function, functions whose names are standard library function names, and / or functions whose number of calls in the embedded Web program is equal to 0, and / or functions whose number of parameter different character strings in all call locations in the embedded Web program is equal to 0 are filtered out from all functions to obtain candidate custom functions;

[0016] Based on the ratio of different parameter strings of each function in the candidate custom functions in the shared keyword set between the front-end and back-end, the first few functions with the highest ratio are identified as potential intermediate taint sources, and an intermediate taint source is determined from the potential intermediate taint sources.

[0017] In a possible implementation, based on static backtracing analysis of the types of function parameters at dangerous function call points, safe dangerous function call points are filtered out, and risky dangerous function call points are determined, including:

[0018] Based on static backtracing analysis of the types of function parameters of dangerous function call points, the preset dangerous function call points are determined to be safe dangerous function call points; wherein the preset dangerous function call points include multiple safe command hijacking dangerous function call points and multiple safe buffer overflow dangerous function call points;

[0019] Safe dangerous function call points are filtered out, and the remaining ones are risky dangerous function call points.

[0020] In one possible implementation, multiple safe command hijacking dangerous function call points include: passing a parameter as a constant string; passing a parameter as a variable, but the variable is assigned to a constant string before the call; passing a parameter as a variable, and the variable is a constant string result returned by the previous executed function;

[0021] Multiple safe buffer overflow dangerous function call sites include: passing a parameter as a constant string, and passing a parameter as a variable, but the variable is assigned to a constant string before the call.

[0022] In one possible implementation, vulnerability mining based on the starting point and the end point of the taint analysis includes:

[0023] Based on the starting point and the end point of the taint analysis, a taint analysis based on symbolic execution is performed.

[0024] In a second aspect, an embodiment of the present invention provides a device for detecting firmware vulnerabilities, including:

[0025] An extraction module, configured to extract a front-end and back-end shared keyword set, wherein the front-end and back-end shared keyword set includes a plurality of front-end and back-end shared keywords;

[0026] The starting point location module is used to extract the features of each function in the program. Based on the proportion of different function parameter strings in the front-end and back-end shared keyword sets in each function's features, it locates the intermediate taint source and uses the located intermediate taint source as the starting point for taint analysis.

[0027] The endpoint location module is used to analyze the types of function parameters of dangerous function call points based on static backtracing, filter out safe dangerous function call points, determine risky dangerous function call points, and use the risky dangerous function call points as the endpoint of the taint analysis;

[0028] The taint analysis module is used to perform vulnerability mining based on the starting point and end point of the taint analysis.

[0029] In a third aspect, an embodiment of the present invention provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the method described in the first aspect or any possible implementation of the first aspect are implemented.

[0030] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of the method described in the first aspect or any possible implementation of the first aspect.

[0031] The embodiment of the present invention provides a method, apparatus, device and storage medium for firmware vulnerability mining. Since network communication is the main source of threat to IoT devices, it is necessary to first extract the front-end and back-end shared keyword set used to mark and transmit user input. In order to solve the problem of quickly inferring the intermediate taint source in an embedded Web program that strips symbol tables and debugging information, it is necessary to accurately locate the intermediate taint source by extracting the features of each function in the program and the proportion of different strings of function parameters in the front-end and back-end shared keyword set based on the features, and use the obtained intermediate taint source as the starting point of taint analysis. Then, by using static backtracking analysis to filter out safe and dangerous function call points, it is possible to accurately identify risky dangerous function call points, reduce the taint propagation paths to be analyzed, streamline the target end point of taint analysis, and further shorten the vulnerability mining time. The present invention realizes efficient firmware vulnerability analysis by quickly and accurately determining the intermediate taint source as the starting point of taint analysis and the risky dangerous function call point as the target end point of taint analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] 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 embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0033] Figure 1 This is a flowchart of the implementation of the method for firmware vulnerability mining provided by an embodiment of the present invention;

[0034] Figure 2 This is a process block diagram of a method for discovering firmware vulnerabilities provided by an embodiment of the present invention;

[0035] Figure 3 is a schematic diagram of the characteristics of a function provided by an embodiment of the present invention;

[0036] Figure 4 1 is a schematic diagram of the structure of a device for detecting firmware vulnerabilities provided by an embodiment of the present invention;

[0037] Figure 5 is a schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0038] In the following description, specific details such as particular system structures and techniques are provided for purposes of illustration, not limitation, to facilitate a thorough understanding of the embodiments of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

[0039] In order to make the purpose, technical solutions and advantages of the present invention more clear, specific embodiments will be described below with reference to the accompanying drawings.

[0040] At present, in order to make the embedded firmware vulnerability mining technology more applicable, a vulnerability discovery method based on static taint analysis is proposed, which can be directly applied statically to the firmware program to achieve high code coverage without the need for simulation or using real embedded devices for analysis.

[0041] The classic firmware taint analysis workflow consists of three main steps: First, identify interface functions that receive user data (such as recv, getenv, and fgets) as taint sources. Second, identify unsafe library functions (such as system, sprintf, and strcpy) that could lead to buffer overflows or command hijacking as taint sinks. Third, analyze the data flow from taint sources to sinks and determine the presence of vulnerabilities by checking whether tainted data reaches any sink without being sanitized in the data flow.

[0042] It is extremely difficult to analyze the complete data flow path from the taint source (such as the interface library function recv) to the convergence point in a large amount of closed-source firmware. Certain custom functions in embedded Web programs can be used as intermediate taint sources. Compared with interface library functions, using custom functions as intermediate taint sources can greatly shorten the analyzed data flow path and streamline the starting point of taint analysis. However, the inventors found that within the firmware's embedded Web program, problems such as data aliases, indirect calls through function pointers or jump tables, and stripping of debugging information increase the complexity of data flow analysis, making it difficult to quickly and accurately determine the intermediate taint source, resulting in the inability to quickly discover vulnerabilities.

[0043] Currently, the advanced intermediate taint source identification tool FITS uses behavioral features (including six structural features and five flow features) to represent each function. This feature representation can capture the static and dynamic properties of the function and rank custom functions as intermediate taint sources through behavioral clustering and similarity scoring.

[0044] However, after extensive research, the inventors discovered that FITS constructs a large number of behavioral signatures for each function in a program and relies on the embedded web program itself and standard libraries, resulting in a long time spent inferring intermediate taint sources. While FITS's precise use of intermediate taint sources as the starting point for taint analysis reduces the analysis path and time required, the excessive time required to determine the intermediate taint source still results in a long overall vulnerability discovery process.

[0045] In order to solve the problems of the prior art, the embodiments of the present invention provide a method, apparatus, device and storage medium for detecting a firmware vulnerability.

[0046] See also Figure 1 and Figure 2 , which shows a flowchart of the implementation method of the firmware vulnerability mining method provided by the embodiment of the present invention, which is detailed as follows:

[0047] S110: Extract a set of keywords shared by the front-end and back-end.

[0048] The front-end and back-end shared keyword set includes multiple front-end and back-end shared keywords.

[0049] In some embodiments, since network communication is the main source of threats to IoT devices, it is necessary to select an embedded web program as an analysis target from the binary files obtained from the decompressed firmware.

[0050] First, we decompress the firmware using binwalk to obtain the frontend and backend binaries. Then, we extract the shared keywords between the frontend and backend used to mark the passing of user input.

[0051] Currently, there are many methods for extracting front-end and back-end shared keywords, all of which can be applied in the present invention and will not be described in detail here.

[0052] S120: Extract the features of each function in the program, locate the intermediate taint source based on the proportion of different function parameter strings in the front-end and back-end shared keyword sets in the features of each function, and use the located intermediate taint source as the starting point for taint analysis.

[0053] As previously mentioned, the currently used static taint analysis method, FITS, requires a large number of features when constructing behavioral signatures for each function in a program. Six structural features and five flow features are required to represent each function. Furthermore, it relies on the embedded web program itself and standard libraries, resulting in a long time to infer intermediate taint sources. Therefore, an optimized design is needed to quickly and accurately locate intermediate taint sources.

[0054] To facilitate understanding, the following code is presented by decompiling the httpd program in the Tenda AC15 router firmware to obtain a buffer overflow vulnerability example:

[0055] 1.src=(char*)sub_2BABC(a1,"ssid",&unk_E35DC);

[0056] 2.if(*src){

[0057] 3.strcpy(s,src);

[0058] 4.strcpy(dest,src); 5.......

[0060] Function sub_2BABC extracts the parameter value corresponding to parameter name ssid from the received user request a1, stores it in variable src, and uses it with strcpy.

[0061] Through ongoing research, the inventors discovered that if the length of the variable src is not checked and exceeds the variable buffer size, a buffer overflow vulnerability can occur. Because embedded devices have limited processing power and memory, developers often prioritize functionality and cost over security checks during development, making embedded devices extremely vulnerable to vulnerabilities.

[0062] For easier understanding, some examples of intermediate taint source calls are also provided:

[0063] 1.v2=(char*)sub_2BABC(a1,"deviceId",&unk_EFC98);

[0064] 2.v6=(char*)sub_2BABC(a1,"password",&unk_DC470);

[0065] 3.v7=(char*)sub_2BABC(a1,"username",&unk_DC470);

[0066] 4.v9=(char*)sub_2BABC(a1,"speed_dir","0");

[0067] 5.s2=(char*)sub_2BABC(a1,"mac",&unk_EDB68);

[0068] Furthermore, through multiple invocation examples of intermediate taint sources, the inventors discovered that these sources exhibit two notable characteristics: First, they extract partial content from user requests and transmit the results via return values, pointers, global variables, and other methods. Second, they use different shared strings between the frontend and backend for information transmission as parameters. Based on these characteristics, the present invention proposes a feature representation for functions that includes five features.

[0069] In some embodiments, as Figure 3 As shown, the characteristics of a function include the function name, the number of times the function is called in the embedded Web program, the number of different parameter strings in all calls of the function in the embedded Web program, the proportion of different parameter strings of the function in the keyword set shared by the front-end and back-end, and a list of all parameter strings of the function.

[0070] In this embodiment, definition reachability analysis and call site analysis can be performed based on the control flow graph and call graph generated by under-constrained symbolic execution to extract features of each function in the program.

[0071] In some embodiments, since network communication data is structured, user requests are usually stored in memory in the form of a combination of "keywords" and "user input". When certain user inputs need to be processed, keywords such as name and password are used as indexes to obtain the corresponding part of the user input. Therefore, it is reasonable to use the case where the function parameter is a string as a feature.

[0072] In order to solve the challenges brought by diversified addressing modes and variable type loss to determining whether function parameters are strings, the present invention recursively collects the program call points of all functions and the registers that store parameters, then traces the registers backwards, and ends the trace when the register can be represented by a constant. Next, the section where the constant is located is analyzed to obtain the specific content of the parameter string. If the address stored in the register points to a read-only section in the program (i.e., .rodata), the content of the parameter string is directly obtained. In some cases, the strings are dynamically generated during program execution, so they are stored in the data section (i.e., .data). The reference method of these strings is similar to the global offset table, which provides an intermediate table to store pointers to these strings, so the content pointed to by the data section address is retrieved to obtain the content of the parameter string.

[0073] In some embodiments, in order to quickly identify the intermediate taint source, it is necessary to filter the functions to determine the function that is most likely to be the intermediate taint source. The specific filtering process is as follows:

[0074] S1210. Based on the characteristics of each function, filter the functions whose names are standard library function names.

[0075] Since the intermediate taint source is a custom function rather than a standard library function, based on the extracted features of each function, some standard library functions can be filtered out based on the function name.

[0076] S1220 : Based on the characteristics of each function, filter out the functions whose number of calls in the embedded Web program is equal to 0.

[0077] Since the intermediate taint source needs to be called repeatedly in the program to extract and return part of the user input, the number of times it is called in the program must be greater than 0.

[0078] S1230 . Based on the characteristics of each function, filter the functions whose number of different parameter character strings in all call locations in the embedded Web program is equal to 0 to obtain candidate custom functions.

[0079] Because the intermediate taint source uses different front-end and back-end shared strings as parameters for transmitting information, the number of different parameter strings must be greater than 0. By filtering based on the above three conditions, many functions can be filtered out, leaving only candidate custom functions.

[0080] S1240: Based on the ratio of different parameter strings of each function in the candidate custom functions in the shared keyword set between the front-end and back-end, determine the first few functions with the highest ratio as potential intermediate taint sources, and determine an intermediate taint source from the potential intermediate taint sources.

[0081] Based on a list of all function parameter strings in the function signature and a set of shared keywords between the frontend and backend, the proportion of different function parameter strings in the shared keyword set can be determined. By sorting these proportions in descending order, several functions with higher proportions are identified as potential intermediate taint sources. Combined with manual analysis, one of these potential intermediate taint sources is identified, thereby locating the intermediate taint source. Using this intermediate taint source as the starting point for taint analysis, this allows for rapid locating of the intermediate taint source.

[0082] For ease of understanding, the present invention compares the currently used FITS static method with the method for determining the intermediate stain source in the present invention.

[0083] The FITS static method constructs 11 features for each function in the program, then uses these 11 features to score each function, identifies the top three functions with the highest scores as potential intermediate taint sources, and then combines manual analysis to determine an intermediate taint source.

[0084] However, the present invention constructs five features of the function, namely the function name, the number of times the function is called in the embedded Web program, the number of different parameter strings in all calls to the function in the embedded Web program, the proportion of the different parameter strings of the function in the front-end and back-end shared keyword set, and a list of all parameter strings of the function. When determining the intermediate taint source, the function name, the number of times the function is called in the embedded Web program, and the number of different parameter strings in all calls to the function in the embedded Web program can be used to eliminate some functions that are unlikely to be intermediate taint sources. For the remaining candidate custom functions, it is only necessary to use the list of all parameter strings of the function and the front-end and back-end shared keyword set to determine the proportion of the different parameter strings of the function in the front-end and back-end shared keyword set in the function characteristics. The larger the proportion, the more likely it is an intermediate taint source, thereby achieving rapid positioning of the intermediate taint source compared to the FITS static method. In terms of intermediate taint source inference, the present invention significantly reduces the time used for inference compared to FITS without reducing the inference accuracy.

[0085] In addition, the algorithm for quickly identifying intermediate taint sources is as follows:

[0086] Input: embedded web program binProg, front-end and back-end shared keyword set KwsFrontend, function characteristics funcChars: function name name, function call count callCnt, number of different function parameter strings uniqParamCnt, ratio of function parameter strings in the front-end and back-end shared keyword set KwdRatio, and list of different function parameter strings uniqParamList

[0087] Output: The three functions PotentSources[3] that are most likely to be intermediate taint sources

[0088] 1.funcList←extract_functions_from(binProg)

[0089] 2.PotentSources←[]

[0090] 3.for each func in funcList do

[0091] 4.if isStandardLibraryFunction(func.name)then

[0092] 5. func.KwdRatio←0

[0093] 6. continue

[0094] 7.end if

[0095] 8.if func.callCnt == 0 then

[0096] 9. func.KwdRatio←0

[0097] 10. continue

[0098] 11.end if

[0099] 12.if func.uniqParamCnt==0then

[0100] 13. func.KwdRatio←0

[0101] 14. continue

[0102] 15.end if

[0103] 16.KwCnt←0

[0104] 17.for each paramStr in func.uniqParamList do

[0105] 18. if paramStr in KwsFrontend then

[0106] 19. KwCnt←KwCnt+1

[0107] 20. end if

[0108] 21.end for

[0109] 22.func.KwdRatio←KwCnt / len(KwsFrontend)

[0110] / *Calculate the proportion of function parameter strings in the front-end and back-end shared keyword set* /

[0111] 23.end for

[0112] 24.Sort funcList by func.KwdRatio in descending order

[0113] 25.PotentSources←funcList[:3]

[0114] 26.return PotentSources / *output the three functions that are most likely to be intermediate taint sources* /

[0115] S130 , based on static backtracing analysis of function parameter types, filtering safe dangerous function call points, determining risky dangerous function call points, and using the risky dangerous function call points as endpoints for taint analysis.

[0116] Currently, when determining taint sinks, most methods identify them through the symbolic names of C standard library functions (such as system, strcpy, etc.). However, this cannot ensure that the data flow input by the user reaches the taint sink, so they spend too much time analyzing safe taint sinks that will not cause vulnerabilities.

[0117] In order to further shorten the vulnerability mining time, eliminate unnecessary mining paths, and reduce the workload of taint analysis, the present invention further filters the endpoints of taint analysis. The specific filtering method includes:

[0118] S1310 : Analyze the types of function parameters of dangerous function call points based on static backtracing, and determine the preset dangerous function call points as safe dangerous function call points.

[0119] Among them, the preset dangerous function call points include multiple safe command hijacking type dangerous function call points and multiple safe buffer overflow type dangerous function call points.

[0120] In some embodiments, multiple safe command hijacking-type dangerous function call points include: passing a constant string as a parameter; passing a variable as a parameter, but the variable is assigned a constant string before the call; passing a variable as a parameter, and the variable is a constant string result returned by the previously executed function. These are the three safe command hijacking-type dangerous function call points.

[0121] For command hijacking dangerous function call points, directly determine whether the attribute of the passed parameter is a string. If it is a constant string, it is determined to be a safe command hijacking dangerous function call point. If the passed parameter is a variable, then based on static backtracking analysis, determine whether the variable is assigned to a constant string before the call. If the variable is assigned to a constant string before the call, it is determined to be a safe command hijacking dangerous function call point. If the passed parameter is a variable, you can also use the open source tool Ghidra to first determine whether the parameter source of the command hijacking dangerous function is the return result of the previous function. Then obtain the decompiled code result of the previous sentence of the dangerous function call point, and find out whether there is a function in the decompiled code result that is used to splice or copy the commands executed by the command hijacking dangerous function (i.e. strcpy, memcpy, strlcpy, sprintf, sscanf, strncpy, snprintf). Further investigation of the functions used to splice or copy the commands executed by command hijacking dangerous functions shows that this type of function copies data from the memory space of the source address to the memory space of the target address. Therefore, the data in the memory space of the target address has the same properties as the data in the memory space of the source address. Therefore, it is only necessary to check the parameter source of the previous function to know the properties of its return result. If the parameter source of the previous function is all constants, then its return result is a constant, and the parameter source of the command hijacking dangerous function is a constant, so this is a safe command hijacking dangerous function call point; if there are variables in the parameter source of the previous function, resulting in its return result not being a fixed string, the parameter source of the command hijacking dangerous function is not a fixed string, so this is a risky command hijacking dangerous function call point.

[0122] To facilitate understanding, here is a decompiled code snippet of the httpd program from Netgear's R6400 router:

[0123] 1.int sub_84ECC(int a1){

[0124] 2.……

[0125] 3.system(" / usr / bin / killall-9bftpd 2> / dev / null");

[0126] 4.v6="bftpd-Dc / tmp / bftpd.conf&";

[0127] 5.system(v6);

[0128] 6.}

[0129] 7.int sub_9A980(){

[0130] 8.sprintf(&v1,"bzip2-d%s"," / tmp / langtbl.bz2");

[0131] 9.system((const char*)&v1);

[0132] 10.……

[0133] 11.}

[0134] From the above, sub_84ECC shows two dangerous command hijacking function call points. The first, system, takes a fixed string as its argument. The second, system, takes a variable v6 as its argument. However, backtracing back variable v6 reveals that its value is a constant string. In sub_9A980, variable v1 is passed to the system function. However, backtracing back variable v1 reveals that its value is obtained by calling the sprintf function. The source arguments passed to sprintf are the constant strings bzip2-d %s and / tmp / langtbl.bz2. Therefore, the value ultimately stored in variable v1 is the constant string bzip2-d / tmp / langtbl.bz2. Therefore, the three dangerous command hijacking function call points involved in sub_84ECC and sub_9A980 are safe.

[0135] Multiple safe buffer overflow dangerous function call sites include: passing a parameter as a constant string, and passing a parameter as a variable, but the variable is assigned to a constant string before the call. These are two types of safe buffer overflow dangerous function call sites.

[0136] Static backtracking analysis is used to identify safe buffer overflow-related dangerous function call sites. Specifically, the following two scenarios are considered safe parameter passing: the parameter passed is a constant string; the parameter passed is a variable, but the variable is assigned a constant string before the call. Based on the triggering characteristics of buffer overflow vulnerabilities, four buffer overflow-related functions (i.e., strcpy, sprintf, sscanf, and strcat) are considered for backtracking analysis to determine the function parameter types.

[0137] To facilitate understanding, here is a decompiled code snippet of the httpd program from Netgear's R6400 router:

[0138] 1.char sub_10DC4(char*a1,int a2,int*a3,int a4){

[0139] 2.……

[0140] 3.if(stristr(v20,"www.routerlogin.net")){

[0141] 4.v22="www.routerlogin.net";

[0142] 5.}

[0143] 6.else{

[0144] 7.v22="routerlogin.com";

[0145] 8.}

[0146] 9.strcpy(byte_F56A8,v22);

[0147] 10.strcpy((char*)&v303,"Chinese");

[0148] 11.……

[0149] 12.}

[0150] In the sub_10DC4 function, there are two buffer overflow-like dangerous function call points. The variable v22 is passed to the first buffer overflow-like dangerous function strcpy. However, by backtracking the variable v22, it is found that it can only be one of two constant strings, so this buffer overflow-like dangerous function call point is safe. The source parameter of the second buffer overflow-like dangerous function call point in the sub_10DC4 function is a constant string, so it is also a safe dangerous function call point.

[0151] S1320: Filter out safe dangerous function call points, and the remaining dangerous function call points are risky.

[0152] From the analysis of the above three types of safe command hijacking dangerous function call points and the two types of safe buffer overflow dangerous function call points, it can be seen that it will waste a lot of time to regard it as a risky dangerous function call point only by the function name and apply symbolic execution-based taint analysis.

[0153] By fully filtering out safe and dangerous function call points, the present invention can accurately identify risky function call points by filtering out the three safe types of command hijacking dangerous function call points and the two safe types of buffer overflow dangerous function call points. By eliminating unnecessary mining paths, the workload of taint analysis can be reduced and the mining speed can be accelerated.

[0154] By reducing the time spent locating intermediate taint sources and reducing the number of taint propagation paths from intermediate taint sources to dangerous function call points, the analysis time required to apply taint analysis to taint propagation paths can be reduced, thereby achieving the goal of shortening vulnerability discovery time.

[0155] S140: Perform vulnerability mining based on the starting point and the end point of the taint analysis.

[0156] Through taint analysis, we check whether there is a path from the intermediate taint source to the risky dangerous function call point to achieve vulnerability detection.

[0157] The taint analysis of the present invention relies on symbolic execution and adopts input-sensitive taint analysis, which includes coarse-grained taint analysis, an efficient path exploration strategy of sensitive path guidance and call path merging, and a path priority strategy.

[0158] When quickly and accurately identifying intermediate taint sources as the starting point for taint analysis, the present invention ranks functions as intermediate taint sources based on the proportion of their parameter strings in a set of shared keywords used by the frontend and backend for information transmission. When filtering safe and dangerous function call points, the method statically backtracks and analyzes the parameter types of function parameters, eliminating safe command hijacking-related dangerous function call points and safe buffer overflow-related dangerous function call points, which are complex cases where the parameter sources are constants. This ensures that taint analysis is applied to valid taint propagation paths, ultimately reducing the time required to locate intermediate taint sources, the number of taint propagation paths from intermediate taint sources to dangerous function call points, and the analysis time required to apply taint analysis to taint propagation paths, thereby shortening vulnerability discovery time.

[0159] The method for firmware vulnerability mining provided by the present invention, since network communication is the main source of threat to IoT devices, therefore, it is necessary to first extract the front-end and back-end shared keyword set used to mark the transmission of user input. In order to solve the problem of quickly inferring the intermediate taint source in the embedded Web program that strips the symbol table and debugging information, it is necessary to accurately locate the intermediate taint source by extracting the characteristics of each function in the program, and based on the proportion of different character strings of the function parameters in the characteristics in the front-end and back-end shared keyword set, and use the obtained intermediate taint source as the starting point of the taint analysis. Then, by utilizing static backtracing analysis to fully filter out safe dangerous function call points, it is possible to accurately identify risky dangerous function call points, reduce the taint propagation path to be analyzed, streamline the target end point of the taint analysis, and further shorten the vulnerability mining time.

[0160] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0161] Based on the firmware vulnerability mining method provided in the above embodiment, the present invention also provides a specific implementation of a firmware vulnerability mining device applied to the firmware vulnerability mining method. Please refer to the following embodiment.

[0162] like Figure 4 As shown, a device 400 for firmware vulnerability mining is provided, the device comprising:

[0163] An extraction module 410 is configured to extract a front-end and back-end shared keyword set, wherein the front-end and back-end shared keyword set includes a plurality of front-end and back-end shared keywords;

[0164] The starting point location module 420 is used to extract the characteristics of each function in the program, locate the intermediate taint source based on the proportion of different function parameter strings in the front-end and back-end shared keyword set in each function's characteristics, and use the located intermediate taint source as the starting point of the taint analysis;

[0165] End point location module 430, configured to analyze the types of function parameters of dangerous function call points based on static backtracing, filter out safe dangerous function call points, determine risky dangerous function call points, and use the risky dangerous function call points as the end points of taint analysis;

[0166] The taint analysis module 440 is used to perform vulnerability mining based on the starting point and the end point of the taint analysis.

[0167] In one possible implementation, the characteristics of a function include the function name, the number of times the function is called in the embedded Web program, the number of different parameter strings in all calls to the function in the embedded Web program, the proportion of the different parameter strings of the function in the keyword set shared by the front-end and back-end, and a list of all parameter strings of the function.

[0168] In a possible implementation, the starting point location module 420 is configured to perform definition reachability analysis and call point analysis based on the control flow graph and call graph generated by underconstrained symbolic execution to extract features of each function in the program.

[0169] In one possible implementation, the starting point location module 420 is configured to filter out, based on the characteristics of each function, functions whose names are standard library function names, and / or functions whose number of calls in the embedded Web program is equal to 0, and / or functions whose number of parameter different character strings in all call locations in the embedded Web program is equal to 0 from all functions, to obtain candidate custom functions;

[0170] Based on the ratio of different parameter strings of each function in the candidate custom functions in the shared keyword set between the front-end and back-end, the first few functions with the highest ratio are identified as potential intermediate taint sources, and an intermediate taint source is determined from the potential intermediate taint sources.

[0171] In one possible implementation, the endpoint location module 430 is configured to determine a preset dangerous function call point as a safe dangerous function call point based on static backtracing analysis of the types of function parameters of the dangerous function call point; wherein the preset dangerous function call points include a plurality of safe command hijacking dangerous function call points and a plurality of safe buffer overflow dangerous function call points;

[0172] Safe dangerous function call points are filtered out, and the remaining ones are risky dangerous function call points.

[0173] In one possible implementation, multiple safe command hijacking dangerous function call points include: passing a parameter as a constant string; passing a parameter as a variable, but the variable is assigned to a constant string before the call; passing a parameter as a variable, and the variable is a constant string result returned by the previous executed function;

[0174] Multiple safe buffer overflow dangerous function call sites include: passing a parameter as a constant string, and passing a parameter as a variable, but the variable is assigned to a constant string before the call.

[0175] In a possible implementation, the taint analysis module 440 is configured to perform symbolic execution-based taint analysis based on a starting point and an end point of the taint analysis.

[0176] Figure 5 Schematic diagram of an electronic device provided by an embodiment of the present invention. Figure 5 As shown, the electronic device 5 of this embodiment includes: a processor 50, a memory 51, and a computer program 52 stored in the memory 51 and executable on the processor 50. When the processor 50 executes the computer program 52, the steps in the above-mentioned firmware vulnerability mining method embodiments are implemented, such as Figure 1 Alternatively, when the processor 50 executes the computer program 52, the functions of the modules in the above-mentioned device embodiments are realized, for example, Figure 4 Functions of modules 410 to 440 are shown.

[0177] Exemplarily, the computer program 52 may be divided into one or more modules, which are stored in the memory 51 and executed by the processor 50 to implement the present invention. The one or more modules may be a series of computer program instruction segments capable of implementing specific functions, which are used to describe the execution process of the computer program 52 in the electronic device 5. For example, the computer program 52 may be divided into Figure 4 Modules 410 to 440 are shown.

[0178] The electronic device 5 may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will understand that Figure 5 It is only an example of the electronic device 5 and does not constitute a limitation of the electronic device 5. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0179] The processor 50 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0180] The memory 51 can be an internal storage unit of the electronic device 5, such as a hard disk or memory of the electronic device 5. The memory 51 can also be an external storage device of the electronic device 5, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 5. Furthermore, the memory 51 can also include both an internal storage unit of the electronic device 5 and an external storage device. The memory 51 is used to store the computer program and other programs and data required by the electronic device. The memory 51 can also be used to temporarily store data that has been output or is about to be output.

[0181] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0182] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0183] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0184] In the embodiments provided by the present invention, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0185] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0186] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0187] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, it can implement the steps of the above-mentioned various firmware vulnerability mining method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device that can carry the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc.

[0188] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A method for discovering firmware vulnerabilities, characterized in that: include: Extracting a front-end and back-end shared keyword set, wherein the front-end and back-end shared keyword set includes a plurality of front-end and back-end shared keywords; Extract the features of each function in the program, locate the intermediate taint source based on the proportion of different function parameter strings in the front-end and back-end shared keyword set in each function's features, and use the located intermediate taint source as the starting point for taint analysis; wherein the function features include the function name, the number of times the function is called in the embedded Web program, the number of different parameter strings in all call locations of the function in the embedded Web program, the proportion of different function parameter strings in the front-end and back-end shared keyword set, and a list of all parameter strings of the function; Analyze the types of function parameters of dangerous function call points based on static backtracing, filter safe dangerous function call points, determine risky dangerous function call points, and use the risky dangerous function call points as the end point of taint analysis; Perform vulnerability mining based on the starting point and the end point of the taint analysis; The extraction of features of each function in the program and the location of the intermediate taint source based on the proportion of different strings of function parameters in the front-end and back-end shared keyword sets in the features of each function include: Based on the characteristics of each function, functions whose names are standard library function names, and / or functions whose number of calls in the embedded Web program is equal to 0, and / or functions whose number of parameter different character strings in all call locations in the embedded Web program is equal to 0 are filtered out from all functions to obtain candidate custom functions; Based on the ratio of different parameter strings of each function in the candidate custom functions in the shared keyword set between the front-end and back-end, the first several functions with the highest ratio are determined as potential intermediate taint sources, and an intermediate taint source is determined from the potential intermediate taint sources.

2. The method for firmware vulnerability mining according to claim 1, wherein: The feature of each function in the extraction program includes: Definition reachability analysis and call site analysis are performed based on the control flow graph and call graph generated by underconstrained symbolic execution to extract the characteristics of each function in the program.

3. The method for firmware vulnerability mining according to claim 1, wherein: The method of analyzing the types of function parameters of dangerous function call points based on static backtracing, filtering safe dangerous function call points, and determining risky dangerous function call points includes: Based on static backtracing analysis of the types of function parameters of dangerous function call points, the preset dangerous function call points are determined as safe dangerous function call points; wherein the preset dangerous function call points include a plurality of safe command hijacking dangerous function call points and a plurality of safe buffer overflow dangerous function call points; The safe dangerous function call points are filtered out, and the remaining dangerous function call points are risky.

4. The method for firmware vulnerability mining according to claim 3, wherein: The multiple safe command hijacking dangerous function call points include: passing a parameter as a constant string; passing a parameter as a variable, but the variable is assigned to a constant string before the call; passing a parameter as a variable, and the variable is a constant string result returned by the previous execution function; The multiple safe buffer overflow type dangerous function call points include: passing a parameter as a constant string, and passing a parameter as a variable, but the variable is assigned as a constant string before the call.

5. The method for firmware vulnerability mining according to claim 1, wherein: The vulnerability mining based on the starting point and the end point of the taint analysis includes: Performing a taint analysis based on symbolic execution based on the taint analysis start point and the taint analysis end point.

6. A device for detecting firmware vulnerabilities, characterized in that: include: An extraction module, configured to extract a front-end and back-end shared keyword set, wherein the front-end and back-end shared keyword set includes a plurality of front-end and back-end shared keywords; A starting point location module is used to extract the features of each function in the program, locate the intermediate taint source based on the proportion of different function parameter strings in the front-end and back-end shared keyword set in the features of each function, and use the located intermediate taint source as the starting point of the taint analysis; wherein the function features include the function name, the number of times the function is called in the embedded Web program, the number of different parameter strings in all call locations of the function in the embedded Web program, the proportion of different function parameter strings in the front-end and back-end shared keyword set, and a list of all parameter strings of the function; An endpoint location module is used to analyze the types of function parameters of dangerous function call points based on static backtracing, filter safe dangerous function call points, determine risky dangerous function call points, and use the risky dangerous function call points as the endpoint of the taint analysis; A taint analysis module, configured to perform vulnerability mining based on the starting point and the end point of the taint analysis; Among them, the starting point positioning module is also used to filter out functions whose function names are standard library function names, and / or functions whose number of calls in the embedded Web program is equal to 0, and / or functions whose number of different parameter strings in all call locations in the embedded Web program is equal to 0 from all functions based on the characteristics of each function, to obtain candidate custom functions; based on the ratio of the different parameter strings of each function in the candidate custom functions in the shared keyword set between the front-end and back-end, the first few functions with the highest ratio are determined as potential intermediate taint sources, and an intermediate taint source is determined from the potential intermediate taint sources.

7. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the method according to any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images