A method for mining and exploiting stack overflow vulnerabilities of internet of things devices based on reverse analysis
By reverse engineering the web service program of IoT device firmware, constructing function call and variable passing chains, and locating and exploiting stack overflow vulnerabilities, this method solves the problems of insufficient efficiency and accuracy in existing detection methods, and achieves efficient vulnerability detection and exploitation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-03-07
- Publication Date
- 2026-03-20
AI Technical Summary
Existing methods for detecting vulnerabilities in IoT devices are insufficient in terms of detection efficiency and accuracy. In particular, for the detection of stack overflow vulnerabilities, static and dynamic analysis techniques suffer from high false alarm rates and low path coverage, while reverse analysis methods are complex to operate and not very practical.
Reverse engineering techniques are used to analyze the firmware of IoT devices. By tracing dangerous functions in the backend code of the web service, the relationship between function call chains and variable passing chains is constructed to locate stack overflow vulnerabilities, and malicious requests are constructed to exploit these vulnerabilities.
Effectively detects and exploits stack overflow vulnerabilities in IoT devices, reducing detection costs, increasing vulnerability detection rates, applicable to a wide range of IoT device programs, and improving security.
Smart Images
Figure CN116305152B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application belongs to the technical field of software engineering, and particularly relates to a stack overflow vulnerability mining and utilization method based on reverse analysis of Internet of Things devices. BACKGROUND
[0002] With the acceleration of 5G technology for the development of the Internet of Things, there will be 25 billion Internet of Things devices connected to people's lives by 2025. However, the Internet of Things device network has many security problems. Internet of Things devices often have web front-end vulnerabilities, backdoor vulnerabilities, password cracking vulnerabilities, and stack overflow vulnerabilities, so it has high security value to mine and research stack overflow vulnerabilities of Internet of Things devices.
[0003] There are many methods for detecting vulnerabilities of binary programs for Internet of Things devices at present, but a lot of manpower and material resources are often consumed in detection, such as automatic mining technology in a black box mode. In order to increase detection efficiency, some tools for checking code security through code specifications are often used in code detection. The new Cisco router test framework uses a semi-effective fuzzy test case generator (SFTCG) to generate test cases, which greatly improves the effectiveness of testing and code coverage, but it cannot detect logical code vulnerabilities in detail. At present, the static analysis technology based on static analysis technology is very common in the field of Internet of Things vulnerability detection. This technology does not need to actually run the program, but uses simulated program execution flow to traverse the code area. However, because the path coverage rate is high, it takes a long time to access and analyze instructions and restore memory layout, which is easy to produce a lot of false positives, and this technology cannot obtain the context information of program running, so its detection accuracy needs to be improved.
[0004] Another dynamic detection vulnerability technology analyzes the state characteristics and related information exhibited by the program during execution to discover defects in the program, but it cannot cover all paths during program execution, has a high false negative rate, and program execution also generates a large system overhead. Moreover, whether it is static analysis or dynamic analysis technology, even if a large number of possible real vulnerabilities are scanned, security analysts still need to complete vulnerability confirmation and the "last mile" problem of vulnerability triggering position.
[0005] Vulnerability mining based on reverse analysis actually belongs to the gray box testing method, which uses reverse analysis technology to assist vulnerability mining, can directly measure the problem domain and test as many vulnerabilities as possible, can reduce the cost of manpower consumed in detection, and has a high detection rate for logical vulnerabilities. However, the current reverse analysis method for Internet of Things devices generally has the disadvantages of not being easy to operate and not being strong in practicality. SUMMARY
[0006] In view of the problems in the prior art, the present application provides a method for mining and exploiting stack overflow vulnerabilities of Internet of Things devices based on reverse analysis, which analyzes the firmware of the Internet of Things devices based on code reverse analysis technology, can effectively detect possible stack overflow vulnerabilities of the Internet of Things devices, mainly the stack overflow vulnerabilities that may occur when dangerous functions in the Web service program of the Internet of Things devices do not perform length checking when using the string input by the user on the Web page, and exploits the vulnerabilities, so that attacks on the Internet of Things devices can be realized.
[0007] The technical scheme of the present application is:
[0008] A method for mining stack overflow vulnerabilities of Internet of Things devices based on reverse analysis, comprising the following steps:
[0009] Step 1: Obtain the firmware of the Internet of Things device and the Web service backend code and structure;
[0010] Step 2: Track the dangerous functions in the Web service backend code, perform reverse analysis on the code in units of relationship chains, capture vulnerability points, and record vulnerability-related information.
[0011] Further, step 1 comprises the following steps:
[0012] Step 1.1: Extract the file system of the firmware of the Internet of Things device, and find the binary file that provides Web service in the extracted file system;
[0013] Step 1.2: Preload the found binary file using the IDA reverse tool, thereby obtaining the Web service backend assembly code of the Internet of Things device and the C language code generated using the IDA disassembly function, and obtaining a logically complete code structure; the code structure includes the calling relationship between functions and the string reference relationship.
[0014] Further, in step 1.1, the file system of the firmware of the Internet of Things device is extracted using the Binwalk tool.
[0015] Further, step 2 comprises the following steps:
[0016] Step 2.1: Find dangerous functions in the obtained Web service backend code, and track the dangerous function calling relationship and obtain the variable passing relationship according to the obtained code structure;
[0017] Step 2.2: According to the function calling relationship and the variable passing relationship, determine the relationship chain, and perform subsequent vulnerability positioning and analysis in units of relationship chains; the relationship chain is composed of a function calling chain and a variable passing chain, and can clearly and completely exhibit the vulnerability triggering logic;
[0018] Step 2.3: For each relationship chain, determine whether the relationship chain has a vulnerability point according to the following rules:
[0019] The relationship chain that meets all of the following conditions is the relationship chain where the vulnerability point is located: ① the end node variable is initialized to a string input by the user on the front-end Web page; ② no string length check is performed during variable transmission; and ③ no string length check is performed from obtaining the string input by the user on the front-end Web page to assigning the end node variable described in rule ①.
[0020] Step 2.4: After locating the vulnerability point, determine the front-end and back-end association before the vulnerability point and the vulnerability triggering logic.
[0021] Further, in step 2, the variable is a string type variable.
[0022] Further, in step 2, the basic characteristics of the relationship chain are:
[0023] (1) The function call chain of the relationship chain starts with a dangerous function;
[0024] (2) The variable transmission chain of the relationship chain starts with a variable that meets the following conditions: ① it is a parameter of the dangerous function at the start of the function call chain; and ② the value is written into another variable by the dangerous function;
[0025] (3) Each function in the function call chain is referred to as a node function, and a function that calls the node function at the end of the current function call chain is added to the end of the function call chain;
[0026] (4) Each variable in the variable transmission chain is referred to as a node variable, and if a variable forms a node variable at the end of the current variable transmission chain through function call parameter transmission or assignment transmission, the variable is added to the end of the variable transmission chain;
[0027] (5) An attribute is added for each node variable, and the attribute is the function where the variable is located;
[0028] (6) The function call chain and the variable transmission chain of the relationship chain are both single chains, and if a branch occurs in function call or parameter transmission, it is considered as a different relationship chain;
[0029] (7) The relationship chain ends when any of the following conditions is met: ① a vulnerability point occurs; or ② when a node variable is initialized to a specific string, a vulnerability point still does not occur.
[0030] Further, in step 2, the vulnerability-related information includes the dangerous function, the relationship chain, and the analysis result of whether a vulnerability point occurs. If a vulnerability point occurs, it also includes the vulnerability point API interface string and other API interface strings.
[0031] After determining the vulnerability through the above method, a vulnerability exploitation method is proposed: after determining the vulnerability, a malicious request is constructed by accessing the web page of the Internet of Things device, an attack is made to the Internet of Things device, and the stack overflow vulnerability is triggered.
[0032] Further, the method specifically comprises the following steps:
[0033] Step a: after determining the vulnerability, analyze the functions of each function in the relationship chain, correspond the functions of the backend functions to the positions of the front-end business modules, and obtain the web page corresponding to the business module triggering the vulnerability;
[0034] Step b: enter the web page of the Internet of Things device with the vulnerability and jump to the web page corresponding to the vulnerability point;
[0035] Step c: perform legal user input on the content to be filled in the web page corresponding to the vulnerability point, and perform packet capture when saving the user input to obtain a POST request packet;
[0036] Step d: modify the obtained POST data request packet, maliciously construct a string, and send the modified POST data request packet.
[0037] Beneficial effects
[0038] The present application proposes a method for mining and exploiting stack overflow vulnerabilities of Internet of Things devices based on reverse analysis, which is targeted at stack overflow vulnerabilities caused by dangerous functions in Web service programs, can effectively reduce the detection range of vulnerabilities, reduce the cost of human resources consumed in detection, and improve the detection rate of vulnerabilities. Moreover, dangerous functions exist widely in Internet of Things device programs, so the present method has a wide range of applications. The combination of vulnerability mining and exploitation is described by examples, which proves that the present application has the characteristics of strong operability and high feasibility compared with existing reverse analysis vulnerability detection methods. Moreover, the method is a theoretical method and is not limited by the degree of automation of detection devices, which can effectively detect stack overflow vulnerabilities in Internet of Things devices, thereby helping to improve the security of Internet of Things devices.
[0039] Additional aspects and advantages of the application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS
[0040] The above and / or additional aspects and advantages of the present application will become apparent and be readily appreciated from the following description, including the appended drawings.
[0041] Figure 1 The figure is a flowchart of the implementation process of the present application.
[0042] Figure 2The relationship chain form diagram proposed in the present application.
[0043] Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 are example diagrams used to more fully describe the specific embodiments, wherein:
[0044] Figure 3 is a front and back API interface comparison diagram.
[0045] Figure 4 is a Tenda AC18 router httpd file sscanf function part reference table in IDA.
[0046] Figure 5 is a Tenda AC18 router httpd file sub_781E8 function part code in IDA.
[0047] Figure 6 is a Tenda AC18 router httpd file fromSetRouteStatic function part code in IDA.
[0048] Figure 7 is a front and back comparison diagram for constructing malicious POST. DETAILED DESCRIPTION
[0049] The vulnerability that the dangerous function in the Internet of Things device Web service program can cause is usually a stack overflow vulnerability that can be caused by the program not performing length checking on the string when the user inputs the string on the Web page, and the present application proposes a vulnerability mining and utilization method for this type of stack overflow vulnerability, which comprises: obtaining the Internet of Things device Web service backend code and code structure; performing reverse analysis on the dangerous function; analyzing the relationship chain composed of the function call chain and the variable transmission chain as a basic unit, thereby locating the vulnerability point and determining the stack overflow vulnerability; and constructing malicious POST to exploit the vulnerability.
[0050] The embodiments of the present application are described in detail below, which are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.
[0051] The present application is described in detail below through an Internet of Things device stack overflow vulnerability mining example:
[0052] Table 1: Internet of Things device and required tools
[0053] IoT device name Tenda AC18 router Firmware version V15.03.05.19_multi Filesystem extraction tool Binwalk v2.1.1 Web service backend binary httpd Reverse analysis tool IDA_Pro v7.5
[0054] Step 1: Obtain the firmware of the Internet of Things device and the code and structure of the Web service backend. The process includes the following steps:
[0055] Step 1.1: Obtain the firmware of the router. It can be downloaded from the update website provided by the router manufacturer or extracted from the Flash of the router through hardware access.
[0056] Use the Binwalk tool to extract the file system of the router firmware and find the binary files of the Web service provided by the router in the extracted file system, which are essentially ELF files.
[0057] Step 1.2: Preload the ELF file using the IDA reverse tool to obtain the router Web service backend assembly code and C language code generated using the IDA disassembly function, and obtain the logically complete code structure; the code structure includes the calling relationship between functions, the string reference relationship.
[0058] Step 2: Trace the dangerous functions in the Web service backend code, perform reverse analysis of the code in units of relationship chains, capture vulnerability points, and record vulnerability-related information. It includes the following steps:
[0059] Step 2.1: Find dangerous functions such as strcpy, sscanf, sprintf, etc. that may cause stack overflow vulnerabilities in the obtained Web service backend code, and trace the dangerous function calling relationship and obtain the variable passing relationship according to the obtained code structure.
[0060] Since the variable types that cause buffer overflow are all strings, unless otherwise specified, the variables described in the present application are string type variables. The present application analyzes, filters, locates, etc. in units of relationship chains (hereinafter referred to as relationship chains) composed of function call chains and variable passing chains.
[0061] Step 2.2: According to the function call relationship and the variable passing relationship, determine the relationship chain, and take the relationship chain as the basic unit for subsequent vulnerability positioning and analysis; the relationship chain is composed of function call chains and variable passing chains, which can clearly and completely show the vulnerability triggering logic.
[0062] The basic characteristics of the relationship chain are:
[0063] (1) The function call chain of the relationship chain starts with a dangerous function that may cause a stack overflow vulnerability, such as strcpy(str1, str2).
[0064] (2) The variable transfer chain of the relationship chain starts from the variable that meets the following conditions: ① It is the parameter of the dangerous function at the start of the function call chain; ② The value is written into another variable through the dangerous function. For example, str2 in (1) is the parameter of the strcpy function and is written into str1 through strcpy, so str2 is the start of the variable transfer chain.
[0065] (3) Each function in the function call chain is called a node function, and the function that calls the node function at the end of the current function call chain should be added to the end of the function call chain.
[0066] (4) Each variable in the variable transfer chain is called a node variable, and if a variable forms the node variable at the end of the current variable transfer chain through function call parameter transfer or assignment transfer, the variable should be added to the end of the variable transfer chain.
[0067] (5) An attribute should be added for each node variable, which is the function in which the variable is located.
[0068] (6) The function call chain and the variable transfer chain of the relationship chain are both single chains, and if the function call or parameter transfer branches, it should be considered as a different relationship chain.
[0069] (7) The relationship chain ends when any of the following conditions is met: ① A vulnerability point appears; ② When the node variable is initialized to a specific string, the vulnerability point still does not appear.
[0070] The relationship chain structure and form derived from the basic structure are as follows Figure 2 .
[0071] Step 2.3: For each key chain, determine whether a relationship chain has a vulnerability point according to the following rules:
[0072] The relationship chain that meets all the following three conditions is the relationship chain where the vulnerability point is located: ① The end node variable is initialized to a string input by the user on the front-end Web page; ② No string length check is performed during the variable transfer process; ③ No string length check is performed from obtaining the string input by the user on the front-end Web page to assigning the end node variable described in rule ①.
[0073] Step 2.4: After locating the vulnerability point, determine the front-end and back-end association and vulnerability triggering logic.
[0074] First, combine Figure 3 a simple analysis of the front-end and back-end of a certain Internet of Things device. Access the Web page of the Internet of Things device and use the Burpsuit tool to click and capture the packet of a module, which can obtain a similar Figure 3The POST request of the left, and get the module url (example, / goform / saveParentControlInfo) and the string provided by the processing of the module (example, deviceId, deviceName, etc.) from the Internet of Things device Web service backend code analysis found that the implementation of the module routing function reference "deviceId", "deviceName" and other strings, such as Figure 3 As shown in the right.
[0075] Through the above analysis can be known, the module front-end API input interface named deviceId, deviceName, etc. exist, the user by inputting data to the interface, by sending http protocol data packets to the Internet of Things device backend binary program, and by sub_2BA8C function by identifying API interface string "deviceId", "deviceName" and other methods to read user input.
[0076] One of the conditions for the above vulnerability is that the "end node variable is initialized to the string input by the user in the front-end Web page", combined with the analysis of the vulnerability point can be known that the vulnerability trigger logic is: the backend binary program reads user input by identifying API interface and other methods, and initializes the string, when the user input string length is greater than the array length, and the string is used without length check by dangerous function (such as strcpy, sscanf, sprintf), and then the stack overflow vulnerability occurs. Therefore, when the vulnerability point appears, the API interface string near the vulnerability point also needs to be recorded.
[0077] For this embodiment, first select sscanf as a dangerous function, view all functions cross reference sscanf, such as Figure 4 There are 116 records.
[0078] Then analyze these functions and related variables according to the relationship chain, now a specific description of the relationship chain construction process of a vulnerability point exists:
[0079] Analysis to the 43rd record function sub_781E8 that references the sscanf function, then the function is a starting point of a function call chain. View the function code, such as Figure 5, analysis can be known, variable transfer chain starting point should choose variable v16, and add attribute sub_781E8 to it; and v16 is assigned to the value of another variable a2 inside the function, then add a2 to the end of the variable transfer chain, and add attribute sub_781E8 to it. Again a2 is a parameter of the function sub_781E8, it is known that the variable comes from the function that calls the function, and thus the reverse analysis is performed again. Analysis to the function fromSetRouteStatic, add the function to the end of the function call chain, view the function code, such as Figure 6 , analysis can be known that sub_781E8 parameter a2 is the variable v5 of the function, add v5 to the end of the variable transfer chain, and add attribute fromSetRouteStatic to it. Further analysis can be known that sub_2BA8C is a function for obtaining user input data, and v5 is initialized to the user input string through the API interface string "list". By analyzing the sub_2BA8C function and the variable transfer process, it is found that the length of the string is not checked. At this point, the vulnerability point appears, and the relationship chain ends. The complete relationship chain is as follows (the attributes in the brackets):
[0080] Table 2: Example vulnerability relationship chain and other vulnerability related information
[0081] Dangerous function sscanf Function call chain sub_781E8 -> fromSetRouteStatic Variable passing chain v16 (sub_781E8) -> a2 (sub_781E8) -> v5 (fromSetRouteStatic) Analysis results Vulnerability occurrence Vulnerability API interface string "list" Other API interface strings None
[0082] After determining the vulnerability by the above method, the following process is used for vulnerability exploitation:
[0083] Step a: After determining the vulnerability, analyze the functions in the relationship chain, and correspond the backend function to the front-end business module position to obtain the corresponding Web page of the business module that triggers the vulnerability.
[0084] Step b: Enter the Web page of the Internet of Things device where the vulnerability appears, and jump to the Web page corresponding to the vulnerability point.
[0085] Step c: Perform legal user input on the content that needs to be filled in the Web page corresponding to the vulnerability point, and use the Burpsuit tool to capture the packet when saving the user input (i.e. the process of receiving the user input string to the Web backend program) to obtain the POST request data packet, as shown in Figure 7 (left); which contains the API interface name of the vulnerability point (example deviceList) and other API interface names that may exist under this page (example macFilterType), the corresponding string of which is the legal user input.
[0086] Step d: modify the obtained POST data request packet, maliciously construct the string, modify the string in the POST at the API interface name of the vulnerability point, add a large number of characters to the string according to the characteristics of the dangerous function, such as Figure 7 The modified POST data request packet is finally sent.
[0087] After the above steps, it can be observed that the Internet of Things device has been attacked. Thus, the exploitation of the vulnerability is completed. A POC can also be written according to the characteristics of the vulnerability to improve the completeness of the vulnerability exploitation process. In addition, if the attacker carefully constructs the string, remote code execution and other vulnerabilities can also be caused.
[0088] Although the embodiments of the present application have been shown and described above, it should be understood that the above embodiments are exemplary and should not be construed as limiting the present application, and those of ordinary skill in the art can make changes, modifications, replacements and variations to the above embodiments without departing from the principles and spirit of the present application within the scope of the present application.
Claims
1. A method for discovering stack overflow vulnerabilities in IoT devices based on reverse engineering, characterized in that: Includes the following steps: Step 1: Obtain the firmware and web service backend code and structure of the IoT device; Step 2: Trace dangerous functions in the web service backend code, perform reverse engineering on a chain-by-chain basis, identify vulnerability points, and record vulnerability-related information. This includes the following steps: Step 2.1: Locate dangerous functions in the obtained Web service backend code, trace the call relationships of dangerous functions based on the obtained code structure, and obtain variable passing relationships; the variables are string type variables; Step 2.2: Based on function call relationships and variable passing relationships, determine the relationship chain, and use the relationship chain as the basic unit for subsequent vulnerability location and analysis; the relationship chain is composed of function call chains and variable passing chains, which can clearly and completely show the vulnerability triggering logic; the basic characteristics of the relationship chain are: (1) The starting point of the function call chain in the relational chain is a dangerous function; (2) The variable passing chain of the relation chain starts with a variable that simultaneously satisfies the following conditions: ① It is the parameter of the dangerous function at the starting point of the function call chain; ② The value is written to another variable through the dangerous function; (3) Each function in the function call chain is called a node function. The function that calls the node function at the end of the current function call chain is added to the end of the function call chain. (4) Each variable in the variable passing chain is called a node variable. If a variable becomes the node variable at the end of the current variable passing chain through function call parameter passing or assignment passing, then the variable is added to the end of the variable passing chain. (5) Add an attribute to each node variable, the attribute being the function in which the variable resides; (6) The function call chain and variable passing chain of the relation chain are both single chains. If there is a branch in the function call or parameter passing, it is considered as a different relation chain. (7) The relationship chain ends when any of the following conditions are met: ① A vulnerability point appears; ②The vulnerability still hasn't appeared even when the node variable is initialized to a specific string; Step 2.3: For each relationship chain, determine whether there are any vulnerabilities by judging according to the following rules: The following three conditions must be met for a relationship chain to be considered a vulnerability: ① The last node variable is initialized to the string entered by the user on the front-end web page; ② No string length check is performed during variable passing; ③ No string length check is performed from obtaining the string entered by the user on the front-end web page to assigning it to the last node variable mentioned in rule ①. Step 2.4: After locating the vulnerability, determine the front-end and back-end connections of the vulnerability and the vulnerability triggering logic.
2. The method for discovering IoT device stack overflow vulnerabilities based on reverse analysis according to claim 1, characterized in that: Step 1 includes the following steps: Step 1.1: Extract the file system of the IoT device firmware and find the binary file that provides the web service for the IoT device in the extracted file system; Step 1.2: Use the IDA reverse engineering tool to preload the found binary file to obtain the assembly code of the IoT device web service backend and the C language code generated by the IDA disassembly function, and obtain a logically complete code structure; the code structure includes the calling relationship between functions and the string reference relationship.
3. The method for discovering IoT device stack overflow vulnerabilities based on reverse analysis according to claim 2, characterized in that: In step 1.1, the Binwalk tool is used to extract the file system of the IoT device firmware.
4. The method for discovering IoT device stack overflow vulnerabilities based on reverse analysis according to claim 1, characterized in that: In step 2, the vulnerability-related information includes dangerous functions, relationship chains, and analysis results on whether a vulnerability point has been found. If a vulnerability point has been found, it also includes the vulnerability point API interface string and other API interface strings.
5. A method for exploiting vulnerabilities discovered by any one of the mining methods described in claims 1 to 4, characterized in that: After identifying the vulnerability, a malicious request was constructed to attack the IoT device by accessing its web page, triggering a stack overflow vulnerability.
6. The method of use according to claim 5, characterized in that: Specifically, the following steps are included: Step a: After identifying the vulnerability, analyze the functions in the relationship chain, match the backend functions with the frontend business module locations, and obtain the web page corresponding to the business module that triggered the vulnerability; Step b: Access the web page of the vulnerable IoT device and redirect to the web page corresponding to the vulnerability point; Step c: Allow legitimate user input for the content required on the web page corresponding to the vulnerability, and capture network packets when saving the user input to obtain the POST request data packet; Step d: Modify the obtained POST data request packet, maliciously construct the string, and send the modified POST data request packet.