Method and system for automatic generation of embedded device PoC based on front-end and back-end keyword sharing

Abstract

The application relates to the technical field of network security, in particular to an embedded device PoC automatic generation method and system based on front-end and back-end keyword sharing, which comprises the following steps: extracting a basic block path triggered by a vulnerability from vulnerability alarm data; extracting a key item and a corresponding value from the basic block path, wherein the key item is a string appearing in the basic block path, and the corresponding value is a judgment value of basic block jumping; searching the key item in front-end file data, and acquiring a shared keyword for representing the connection between the front-end webpage service file data and the back-end file data by matching the key item with the key item of the back-end file data, wherein the front-end file provides an interface for user and device interaction, and the back-end file is used for executing device instructions; constructing webpage service program configuration data based on the shared keyword, generating webpage service request data packets by using the webpage server configuration data, and obtaining a target device response by sending the request data packets. The application extracts information from vulnerability alarm information and automatically generates a vulnerability verification code based on front-end and back-end keyword sharing according to the characteristics of the embedded device, so that the vulnerability detection efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to an automated method and system for generating Proof of Concept (PoC) for embedded devices based on front-end and back-end keyword sharing. Background Technology

[0002] As vulnerability types become increasingly complex, the limitations of vulnerability detection devices are becoming more and more prominent. Many vulnerabilities cannot be detected by existing security devices or cannot be detected in a timely and effective manner. In such cases, Proof of Code (POC) vulnerability detection technology is needed for discovery. A POC typically consists of a piece of vulnerability verification code or vulnerability detection data. After sending this code or data to the target, the existence of the vulnerability is determined by the specific information returned by the target. It is the most intuitive way to indicate the exploitability and severity of a vulnerability. The automatic generation of POCs is an indispensable part of automated vulnerability verification research. However, existing automated embedded device vulnerability detection methods often only provide simple vulnerability alerts and cannot verify the exploitability of the generated vulnerability. They rely on expert experience to manually analyze binary programs to construct vulnerability verification codes, which is relatively inefficient. Summary of the Invention

[0003] To address this, the present invention provides an automated PoC generation method and system for embedded devices based on front-end and back-end keyword sharing. Combining the characteristics of embedded devices, the method extracts information from vulnerability alerts and automatically generates vulnerability verification code based on front-end and back-end keyword sharing, thereby improving vulnerability detection efficiency.

[0004] According to the design scheme provided by this invention, on the one hand, an automated method for generating PoC for embedded devices based on front-end and back-end keyword sharing is provided, comprising:

[0005] Based on the vulnerability alert data, the basic block path that triggers the vulnerability is extracted. Key items and corresponding values ​​are extracted from the basic block path. The key items are strings that appear in the basic block path, and the corresponding values ​​are judgment values ​​for basic block jumps.

[0006] Search for key items in the front-end file data and obtain shared keywords that represent the connection between the front-end web service file data and the back-end file data by matching them with key items in the back-end file data. The front-end file provides the interface for users to interact with the device, and the back-end file is used to execute device commands.

[0007] The web service program configuration data is constructed based on shared keywords. The web server configuration data is used to generate web service request data packets, and the response from the target device is obtained by sending the request data packets.

[0008] As part of the embedded device PoC automated generation method based on front-end and back-end keyword sharing of this invention, the method further includes extracting the basic block path of vulnerability triggering from vulnerability alert data, which includes:

[0009] Perform targeted symbolic execution on abnormal information in vulnerability alert data, use a variable array to record basic blocks in the symbolic execution path, and delete basic blocks that do not belong to the exploration path branches when backtracking the exploration path. Use the basic blocks recorded by the variable array when a suspicious vulnerability point is explored as the basic blocks of the required vulnerability triggering basic block path.

[0010] As an automated PoC generation method for embedded devices based on front-end and back-end keyword sharing in this invention, the key items are further extracted from the basic block path, including:

[0011] Based on the data extraction function and using the function call rules, the basic block path is traversed. It is determined whether the function called by the call instruction type after the parameter passing instruction type is the data extraction function. If so, the parameters passed in the parameter passing instruction are used as the key items in the basic block path. The data extraction function is the function that parses the front-end web service request data packet in the back-end web service processing program.

[0012] As an automated PoC generation method for embedded devices based on front-end and back-end keyword sharing in this invention, further, extracting key item corresponding values ​​from the basic block path includes:

[0013] Based on the basic block conditional jump instructions, the function parameter information where the vulnerability trigger point is located, and the vulnerability type, the jump between different basic blocks is determined by the conditional jump instructions. The value of the key item is obtained by judging the value of the specified register before the jump. The conditional jump instructions include jump instructions with unequal values ​​and jump instructions with equal values.

[0014] As an automated PoC generation method for embedded devices based on front-end and back-end keyword sharing in this invention, further, the method obtains the corresponding value of the key item by judging the value of the specified register before the jump, including:

[0015] If a specified register corresponds to a key item when determining the value of a specified register, then the value of that specified register is used as the value corresponding to the key item.

[0016] If the specified register corresponds to multiple key items when determining the value of the specified register, then identify whether the last instruction of the basic block is a conditional jump instruction. If it is, then backtrack upwards to find the most recent conditional judgment instruction, extract the parameter of the most recent conditional judgment instruction, and if the parameter is a key item, then use the value of the parameter as the corresponding value of the key item. If the parameter depends on multiple key items, then use data flow analysis technology to backtrack the basic block to find the source of the judgment parameter in the conditional jump instruction, represent the parameter with an expression of multiple key items, and obtain the corresponding values ​​of multiple key items by constraining and solving the expression.

[0017] As an automated PoC generation method for embedded devices based on front-end and back-end keyword sharing in this invention, further comprising obtaining the corresponding value of the key item by judging the value of the specified register before the jump, and further including:

[0018] By tracing the use of registers when the vulnerable function pushes onto the stack, the parameter definitions are obtained by analyzing the function stack space layout, and the values ​​corresponding to the key items that trigger the vulnerability are determined based on the parameter definitions.

[0019] As part of the embedded device PoC automated generation method based on front-end and back-end keyword sharing of this invention, the web service program configuration data constructed based on shared keywords further includes:

[0020] A session is created using a dictionary and a request library. Web services are obtained by sending requests. Specified parameters are extracted from the header of the embedded device's response packet, and a function to log in to the embedded device is generated.

[0021] The login request function is used to obtain the web service handler, the tag attribute information in the front-end file is extracted, the configuration data is constructed by combining the key items and corresponding values, the address of the web service handler where the vulnerability point is located in the embedded device is generated, and the web service request data packet is constructed.

[0022] Furthermore, this invention also provides an automated PoC generation system for embedded devices based on front-end and back-end keyword sharing, comprising: a path extraction module, a shared matching module, and a code generation module, wherein...

[0023] The path extraction module is used to extract the basic block path that triggers the vulnerability based on the vulnerability alarm data, and to extract key items and corresponding values ​​from the basic block path. The key items are strings that appear in the basic block path, and the corresponding values ​​are judgment values ​​for basic block jumps.

[0024] The shared matching module is used to search for key items in the front-end file data and obtain shared keywords that represent the connection between the front-end web service file data and the back-end file data by matching them with key items in the back-end file data. The front-end file provides the interface for user interaction with the device, and the back-end file is used to execute device commands.

[0025] The code generation module is used to build web service program configuration data based on shared keywords, generate web service request data packets using web server configuration data, and obtain the target device response by sending request data packets.

[0026] The beneficial effects of this invention are:

[0027] This invention extracts the basic block path that triggers vulnerabilities from vulnerability alert data, extracts key items and corresponding values ​​from the basic block path, where the key items are strings appearing in the basic block path and the corresponding values ​​are judgment values ​​for basic block jumps; it searches for key items in front-end file data and obtains shared keywords representing the connection between front-end web service file data and back-end file data by matching them with key items in back-end file data; it constructs web service program configuration data based on the shared keywords, generates web service request data packets using the web server configuration data, and obtains the target device response by sending the request data packets; by combining the characteristics of embedded devices, it automatically generates vulnerability verification code based on the information extracted from vulnerability alert information and the shared keywords between the front-end and back-end, effectively improving vulnerability detection efficiency, ensuring the accuracy and timeliness of vulnerability detection, facilitating timely code reinforcement and improvement, and demonstrating good application results. Attached image description:

[0028] Figure 1 This is a schematic diagram of the automated PoC generation process for embedded devices based on front-end and back-end keyword sharing in the embodiment.

[0029] Figure 2 This is a schematic diagram of the backend file analysis architecture in the embodiment;

[0030] Figure 3 This is a schematic diagram of the data extraction function in the example;

[0031] Figure 4 This is an illustration of a buffer overflow vulnerability in the example.

[0032] Figure 5 This example illustrates the use of key items to match front-end files. Detailed implementation method:

[0033] To make the objectives, technical solutions, and advantages of this invention clearer and more understandable, the invention will be further described in detail below with reference to the accompanying drawings and technical solutions.

[0034] Regarding the automation of vulnerability detection in embedded devices, the embodiments of this invention are described in [reference needed]. Figure 1 As shown, an automated method for generating PoC for embedded devices based on front-end and back-end keyword sharing is provided, comprising:

[0035] S101. Extract the basic block path that triggers the vulnerability based on the vulnerability alarm data, and extract key items and corresponding values ​​from the basic block path. The key items are strings that appear in the basic block path, and the corresponding values ​​are judgment values ​​for basic block jumps.

[0036] The basic block path triggering the vulnerability is obtained using symbolic execution technology. Static analysis is then used to extract the strings appearing in the basic block path and the judgment values ​​of the basic block jumps. The strings are used as key items, and the judgment values ​​of the jumps are used as the corresponding values ​​of the key items.

[0037] Specifically, based on the basic block path for vulnerability triggering extracted from vulnerability alert data, it can be designed to include:

[0038] Perform targeted symbolic execution on abnormal information in vulnerability alert data, use a variable array to record basic blocks in the symbolic execution path, and delete basic blocks that do not belong to the exploration path branches when backtracking the exploration path. Use the basic blocks recorded by the variable array when a suspicious vulnerability point is explored as the basic blocks of the required vulnerability triggering basic block path.

[0039] Web-based vulnerabilities in embedded devices arise because externally input data is not filtered or properly processed after being sent to the backend for file handling, and dangerous functions such as strcpy, sprintf, and system are called. In other words, the parameters of these dangerous functions are influenced by the externally input data. Therefore, to trigger the vulnerability, the web service data packets need to be configured to ensure that the data in the packets can trigger the vulnerability when the embedded device processes the request packets.

[0040] like Figure 2 As shown, the basic block path information from the function entry point to the alert vulnerability point is first extracted. Then, IDAPro's Python script is used to parse the data extraction functions appearing on the basic block path and the key item strings contained in the data extraction functions. Next, the jump conditions of the basic blocks in the basic block path are identified, and the values ​​corresponding to the key item strings are solved. The key items and their corresponding values ​​constitute the data part of the web request in the vulnerability verification code.

[0041] Obtaining the specific basic block path that triggers the vulnerability is the first step in constructing vulnerability verification code. Relying on taint source data, taint propagation functions, and suspected vulnerability points from the alert information, targeted symbolic execution is performed. During symbolic execution, a variable array is maintained to record the basic blocks contained in the current path. When the symbolic execution backtracks to explore the path, basic blocks that do not belong to the next path branch are dynamically deleted until a suspected vulnerability point is discovered. The data in the variable array then represents the required basic block path.

[0042] The key items extracted from the basic block path may include:

[0043] Based on the data extraction function and using the function call rules, the basic block path is traversed. It is determined whether the function called by the call instruction type after the parameter passing instruction type is the data extraction function. If so, the parameters passed in the parameter passing instruction are used as the key items in the basic block path. The data extraction function is the function that parses the front-end web service request data packet in the back-end web service processing program.

[0044] In the backend web service processing program, the request data packets submitted by the frontend web file are parsed through the data extraction function. The data extraction function is the same in a program, and the input parameter of the data extraction function is the string of the key item to be extracted.

[0045] like Figure 3 The image shows a call to the data extraction function FUN_1AB18 in the httpd web service program of the Netgear R7000 router firmware. In this call, the string "qos_policy" passed via the LDR r1, = s_qos_policy; "qos_policy" directive corresponds to the "qos_policy" configuration item in the web request data. To effectively identify key items contained in the basic block path, we consider using "LDR" type directives and "BL" directives as characteristics. According to function call rules, parameter passing is completed before function call. Therefore, the characteristic of a data processing function is that it first uses the "LDR" type instruction to pass parameters, and then uses the "BL" instruction to call it. Therefore, the designed extraction method involves traversing instructions within the basic block to find the "LDR" instruction, and then determining whether the function called by the "BL" instruction following the "LDR" instruction is a data extraction function or a configuration setting function. If it is a data extraction function, it indicates that the parameter passed in the "LDR" instruction is the key data item in the vulnerability verification code; if it is a configuration setting function, it is skipped. The specific key item extraction algorithm is shown in Algorithm 1.

[0046]

[0047] The extraction of key item values ​​from the basic block path may include:

[0048] Based on the basic block conditional jump instructions, the function parameter information where the vulnerability trigger point is located, and the vulnerability type, the jump between different basic blocks is determined by the conditional jump instructions. The value of the key item is obtained by judging the value of the specified register before the jump. The conditional jump instructions include jump instructions with unequal values ​​and jump instructions with equal values.

[0049] In this embodiment, if the specified register corresponds to a key item when determining the value of the specified register, then the value of the specified register is used as the value corresponding to the key item; if the specified register corresponds to multiple key items when determining the value of the specified register, then it is identified whether the last instruction of the basic block is a conditional jump instruction. If it is, then it is traced back to find the most recent conditional judgment instruction, and the parameter of the most recent conditional judgment instruction is extracted. If the parameter is a key item, then the value of the parameter is used as the value corresponding to the key item. If the parameter depends on multiple key items, then the basic block is back-analyzed using data flow analysis technology to find the source of the judgment parameter in the conditional jump instruction, and the parameter is represented by an expression of multiple key items. The values ​​corresponding to multiple key items are obtained by constraining and solving the expression.

[0050] Successful vulnerability triggering requires not only configuring all extracted critical items but also setting these critical items to values ​​that enable navigation along the basic block path. Different values ​​for a single critical item will cause the program to run along different paths. Although there may be more than one basic block path to the vulnerability trigger point, all trigger paths are fixed. Only when the critical items extracted in the previous stage are configured with appropriate values ​​can the program be guaranteed to reach the vulnerability trigger point at runtime according to the trigger path.

[0051] like Figure 4 The image shows an example of a buffer overflow vulnerability in the httpd web service program of the Netgear R7000 router firmware. When the length of the parameter "qos_policy" exceeds a certain limit of 128, repeated transmission of the same "qos_policy" will cause an overflow at 0x82c3c in the function FUN_00082b28. The image also shows that the data extraction function FUN_001AB18...

[0052] The data represented by the strings 'apply' and 'qos_policy' has been extracted, which means that the names of the key items in the Web request in the vulnerability verification code have been extracted. Now, the values ​​of the key items need to be determined. Two factors need to be considered: one is to ensure that the jump is performed according to the basic block path obtained earlier, and the other is to ensure that the vulnerability can be triggered.

[0053] Regarding the first factor, we need to analyze the conditional statements and jump instructions within the basic blocks. For the second factor, we need to analyze the parameter information and vulnerability type of the function where the vulnerability trigger point is located, and then determine how to set the values ​​of the relevant critical items to trigger the vulnerability. Jumps between different basic blocks within a function are accomplished through a combination of conditional statements and jump instructions. In this embodiment, the conditional statements are mainly divided into unequal value jump instructions and equal value jump instructions, namely the "BNE" and "BEQ" instructions. Before jumping, these two types of jump instructions often evaluate the value of a specific register. A common scenario is that the value of the specific register being evaluated is the value corresponding to the critical item. Another more complex scenario is that the value of the specific register being evaluated is affected by multiple critical items, requiring evaluation of the result of the operations on these multiple critical items.

[0054] For various scenarios, the approach to extracting key item values ​​is as follows: First, identify whether the last instruction of the basic block is a conditional jump instruction. If it is, the next step is to backtrack to find the most recent conditional judgment instruction and then extract the parameter of that instruction. If the parameter is the key item, then the value of this parameter is the value corresponding to the key item. If the parameter depends on multiple key items, data flow analysis technology is needed to backtrack and analyze the basic block to find the source of the judgment parameter in the conditional jump instruction, and represent the parameter using expressions of multiple key items. Then, the expressions are constrained and solved to obtain the values ​​corresponding to multiple key items.

[0055] The above methods can extract the corresponding values ​​of key data items, ensuring that the device successfully reaches the basic block where the vulnerability point is located according to the vulnerability triggering path. However, it is still necessary to solve the problem of how to trigger the vulnerability. Since the corresponding values ​​of the key items for vulnerability triggering are often not directly obtainable from the program, it is necessary to analyze the parameters of the vulnerable function. By tracing the use of registers when the function pushes onto the stack, analyzing the function stack space layout, the definition of the parameters can be obtained, thereby determining the value that triggers the vulnerability. Figure 4 In the vulnerability example, analysis of the conditional statements and jump instructions revealed that apply ≠ 0; the length of qos_policy needs to be greater than 128. Only with this configuration can the vulnerability trigger point be reached and the vulnerability be triggered.

[0056] S102. Search for key items in the front-end file data and obtain shared keywords that represent the connection between the front-end web service file data and the back-end file data by matching them with key items in the back-end file data. The front-end file provides an interface for user interaction with the device, and the back-end file is used to execute device commands.

[0057] Shared keywords are used to identify the connections between front-end web files and back-end files. Using the key items obtained in the previous stage, a search is performed in the front-end files, matching strings contained in the front-end and back-end files to identify the web service where the vulnerability is triggered. After obtaining the front-end web files, they are analyzed to determine the format of the web service data packets and how these packets are sent.

[0058] While constructing the data portion of a web request is feasible, successfully sending the request data packet requires considering which web service the vulnerability sends the request to, the format of the web service data packet, and the method used to send the data packet to the backend web service handler. These three questions fall under the scope of frontend files, therefore requiring integration with frontend file analysis of embedded devices to resolve these issues and improve the construction of the web request.

[0059] In the field of embedded systems, devices typically provide diverse web services to meet end-users' functional needs and facilitate configuration settings. These services are implemented through front-end and back-end files of the embedded system. The front-end file constitutes the user interface, providing the interface for user interaction with the device, while the back-end file contains the core code for business logic and device management, executing specific device commands. When an embedded device receives a web request from the outside world, the request is first received by the front-end file. These front-end files are responsible for classifying the request and forwarding it to the corresponding back-end processing logic. This architecture allows the device to flexibly handle various requests, but it also leads to complex dependencies between front-end and back-end files. Specifically, a front-end file may depend on multiple back-end files to complete a function; similarly, a back-end file may be called by different front-end files to serve different functions. Therefore, finding the web service in the front-end file that can trigger a back-end vulnerability becomes crucial.

[0060] Often, due to programming standards or variable naming conventions, front-end data receiving functions and back-end data processing functions use similar or identical variable names. This means that the front-end treats user input as keywords and encodes these keywords into the data packets it sends. Correspondingly, the back-end parses these data packets, extracts these keywords, and interprets the user input. By leveraging this pattern, keywords can be identified in the back-end code, and then a corresponding search can be performed in the front-end code to match key strings between the front-end and back-end. This method can help locate relevant front-end files to some extent.

[0061] Therefore, in this embodiment, a technique of sharing keywords between the front-end and back-end is used to find the front-end web service file that triggers the back-end vulnerability. The general process involves using multiple key strings obtained from the back-end analysis module as keywords, and then searching and matching them using the `strings` keyword in the front-end file. Using multiple key strings avoids the situation where multiple web service files contain the same string. For example... Figure 5 As shown, the string 'qos_policy' is used to... Figure 5 The search for the front-end web service file containing the buffer overflow vulnerability revealed that the front-end web service file is Quick_QOS_add_service.htm.

[0062] S103. Construct web service program configuration data based on shared keywords, generate web service request data packets using web server configuration data, and obtain the target device response by sending request data packets.

[0063] The information and data acquired in the above stages will be organized into a unified format, and data packets will be constructed and sent. The required functionalities include: device login, obtaining web handlers, constructing data to change configurations, and sending data packets.

[0064] Specifically, the configuration data for building a web service program based on shared keywords can be designed to include:

[0065] A session is created using a dictionary and a request library. Web services are obtained by sending requests. Specified parameters are extracted from the header of the embedded device's response packet, and a function to log in to the embedded device is generated.

[0066] The login request function is used to obtain the web service handler, the tag attribute information in the front-end file is extracted, the configuration data is constructed by combining the key items and corresponding values, the address of the web service handler where the vulnerability point is located in the embedded device is generated, and the web service request data packet is constructed.

[0067] By analyzing the Proof of Code (PoC) of existing vulnerabilities, it was found that the PoC mainly consists of four modules: login module, web handler acquisition module, configuration data construction module, and data packet sending module.

[0068] To send configuration data packets to an embedded device, you first need to log in to the device. For this purpose, this chapter designs a function `login(ip)`. First, a `headers` dictionary is defined to store information from the HTTP request headers. For example, `Accept` specifies the types of responses the client can accept, `Cache-Control` specifies the client's caching control policy, `DNT` indicates that the server should not track user behavior, and `User-Agent` specifies the client's browser type and version. Then, a session is created using the `requests` library, sending a GET request to the web service obtained in the previous section. Next, the `set-cookie` parameter is extracted from the embedded device's response header. Then, the regular expression `re.findall(r'XSRF_TOKEN=(.*?);',set-cookie,re.M|re.I)` is used in the `set-cookie` parameter to extract `XSRF_TOKEN`, which is used in the next stage of web service processing to extract the CGI file.

[0069] The vulnerability triggering process begins with a configuration adjustment request for the device's web service. This operation is implemented by the `register_request` function, which encapsulates the configuration request process for the web service. This function accepts three key parameters: the embedded device's network interface address (IP), the Base64 encoded format of the user authentication information, and the cross-site request forgery token (XSRF_TOKEN) obtained through the previous login steps.

[0070] In the function execution flow, an HTTP request header dictionary (headers) is first constructed, followed by specifying the target URL of the request. Furthermore, by instantiating a `requests.Session` object and setting its `verify` property to `False`, the SSL certificate verification process is bypassed to prevent SSL-level verification errors from interfering with the request process. The function then communicates with the target device by initiating a GET request with a set timeout limit (10 seconds) and uses the response data to perform subsequent parsing operations. The parsing phase primarily uses regular expressions to extract the CGI URL from the response. This URL identifies the entry point for the web service's processing logic and is the target path for form data submission.

[0071] After completing the above operations, the `register_request` function returns the extracted CGI URL, which serves as the basis for subsequent configuration transmission. The validity of the returned CGI URL is verified to confirm that the web service configuration request has been successfully processed. Once verification is successful, specific configuration data can be sent to the target device. Certain fields or parameters contained in this data may trigger identified security vulnerabilities.

[0072] To ensure the proper construction of web request data packets, the front-end web service file is analyzed, and the attribute information of the input, select, and form tags in the file is extracted. The configuration data is constructed by combining the key items and their corresponding values. The previously obtained CGI URL is set as the address of the web service handler where the vulnerability point is located in the embedded device. Finally, the session library is used to send the request and return the response from the target device.

[0073] Furthermore, based on the above method, this embodiment of the invention also provides an automated PoC generation system for embedded devices based on front-end and back-end keyword sharing, comprising: a path extraction module, a shared matching module, and a code generation module, wherein...

[0074] The path extraction module is used to extract the basic block path that triggers the vulnerability based on the vulnerability alarm data, and to extract key items and corresponding values ​​from the basic block path. The key items are strings that appear in the basic block path, and the corresponding values ​​are judgment values ​​for basic block jumps.

[0075] The shared matching module is used to search for key items in the front-end file data and obtain shared keywords that represent the connection between the front-end web service file data and the back-end file data by matching them with key items in the back-end file data. The front-end file provides the interface for user interaction with the device, and the back-end file is used to execute device commands.

[0076] The code generation module is used to build web service program configuration data based on shared keywords, generate web service request data packets using web server configuration data, and obtain the target device response by sending request data packets.

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

[0078] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0079] The units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations are not considered to be beyond the scope of this invention.

[0080] Those skilled in the art will understand that all or part of the steps in the above methods can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. Optionally, all or part of the steps in the above embodiments can also be implemented using one or more integrated circuits. Accordingly, each module / unit in the above embodiments can be implemented in hardware or as a software functional module. This invention is not limited to any particular combination of hardware and software.

[0081] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for automatically generating Proof-of-Concept (PoC) for embedded devices based on front-end and back-end keyword sharing, characterized in that, Include: Based on the vulnerability alert data, the basic block path triggering the vulnerability is extracted. Key items and corresponding values ​​are extracted from the basic block path. The key items are strings appearing in the basic block path, and the corresponding values ​​are judgment values ​​for basic block jumps. Extracting key items from the basic block path includes: traversing the basic block path according to the data extraction function and using function call rules; determining whether the function called by the call instruction type after the parameter passing instruction type is a data extraction function; if so, the parameters passed in the parameter passing instruction are used as key items in the basic block path. The data extraction function is a function in the backend web service processing program that parses the frontend web service request data packet. Extracting the corresponding values ​​of key items from the basic block path includes: based on the basic block conditional jump instruction and the function parameter information and vulnerability type of the vulnerability trigger point, and judging the jump between different basic blocks through the conditional jump instruction; obtaining the corresponding values ​​of key items based on the value of the specified register before the jump; the conditional jump instruction includes unequal value jump instructions and equal value jump instructions. Search for key items in the front-end file data and obtain shared keywords that represent the connection between the front-end web service file data and the back-end file data by matching them with key items in the back-end file data. The front-end file provides the interface for users to interact with the device, and the back-end file is used to execute device commands. The web service program configuration data is constructed based on shared keywords. The web server configuration data is used to generate web service request data packets, and the response from the target device is obtained by sending the request data packets.

2. The method for automated generation of PoC for embedded devices based on front-end and back-end keyword sharing according to claim 1, characterized in that, Based on the vulnerability alert data, the basic block path for vulnerability triggering is extracted, including: Perform targeted symbolic execution on abnormal information in vulnerability alert data, use a variable array to record basic blocks in the symbolic execution path, and delete basic blocks that do not belong to the exploration path branches when backtracking the exploration path. Use the basic blocks recorded by the variable array when a suspicious vulnerability point is explored as the basic blocks of the required vulnerability triggering basic block path.

3. The method for automated generation of PoC for embedded devices based on front-end and back-end keyword sharing according to claim 1, characterized in that, The value of the key item is obtained by checking the value of the specified register before the jump, including: If a specified register corresponds to a key item when determining the value of a specified register, then the value of that specified register is used as the value corresponding to the key item. If the specified register corresponds to multiple key items when determining the value of the specified register, then identify whether the last instruction of the basic block is a conditional jump instruction. If it is, then backtrack upwards to find the most recent conditional judgment instruction, extract the parameter of the most recent conditional judgment instruction, and if the parameter is a key item, then use the value of the parameter as the corresponding value of the key item. If the parameter depends on multiple key items, then use data flow analysis technology to backtrack the basic block to find the source of the judgment parameter in the conditional jump instruction, represent the parameter with an expression of multiple key items, and obtain the corresponding values ​​of multiple key items by constraining and solving the expression.

4. The method for automated generation of PoC for embedded devices based on front-end and back-end keyword sharing according to claim 1, characterized in that, The value of the key item is obtained by checking the value of the specified register before the jump, and it also includes: By tracing the use of registers when the vulnerable function pushes onto the stack, the parameter definitions are obtained by analyzing the function stack space layout, and the values ​​corresponding to the key items that trigger the vulnerability are determined based on the parameter definitions.

5. The method for automated generation of PoC for embedded devices based on front-end and back-end keyword sharing according to claim 1, characterized in that, Configuration data for a web service program built based on shared keywords includes: A session is created using a dictionary and a request library. Web services are obtained by sending requests. Specified parameters are extracted from the header of the embedded device's response packet, and a function to log in to the embedded device is generated. The login request function is used to obtain the web service handler, the tag attribute information in the front-end file is extracted, the configuration data is constructed by combining the key items and corresponding values, the address of the web service handler where the vulnerability point is located in the embedded device is generated, and the web service request data packet is constructed.

6. An automated PoC generation system for embedded devices based on front-end and back-end keyword sharing, characterized in that, It includes: a path extraction module, a shared matching module, and a code generation module. The path extraction module is used to extract the basic block path that triggers a vulnerability based on vulnerability alert data, and to extract key items and corresponding values ​​from the basic block path. The key items are strings appearing in the basic block path, and the corresponding values ​​are judgment values ​​for basic block jumps. Extracting key items from the basic block path includes: traversing the basic block path according to the data extraction function and using function call rules; determining whether the function called by the call instruction type after the parameter passing instruction type is the data extraction function; if so, using the parameters passed in the parameter passing instruction as key items in the basic block path; the data extraction function is the function that parses the front-end web service request data packet in the back-end web service processing program. Extracting the corresponding values ​​of key items from the basic block path includes: based on the basic block conditional jump instruction and the function parameter information and vulnerability type of the vulnerability trigger point, and judging the jump between different basic blocks through the conditional jump instruction; obtaining the corresponding values ​​of key items based on the value of the specified register before the jump; the conditional jump instruction includes unequal value jump instructions and equal value jump instructions. The shared matching module is used to search for key items in the front-end file data and obtain shared keywords that represent the connection between the front-end web service file data and the back-end file data by matching them with key items in the back-end file data. The front-end file provides the interface for user interaction with the device, and the back-end file is used to execute device commands. The code generation module is used to build web service program configuration data based on shared keywords, generate web service request data packets using web server configuration data, and obtain the target device response by sending request data packets.

7. An electronic device, characterized in that, include: At least one processor, and a memory coupled to said at least one processor; The memory stores a computer program that can be executed by the at least one processor to implement the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, enables the implementation of the method as described in any one of claims 1 to 5.

Images