An automated detection method for firmware update vulnerabilities of internet of things devices

Abstract

This invention relates to an automated method for detecting firmware update vulnerabilities in IoT devices, comprising the following steps: extracting the file system from the firmware and separating the front-end and back-end files; parsing the front-end and back-end files to obtain the back-end binary file to be analyzed; parsing the back-end binary file to be analyzed and constructing a call graph between the back-end binary files, a function call graph of the firmware update process, and a function control flow graph; performing vulnerability detection based on the constructed call graph between the back-end binary files, the function call graph of the firmware update process, and the function control flow graph, and outputting a vulnerability report. Compared with existing technologies, this invention can automatically, accurately, and efficiently detect firmware update vulnerabilities in IoT devices.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to an automated detection method for firmware update vulnerabilities in Internet of Things (IoT) devices. Background Technology

[0002] IoT devices are widely used in many fields such as network communication, industrial control, smart homes, and smart healthcare. As a crucial component of IoT devices, firmware provides functions such as cloud interaction, inter-device communication, and security. To protect devices from cyberattacks, IoT device manufacturers typically release new firmware versions to fix vulnerabilities in older versions—this is known as firmware updates. However, firmware updates themselves are vulnerable to cyberattacks, such as man-in-the-middle attacks, firmware tampering, and phishing attacks. A successful attack targeting a firmware update usually grants the attacker access to the internal data of the physical network device and control over it. If the attack targets critical devices such as routers and gateways, the attacker can further gain control of the network and servers, with an impact far exceeding that of attacks targeting IoT devices.

[0003] Currently, the detection of firmware update vulnerabilities in IoT devices mainly relies on manual reverse engineering. The accuracy and efficiency of this method are highly dependent on the technical skills of the analysts, and the detection cost is enormous, making it difficult to cope with the increasing number of cyberattacks. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the existing technology and provide an automated detection method for firmware update vulnerabilities in IoT devices, which can automatically, accurately and efficiently detect firmware update vulnerabilities in IoT devices.

[0005] The objective of this invention can be achieved through the following technical solution: an automated detection method for firmware update vulnerabilities in Internet of Things (IoT) devices, comprising the following steps:

[0006] S1. Extract the file system from the firmware and separate the front-end and back-end files;

[0007] S2. Parse the front-end and back-end files to obtain the back-end binary file to be analyzed;

[0008] S3. Parse the backend binary files to be analyzed, and construct the call graph between the backend binary files to be analyzed, the function call graph of the firmware update process, and the function control flow graph.

[0009] S4. Based on the call graph between the backend binary files to be analyzed, the function call graph of the firmware update process, and the function control flow graph constructed in step S3, perform vulnerability detection and output a vulnerability report.

[0010] Furthermore, step S1 specifically includes the following steps:

[0011] S11. Extract the file system from the binary format firmware;

[0012] S12. Separate the front-end web file and the back-end binary file from the file system.

[0013] Furthermore, step S1 specifically involves using the API provided by the firmware extraction tool Binwalk to write script code to extract the file system from the binary format firmware;

[0014] Specifically, step S12 involves separating the front-end and back-end files from the file system according to the folder and file format of the front-end and back-end files.

[0015] Furthermore, step S2 specifically includes the following steps:

[0016] S21. For the front-end web file, scan the HTML, JavaScript, and PHP code, filter out functions related to firmware updates, and obtain the strings in the HTTP requests.

[0017] S22. Based on the obtained string, filter the backend binary files to obtain the backend binary files to be analyzed.

[0018] Furthermore, the backend binary file to be analyzed includes firmware version check, cloud firmware download, local firmware upload, firmware decryption verification, new firmware writing, and device restart files.

[0019] Furthermore, the specific process of step S21 is as follows:

[0020] For front-end web files, first scan the HTML file and extract its contents. <button>The set of onclick attributes for the tag, B< / button> <button>< / button> Parameters of I18N and <button>The set T of the value attribute of the tag, <input> The `onclick` attribute set of tags (I);

[0021] Based on a pre-defined corpus, sets B, T, and I are filtered using regular expression matching, resulting in sets B`, T`, and I`. Then, the sets containing B` and T` are further analyzed.< / button> <button>Find the intersection of the tag sets and obtain their onclick attribute set BT`.

[0022] For each element in the BT` and I` sets, construct its abstract syntax tree (AST). Retrieve the name attribute of callee:Identifier and property:Identifier in the AST. Then, search for the function represented by the name attribute in the front-end web file. Through code scanning, search for HTTP requests. If no HTTP request is found, recursively follow the steps for processing the BT` and I` sets until an HTTP request is found or the recursion reaches the lowest level function call. Finally, obtain the string in the HTTP request to form set K.

[0023] Furthermore, the specific process of step S22 is as follows:

[0024] Retrieve backend binary files. If a backend binary file contains at least one element from set K, then mark that file as a backend binary file to be analyzed.

[0025] Furthermore, step S3 specifically includes the following steps:

[0026] S31. For each backend binary file Bi to be analyzed, retrieve the corresponding parameters of the preset function and check whether the parameters contain preset keywords to obtain the backend binary file Bj (j≠i) indicated by the preset keywords. Bi and Bj form a call and called relationship. With Bi and Bj files as nodes and the call relationship as edges, construct a call graph between the backend binary files to be analyzed.

[0027] S32. For each backend binary file to be analyzed in the call graph between backend binary files, locate the entry function by the set entry function code characteristics, use a disassembler to identify the call relationship between the entry function and other functions, and construct the function call graph of the firmware update process of the backend binary file to be analyzed with functions as nodes and function call relationships as edges.

[0028] S33. For the function call graph of the firmware update process of a certain backend binary file to be analyzed, for each function, use a disassembler to identify the control flow between its basic blocks, and construct a function control flow graph with basic blocks as nodes and control flow as edges.

[0029] Furthermore, step S4 specifically includes the following steps:

[0030] S41. Based on the call graph between the backend binary files to be analyzed, analyze the function call graph of the firmware update process of each backend binary file to be analyzed one by one according to the call relationship. Specifically, for the function call graph of the firmware update process of each backend binary file to be analyzed, first filter the leaf nodes, select the functions that execute shell commands and third-party library functions from them, and then start from the leaf nodes to the root node for detection.

[0031] S42. During the detection process, for each node, vulnerability detection is performed on each basic block of the function control flow graph according to the set vulnerability characteristics. If the function meets the vulnerability characteristics, it is marked as a potential vulnerability function.

[0032] S43. Perform vulnerability reachability verification. After detecting a potential vulnerable function, continue searching towards the root node. Check whether there are data calls between the nodes from the root node to the node where the potential vulnerable function is located and the node where the potential vulnerable function is located. For nodes where there are data calls, if the data called is input from an external source, mark the potential vulnerable function as a vulnerable function and record the function address, function name, function parameters, function return value, and vulnerability characteristics to form a vulnerability report.

[0033] Furthermore, the specific characteristics of the vulnerability are as follows:

[0034] If the backend binary file to be analyzed is a firmware version check file, then the corresponding vulnerability characteristics are: the wget command does not use HTTPS, and the communication key is hardcoded;

[0035] If the backend binary file to be analyzed is a cloud firmware download file, the corresponding vulnerability characteristics are: HTTPS is not used in the wget command, the communication key is hard-coded, and the firmware is not verified before being downloaded to the IoT device;

[0036] If the backend binary file to be analyzed is a local firmware upload file, then the corresponding vulnerability characteristic is: the firmware was not verified before being uploaded to the IoT device;

[0037] If the backend binary file to be analyzed is a firmware decryption verification file, the corresponding vulnerability characteristics are: missing verification function, weak encryption and weak verification algorithm, and verification function is easy to bypass.

[0038] If the backend binary file to be analyzed is a new firmware write file, then the corresponding vulnerability characteristic is: there is no verification function before the mtd_write command is executed;

[0039] If the backend binary file to be analyzed is a device reboot file, then the corresponding vulnerability characteristic is: no verification function exists before the reboot command is executed.

[0040] Compared with the prior art, the present invention has the following advantages:

[0041] This invention extracts the file system from binary firmware, separates the front-end and back-end files, and then parses them to obtain the back-end binary file to be analyzed. By parsing this back-end binary file, it constructs a call graph between the back-end binary files, a function call graph of the firmware update process, and a function control flow graph. Based on this, it performs automated vulnerability detection and outputs a vulnerability report. This invention eliminates the need for manual reverse engineering of firmware and tedious assembly code analysis; it only requires the firmware file to automatically, accurately, and efficiently detect firmware update vulnerabilities in IoT devices. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the method flow of the present invention;

[0043] Figure 2 This is a call graph between the backend binary files to be analyzed, constructed in the example. Detailed Implementation

[0044] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0045] Example

[0046] like Figure 1 As shown, an automated detection method for firmware update vulnerabilities in IoT devices includes the following steps:

[0047] S1. Extract the file system from the firmware and separate the front-end and back-end files;

[0048] S2. Parse the front-end and back-end files to obtain the back-end binary file to be analyzed;

[0049] S3. Parse the backend binary files to be analyzed, and construct the call graph between the backend binary files to be analyzed, the function call graph of the firmware update process, and the function control flow graph.

[0050] S4. Based on the call graph between the backend binary files to be analyzed, the function call graph of the firmware update process, and the function control flow graph constructed in step S3, perform vulnerability detection and output a vulnerability report.

[0051] This embodiment applies the above-described solution, and its main contents include:

[0052] (1) Firmware file system extraction, front-end and back-end file separation:

[0053] (1.1) Extract the file system from binary format firmware such as .bin and .img;

[0054] (1.2) Separate the front-end web files and back-end binary files in the file system.

[0055] (2) Parse the front-end and back-end files to obtain the back-end binary file to be analyzed:

[0056] (2.1) For the front-end web file, scan the HTML, JavaScript, and PHP code, filter out functions related to firmware updates, and obtain the strings in the HTTP requests;

[0057] (2.2) Filter the backend binary files based on the obtained strings to obtain the backend binary files to be analyzed.

[0058] (3) Parse the backend binary files to be analyzed, and construct the call graph between the backend binary files to be analyzed, the function call graph of the firmware update process, and the function control flow graph:

[0059] (3.1) Parse the binary file to be analyzed and construct the call graph between the backend binary files to be analyzed;

[0060] (3.2) For each backend binary file to be analyzed in the call graph between backend binary files to be analyzed, construct the function call graph of the firmware update process of the backend binary file to be analyzed;

[0061] (3.3) The function call graph of the firmware update process of the backend binary file to be analyzed constructs a function control flow graph for each function.

[0062] (4) Automated vulnerability detection and vulnerability report generation:

[0063] (4.1) Detect vulnerabilities based on their characteristics and mark potentially vulnerable functions;

[0064] (4.2) Perform vulnerability reachability verification, confirm the vulnerable functions, and generate the corresponding vulnerability report.

[0065] Specifically, in step (1):

[0066] (1.1) Firmware is usually a binary file with .bin and .img. Use the API provided by the firmware extraction tool Binwalk to write script code to realize automated firmware extraction and extract the file system from the firmware;

[0067] (1.2) There are two types of files related to firmware updates in the file system: front-end web files and back-end binary files. Front-end web files are usually in html, js, php, or xml format and are generally located in the etc, etc_ro, or htdocs folders under the root directory of the file system. Back-end files are usually in bin or cgi format and are generally located in the bin or sbin folders under the root directory of the file system. A small number are located in the folder where the front-end web files are located. The front-end and back-end files are separated according to the folder where the front-end and back-end files are located and the file format.

[0068] In step (2):

[0069] (2.1.1) For front-end web files, first scan the HTML file to obtain its contents.< / button> <button> The set of onclick attributes for the tag, B< / button> <button>< / button> Parameters of I18N and <button>The set T of the value attribute of the tag, <input> The `onclick` attribute set of tags (I);

[0070] (2.1.2) Based on the corpus shown in Table 1, the sets B, T, and I are filtered using regular expression matching. The filtered sets are B`, T`, and I`. Then, the sets containing B` and T` are further analyzed.< / button> <button>Find the intersection of the tag sets and obtain their onclick attribute set BT`.

[0071] Table 1

[0072]

[0073] (2.1.3) The elements of the BT` and I` sets are usually javascript and php functions. Construct an abstract syntax tree (AST) for each element in the BT` and I` sets, retrieve the name attribute of callee:Identifier and property:Identifier in the AST, and then retrieve the function represented by the name attribute in the front-end web file. Through code scanning, retrieve the HTTP request (if there is no HTTP request, recursively follow the steps of processing the BT` and I` sets until the HTTP request is found or the recursion reaches the lowest level function call), and then obtain the string in the HTTP request to form set K;

[0074] (2.2) Retrieve backend binary files. If a backend binary file contains at least one element from set K, then mark the file as a backend binary file to be analyzed.

[0075] In step (3):

[0076] (3.1) For each backend binary file Bi to be analyzed, retrieve the parameters of functions such as system, fopen, and FCGI_fopen, and check whether the parameters contain keywords such as / bin / , / sbin / , and .cgi. Obtain the backend binary file Bj (j≠i) indicated by these keywords, such as fwupload.cgi. Bi and Bj form a caller-caller relationship. Construct a call graph between the backend binary files to be analyzed, with Bi and Bj as nodes and the call relationship as edges, such as... Figure 2 As shown in the diagram, the backend binary files to be analyzed in this embodiment can be divided into the following categories: checkver.cgi is the firmware version check file, fwdownload.cgi is the cloud firmware download file, fwupload.cgi is the local firmware upload file, imgdecrypt.bin is the firmware decryption and verification file, mtd_write.bin is the new firmware write file, and reboot.cgi is the device reboot file.

[0077] (3.2) For each backend binary file to be analyzed in the call graph between backend binary files, its entry function needs to be identified. The entry function is located by the features shown in Table 2. The call relationship between the entry function and other functions is identified by the disassembler. The function is used as the node and the function call relationship is used as the edge to construct the function call graph of the firmware update process of the backend binary file to be analyzed.

[0078] Table 2

[0079]

[0080] (3.3) For the function call graph of the firmware update process of a certain backend binary file to be analyzed, for each function, use a disassembler to identify the control flow between its basic blocks, and construct a function control flow graph with basic blocks as nodes and control flow as edges.

[0081] In step (4):

[0082] (4.1.1) Based on the call graph between the backend binary files to be analyzed, the function call graph of the firmware update process of each backend binary file to be analyzed is analyzed one by one according to the call relationship. Specifically, for the function call graph of the firmware update process of each backend binary file to be analyzed, the leaf nodes are first filtered, and functions such as system() that execute shell commands and third-party library functions are selected from them. Then, the detection is carried out from the leaf nodes to the root node.

[0083] (4.1.2) During the detection process, for each node, the basic blocks of its function control flow graph are subjected to vulnerability detection according to the vulnerability characteristics shown in Table 3. If the characteristics are met, the function is marked as a potential vulnerability function.

[0084] Table 3

[0085]

[0086] (4.2) Perform vulnerability reachability verification. After detecting a potential vulnerable function, continue to search towards the root node and check whether there are data calls between the nodes between the root node and the node where the potential vulnerable function is located. For nodes that have data calls, if the data they call is input from the outside, mark the potential vulnerable function as a vulnerable function and record the function address, function name, function parameters, function return value, vulnerability characteristics, and form a vulnerability report.

[0087] In summary, this solution is easy to use, requiring no manual reverse engineering of firmware and tedious assembly code analysis; vulnerability detection can be performed simply by providing the firmware file.

[0088] This solution is highly versatile, and the proposed vulnerability detection scheme is applicable to the firmware of IoT devices with various architectures such as ARM, MIPS, and X86, as well as various device types such as routers and switches.< / button>

Claims

1. An automated detection method for firmware update vulnerabilities in Internet of Things (IoT) devices, characterized in that, Includes the following steps: S1. Extract the file system from the firmware and separate the front-end and back-end files; S2. Parse the front-end and back-end files to obtain the back-end binary file to be analyzed; S3. Parse the backend binary files to be analyzed, and construct the call graph between the backend binary files to be analyzed, the function call graph of the firmware update process, and the function control flow graph. S4. Based on the call graph between the backend binary files to be analyzed, the function call graph of the firmware update process, and the function control flow graph constructed in step S3, perform vulnerability detection and output a vulnerability report. Step S3 specifically includes the following steps: S31. For each backend binary file Bi to be analyzed, retrieve the corresponding parameters of the preset function and check whether the parameters contain preset keywords to obtain the backend binary file Bj(j) to be analyzed indicated by the preset keywords. i) Bi and Bj form a caller-caller relationship. Using Bi and Bj files as nodes and the call relationship as edges, construct a call graph between the backend binary files to be analyzed. S32. For each backend binary file to be analyzed in the inter-call graph of a backend binary file to be analyzed, locate the entry function by the set entry function code characteristics, use a disassembler to identify the call relationship between the entry function and other functions, and construct the inter-call graph of the firmware update process of the backend binary file to be analyzed with functions as nodes and function call relationships as edges. S33. For the function call graph of the firmware update process of a certain backend binary file to be analyzed, for each function, use a disassembler to identify the control flow between its basic blocks, and construct a function control flow graph with basic blocks as nodes and control flow as edges. Step S4 specifically includes the following steps: S41. Based on the call graph between the backend binary files to be analyzed, analyze the function call graph of the firmware update process of each backend binary file to be analyzed one by one according to the call relationship. Specifically, for the function call graph of the firmware update process of each backend binary file to be analyzed, first filter the leaf nodes, select the functions that execute shell commands and third-party library functions from them, and then start from the leaf nodes to the root node for detection. S42. During the detection process, for each node, vulnerability detection is performed on each basic block of the function control flow graph according to the set vulnerability characteristics. If the function meets the vulnerability characteristics, it is marked as a potential vulnerability function. S43. Perform vulnerability reachability verification. After detecting a potential vulnerable function, continue searching towards the root node. Check whether there are data calls between the nodes from the root node to the node where the potential vulnerable function is located and the node where the potential vulnerable function is located. For nodes where there are data calls, if the data called is input from an external source, mark the potential vulnerable function as a vulnerable function and record the function address, function name, function parameters, function return value, and vulnerability characteristics to form a vulnerability report.

2. The automated detection method for firmware update vulnerabilities in IoT devices according to claim 1, characterized in that, Step S1 specifically includes the following steps: S11. Extract the file system from the binary format firmware; S12. Separate the front-end web file and the back-end binary file from the file system.

3. The automated detection method for firmware update vulnerabilities in IoT devices according to claim 2, characterized in that, Specifically, step S1 involves using the API provided by the firmware extraction tool Binwalk to write script code to extract the file system from binary format firmware. Specifically, step S12 involves separating the front-end and back-end files from the file system according to the folder and file format of the front-end and back-end files.

4. The automated detection method for firmware update vulnerabilities in IoT devices according to claim 2, characterized in that, Step S2 specifically includes the following steps: S21. For the front-end web file, scan the HTML, JavaScript, and PHP code, filter out functions related to firmware updates, and obtain the strings in the HTTP requests. S22. Based on the obtained string, filter the backend binary files to obtain the backend binary files to be analyzed.

5. The automated detection method for firmware update vulnerabilities in IoT devices according to claim 4, characterized in that, The backend binary files to be analyzed include firmware version check, cloud firmware download, local firmware upload, firmware decryption verification, new firmware writing, and device reboot files.

6. The automated detection method for firmware update vulnerabilities in IoT devices according to claim 4, characterized in that, The specific process of step S21 is as follows: For front-end web files, first scan the HTML file and extract its contents. <button> The set of onclick attributes for the tag, B< / button> <button>< / button> Parameters of I18N and <button>The set T of the value attribute of the tag, <input> The `onclick` attribute set of tags (I);< / button> Based on a pre-defined corpus, sets B, T, and I are filtered using regular expression matching, resulting in sets B`, T`, and I`. Then, the sets containing B` and T` are further analyzed. <button> Find the intersection of the tag sets and obtain their onclick attribute set BT`.< / button> For each element in the BT` and I` sets, construct its abstract syntax tree (AST). Retrieve the name attribute of callee: Identifier and property: Identifier in the AST. Then, search for the function represented by the name attribute in the front-end web file. Through code scanning, search for HTTP requests. If no HTTP request is found, recursively follow the steps for processing the BT` and I` sets until an HTTP request is found or the recursion reaches the lowest level function call. Finally, obtain the string in the HTTP request to form set K.

7. The automated detection method for firmware update vulnerabilities in IoT devices according to claim 6, characterized in that, The specific process of step S22 is as follows: Retrieve backend binary files. If a backend binary file contains at least one element from set K, then mark that file as a backend binary file to be analyzed.

8. The automated detection method for firmware update vulnerabilities in IoT devices according to claim 1, characterized in that, The specific vulnerability characteristics defined are as follows: If the backend binary file to be analyzed is a firmware version check file, then the corresponding vulnerability characteristics are: the wget command does not use HTTPS, and the communication key is hardcoded; If the backend binary file to be analyzed is a cloud firmware download file, the corresponding vulnerability characteristics are: HTTPS is not used in the wget command, the communication key is hard-coded, and the firmware is not verified before being downloaded to the IoT device; If the backend binary file to be analyzed is a local firmware upload file, then the corresponding vulnerability characteristic is: the firmware was not verified before being uploaded to the IoT device; If the backend binary file to be analyzed is a firmware decryption verification file, the corresponding vulnerability characteristics are: missing verification function, weak encryption and weak verification algorithm, and verification function is easy to bypass. If the backend binary file to be analyzed is a new firmware write file, then the corresponding vulnerability characteristic is: there is no verification function before the mtd_write command is executed; If the backend binary file to be analyzed is a device reboot file, then the corresponding vulnerability characteristic is: no verification function exists before the reboot command is executed.

Images