Device firmware vulnerability detection method and device, computer device and medium

Abstract

The application relates to the field of vulnerability detection, in particular to a vulnerability detection method and device for device firmware, a computer device and a medium, which comprises the following steps: obtaining a firmware file of a device; when the firmware file is a binary component file, obtaining a first string of a first component name and a first component version number from the firmware file; determining a plurality of first candidate strings matched with the first string from strings of vulnerabilities in a vulnerability database; the first candidate string is a string of a second component name and a second component version number corresponding to a vulnerability; determining a vulnerability abstract corresponding to each first candidate string, and determining the confidence of each first candidate string based on a third component name and a third component version number in the vulnerability abstract by using a first language model; taking a first candidate string with a confidence reaching a first threshold value as a second string, and determining a vulnerability to which the second string belongs as a vulnerability of the firmware file. The method can improve the accuracy of vulnerability identification.

Description

Technical Field

[0001] This application relates to the field of vulnerability detection technology, and in particular to a method, apparatus, computer device, and medium for detecting vulnerabilities in device firmware. Background Technology

[0002] Vulnerabilities in device firmware come in many forms, including N-day vulnerabilities. An N-day vulnerability refers to a vulnerability that has been publicly disclosed and patched N days ago, but due to various reasons, some users have not installed the patch, leaving their systems exposed to risk. Here, "N" represents the number of days since the patch was released; it could be a few days, months, or even years. Although patches have been released for N-day vulnerabilities, some servers still harbor unpatched N-day vulnerabilities, making the threat posed by N-day vulnerabilities to the Internet of Things (IoT) significant.

[0003] In the prior art, invention patent application CN 116561768 A mainly determines the components with vulnerabilities and the vulnerabilities in the components by calculating the distance between component information in the firmware file and vulnerability information in the vulnerability database. However, this has the problem of low vulnerability identification accuracy. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, and medium for detecting vulnerabilities in device firmware that can improve the accuracy of vulnerability identification, in order to address the aforementioned technical problems.

[0005] A method for detecting vulnerabilities in device firmware, the method comprising:

[0006] S1. Obtain the device's firmware file. When the firmware file is a component file in binary form, obtain a first string containing the first component name and the first component version number from the firmware file.

[0007] S2. From the strings of each vulnerability in the vulnerability database, determine a plurality of first candidate strings that match the first string; the first candidate strings are the strings of the second component name and the second component version number corresponding to the vulnerability;

[0008] S3. Determine the vulnerability summary corresponding to each of the first candidate strings, and use the first language model to determine the confidence level of each of the first candidate strings based on the third component name and third component version number in the vulnerability summary.

[0009] S4. The first candidate string with a confidence level reaching the first threshold is taken as the second string, and the vulnerability to which the second string belongs is determined to be a vulnerability in the firmware file.

[0010] In this application, by obtaining the device's firmware file, and when the firmware file is a binary component file, a first string containing the first component name and version number is extracted from the firmware file. This allows for targeted extraction of the first string containing the first component name and version number based on the firmware file type, improving extraction accuracy. Multiple first candidate strings matching the first string are identified from the strings of various vulnerabilities in the vulnerability database. These first candidate strings are the strings containing the second component name and version number corresponding to the vulnerability. A vulnerability summary is determined for each first candidate string. Based on the third component name and version number in the vulnerability summary, a first language model is used to determine the confidence level of each first candidate string. The first candidate string with a confidence level reaching a first threshold is designated as the second string, and the vulnerability to which the second string belongs is identified as a vulnerability in the firmware file. This allows for a further screening of the first candidate strings based on confidence levels when multiple first candidate strings are extracted, eliminating erroneous first candidate strings and retaining accurate ones, thereby improving the accuracy of identifying device firmware vulnerabilities.

[0011] In one embodiment, the method for obtaining the first string in step S1 includes:

[0012] The contents of the component file are converted into readable strings, and the preset component name string, component version number string, and first prompt word template are obtained;

[0013] Filter from the readable string to select multiple second candidate strings that match the component name string and the component version number string;

[0014] Based on the first prompt word template and multiple second candidate strings, a second language model is used to output a first string whose confidence level reaches the second threshold.

[0015] In this application, the content of the component file is converted into a readable string, and a preset component name string, component version number string, and first prompt word template are obtained. Multiple second candidate strings that match the component name string and component version number string are filtered from the readable strings. Based on the first prompt word template and multiple second candidate strings, a second language model is used to output a first string with a confidence level reaching a second threshold. In this way, the powerful contextual understanding ability, semantic understanding ability, and confidence evaluation ability of the second language model can be used to accurately filter out the first string of the first component name and the first component version number from multiple second candidate strings, thereby improving the recognition accuracy of the first string.

[0016] In one embodiment, the process of determining the name of the second component and the version number of the second component corresponding to each vulnerability in the vulnerability database in step S2 includes:

[0017] Obtain the vulnerability database and check whether each vulnerability in the vulnerability database is associated with the name of the second component and the version number of the second component;

[0018] When no component information is associated with the target vulnerability, a preset second prompt word template is obtained; the component information is the name of the second component and the version number of the second component.

[0019] Based on the second prompt word template and the vulnerability summary of the target vulnerability, the third component name and the third component version number in the vulnerability summary of the target vulnerability are output using a third language model;

[0020] The name of the third component is used as the name of the second component of the target vulnerability, and the version number of the third component is used as the version number of the second component of the target vulnerability.

[0021] In this application, by acquiring a vulnerability database, it detects whether each vulnerability in the vulnerability data is associated with a second component name and a second component version number. When the target vulnerability is not associated with component information, a preset second prompt word template is acquired. The component information consists of the second component name and the second component version number. Based on the second prompt word template and the vulnerability summary of the target vulnerability, a third language model is used to output the third component name and the third component version number in the vulnerability summary of the target vulnerability. The third component name is used as the second component name of the target vulnerability, and the third component version number is used as the second component version number of the target vulnerability. This can complete the component information for target vulnerabilities for which the vulnerability database is not associated with component information, thereby improving the accuracy of matching when determining multiple first candidate strings that match the first string from the strings of each vulnerability in the vulnerability database.

[0022] In one embodiment, the process of determining the second prompt word template includes:

[0023] Preset initial prompt word template;

[0024] Based on the initial prompt word template, the fourth component name and fourth component version number are extracted from the test set using the fourth language model; the test set includes multiple vulnerability summaries, each of which includes the actual component name and the actual component version number;

[0025] When the name of the fourth component does not match the name of the actual component and / or the version number of the fourth component does not match the version number of the actual component, the initial prompt word template is modified until the name of the fourth component matches the name of the actual component and the version number of the fourth component matches the version number of the actual component, thus obtaining the second prompt word template.

[0026] In this application, when the name of the fourth component and the actual component name do not match and / or the version number of the fourth component does not match the version number of the actual component, the initial prompt word template is modified until the name of the fourth component and the actual component name and the version number of the fourth component match, thus obtaining a second prompt word template. This allows the final second prompt word template to more accurately describe the extraction task, enabling the third language model to output an accurate third component name and third component version number based on the second prompt word template and the vulnerability summary of the target vulnerability.

[0027] In one embodiment, the method further includes:

[0028] When the firmware file is a non-component file in text form, the text content in the firmware file is converted into a third string, and a third prompt word template is obtained;

[0029] Based on the third string and the third prompt word template, the fifth language model is used to output the fourth string containing the firmware name and firmware version number in the third string;

[0030] From the strings of each vulnerability in the vulnerability database, determine multiple third candidate strings that match the fourth string;

[0031] The third candidate string is filtered based on preset filtering conditions to obtain the fifth string, and the vulnerability to which the fifth string belongs is identified as a vulnerability in the firmware file.

[0032] In this application, when the firmware file is a non-component file in text format, the text content in the firmware file is converted into a third string, and a third prompt word template is obtained. Based on the third string and the third prompt word template, a fifth language model is used to output a fourth string containing the firmware name and firmware version number from the third string. This leverages the powerful semantic understanding of the fifth language model to accurately extract the fourth string containing the firmware name and firmware version number from the third string. By identifying multiple third candidate strings that match the fourth string from the strings of various vulnerabilities in the vulnerability database, and filtering the third candidate strings based on preset filtering conditions, a fifth string is obtained. The vulnerability to which the fifth string belongs is then identified as a vulnerability in the firmware file. This dual filtering mechanism achieves accurate filtering of the fifth string, reduces the error rate, and improves the accuracy of firmware file vulnerability identification.

[0033] In one embodiment, the step of filtering the third candidate string based on preset filtering conditions to obtain the fifth string includes:

[0034] If the third candidate string is the same as the fourth string, then the third candidate string is the fifth string;

[0035] If the firmware version number range in the third candidate string includes the firmware version number, and the firmware name in the third candidate string is the same as the firmware name in the fourth string, then the third candidate string is the fifth string;

[0036] If the type of the device affected by the vulnerability to which the third candidate string belongs matches the type of the firmware, then the third candidate string is the fifth string.

[0037] In this application, the third candidate string is determined to be the fifth string when it matches the fourth string; the third candidate string is determined to be the fifth string when the firmware version number range in the third candidate string includes the firmware version number and the firmware name in the third candidate string matches the firmware name in the fourth string; and the third candidate string is determined to be the fifth string when the type of vulnerability to which it belongs matches the type of firmware. This can eliminate some vulnerabilities that are obviously not firmware vulnerabilities.

[0038] In one embodiment, the method further includes:

[0039] A preset keyword database and a file extension database; the keyword database includes multiple preset first keywords, and the file extension database includes multiple preset first file extensions;

[0040] When the second keyword in the firmware file matches any of the first keywords, or when the second file extension of the firmware file matches any of the first file extensions, the firmware file is determined to be a non-component file in text form.

[0041] In this application, the firmware file is determined to be a non-component file in text form when the second keyword in the firmware file matches any first keyword, or when the second file extension of the firmware file matches any first file extension. This enables rapid identification of non-component files in the firmware file.

[0042] A device firmware vulnerability detection apparatus, the apparatus comprising:

[0043] The first string acquisition module is used to acquire the firmware file of the device. When the firmware file is a component file in binary form, it acquires a first string containing the first component name and the first component version number from the firmware file.

[0044] The matching module is used to determine multiple first candidate strings that match the first string from the strings of each vulnerability in the vulnerability database; the first candidate strings are strings of the second component name and the second component version number corresponding to the vulnerability.

[0045] The confidence calculation module is used to determine the vulnerability digest corresponding to each of the first candidate strings, and to determine the confidence of each of the first candidate strings based on the third component name and third component version number in the vulnerability digest using a first language model.

[0046] The vulnerability determination module is used to determine the vulnerability of the firmware file by taking the first candidate string with a confidence level reaching a first threshold as the second string.

[0047] A computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method described above.

[0048] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0049] The beneficial effects of the aforementioned device firmware vulnerability detection device, computer equipment, and media are as follows: By acquiring the device's firmware file, and when the firmware file is a binary component file, the first string containing the first component name and version number is extracted from the firmware file. This allows for targeted extraction of the first string containing the first component name and version number based on the firmware file type, improving extraction accuracy. Furthermore, by identifying multiple first candidate strings matching the first string from the strings of various vulnerabilities in the vulnerability database, where the first candidate strings are the strings containing the second component name and version number corresponding to the vulnerability, a vulnerability summary is determined for each first candidate string. Based on the third component name and version number in the vulnerability summary, a first language model is used to determine the confidence level of each first candidate string. First candidate strings with a confidence level reaching a first threshold are designated as second strings, and the vulnerability associated with the second string is identified as a vulnerability in the firmware file. This allows for further filtering of first candidate strings based on confidence levels when extracting multiple first candidate strings, eliminating erroneous first candidate strings and retaining accurate ones, thereby improving the accuracy of identifying device firmware vulnerabilities. Attached Figure Description

[0050] Figure 1 This is an application environment diagram of a device firmware vulnerability detection method in one embodiment;

[0051] Figure 2 This is a flowchart illustrating a vulnerability detection method for device firmware in one embodiment;

[0052] Figure 3 This is a schematic diagram of the completed vulnerability database in one embodiment;

[0053] Figure 4 This is a schematic diagram of the vulnerability detection process for component files in one embodiment;

[0054] Figure 5 This is a schematic diagram of the vulnerability detection process for non-component files in one embodiment;

[0055] Figure 6 This is a schematic diagram of a portion of the logs in one embodiment;

[0056] Figure 7 This is a diagram illustrating how the component version number is found using the "grep -rn component_name" method in one embodiment.

[0057] Figure 8 This is a schematic diagram illustrating the process of querying a vulnerability database for N-day vulnerabilities in firmware in one embodiment.

[0058] Figure 9This is a structural block diagram of a device firmware vulnerability detection device in one embodiment;

[0059] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0061] The device firmware vulnerability detection method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 interacts with server 104 via a wired / wireless channel. A data storage system can store the data that server 104 needs to process. The process is as follows: S1. Obtain the device's firmware file. If the firmware file is a binary component file, obtain a first string containing the first component name and version number from the firmware file. S2. From the strings of each vulnerability in the vulnerability database, determine multiple first candidate strings that match the first string. The first candidate strings are strings containing the second component name and version number corresponding to the vulnerability. S3. Determine the vulnerability summary corresponding to each first candidate string, and based on the third component name and version number in the vulnerability summary, use a language model to determine the confidence level of each first candidate string. S4. Use the first candidate string with a confidence level reaching a first threshold as the second string, and determine the vulnerability to which the second string belongs as a vulnerability in the firmware file. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, etc. Server 104 can be a single server, a server cluster consisting of multiple servers, or a cloud computing center consisting of multiple servers.

[0062] In one embodiment, such as Figure 2 As shown, a method for detecting vulnerabilities in device firmware is provided, which can be applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0063] S1. Obtain the device's firmware file. If the firmware file is a component file in binary form, obtain the first string containing the first component name and the first component version number from the firmware file.

[0064] Firmware files are a set of specific software programs written into the read-only memory inside a hardware device. Firmware files provide the device with the lowest-level instructions and data required to complete hardware control and operation, and act as a "bridge" between the hardware and the operating system or application software.

[0065] Binary component files are the basic units that constitute the core functions and architecture of firmware. They are independent modules or code collections that have specific functions and can be called by the operating system or applications.

[0066] The first component version number refers to the component version number in the firmware file. Component version numbers are usually defined by the component developer, not the device manufacturer. The component version number is analogous to the version number of a small software component installed in a device or product, while the first component name is the name of that small software component. The first component version number generally exists within the range above and below the first component name. For example, during the reverse engineering of the component "busybox", the string "BusyBox v1.4.2(2018-12-12 03:35:45 CST)" was found, indicating that the first version number of the component "busybox" is "1.4.2".

[0067] The first string is a string containing the name and version number of the first component. Furthermore, the first string can be obtained from the firmware file using the command line "string{} grep -rn {}".

[0068] S2. From the strings of each vulnerability in the vulnerability database, determine multiple first candidate strings that match the first string; the first candidate strings are the strings of the second component name and the second component version number corresponding to the vulnerability;

[0069] The vulnerability database is pre-configured and includes a database of component names and version numbers corresponding to multiple vulnerabilities. The string representing each vulnerability is the string representing the name and version number of the corresponding second component. The vulnerabilities in the database specifically refer to N-day vulnerabilities, so the vulnerabilities identified in the firmware files are also N-day vulnerabilities.

[0070] The first candidate string can be determined using regular expressions. Specifically, the server performs regular expression matching between the string of each vulnerability in the vulnerability database and the first string, thereby finding multiple first candidate strings that match the first string.

[0071] S3. Determine the vulnerability summary corresponding to each first candidate string, and use the first language model to determine the confidence level of each first candidate string based on the third component name and third component version number in the vulnerability summary.

[0072] The vulnerability summary is a concise and general description of the vulnerability, designed to allow users to understand the core information of the vulnerability in the shortest possible time, such as: vulnerability type, affected component name, component version number, potential harm and severity level.

[0073] The vulnerability digest corresponding to the first candidate string is the vulnerability digest of the vulnerability to which the first candidate string belongs. For example, if the string of vulnerability A is string B, and the vulnerability digest of vulnerability A is vulnerability digest C, then when string B is the first candidate string, the vulnerability digest corresponding to the first candidate string is vulnerability digest C.

[0074] A first language model is a language model that can output the first candidate string with a confidence level reaching a first threshold. First language models include, but are not limited to, a trained LLM (Large Language Model).

[0075] When using a first language model to determine the confidence level of each first candidate string, the first candidate string is mainly input into the first language model for confidence level calculation.

[0076] Further, a preset fourth prompt word template is obtained. The fourth prompt word template and the first candidate string are input into the first language model. The first language model calculates the confidence level of each first candidate string based on the explicit mention of the third component name and version number in the vulnerability summary. Explicit mention refers to whether the third component name and version number in the vulnerability summary are complete or precise. If the vulnerability summary directly shows a complete match of component name + version number, the confidence level is 10; if it is only vaguely mentioned, such as "affects version 1.x", or not mentioned at all, the confidence level is reduced. The fourth prompt word template is used to enable the first language model to determine the confidence level of each first candidate string. The fourth prompt word template is shown in Table 1.

[0077]

[0078] S4. The first candidate string with a confidence level reaching the first threshold is taken as the second string, and the vulnerability to which the second string belongs is determined to be a vulnerability in the firmware file.

[0079] The first threshold is a pre-set data. For example, if the first threshold is 10, then only the first candidate string with a confidence level of 10 will be identified as the second string.

[0080] After the first language model determines the confidence level of each first candidate string, the output is the first candidate string whose confidence level reaches the first threshold. Therefore, when determining the second string, the output first candidate string can be directly determined as the second string without comparing the confidence level of each first candidate string with the first threshold.

[0081] The second string may be one or more. If the second string is multiple, it indicates that there are also multiple vulnerabilities in the device's firmware file.

[0082] The aforementioned device firmware vulnerability detection method obtains the device's firmware file. When the firmware file is a binary component file, it extracts the first string containing the first component name and version number. This allows for targeted extraction of the first string based on the firmware file type, improving extraction accuracy. Furthermore, it identifies multiple first candidate strings matching the first string from vulnerability strings in a vulnerability database. These first candidate strings are the second component name and version number corresponding to the vulnerability. A vulnerability summary is determined for each first candidate string. Based on the third component name and version number in the vulnerability summary, a first language model is used to determine the confidence level of each first candidate string. First candidate strings with a confidence level reaching a first threshold are designated as second strings, and the vulnerability associated with these second strings is identified as a vulnerability in the firmware file. This method allows for further filtering of first candidate strings based on confidence levels, eliminating erroneous first candidate strings and retaining accurate ones, thereby improving the accuracy of identifying device firmware vulnerabilities.

[0083] In one embodiment, the method for obtaining the first string in step S1 includes:

[0084] Convert the contents of the component file into a readable string, and obtain the preset component name string, component version number string, and first prompt word template;

[0085] Filter from readable strings to select multiple second candidate strings that match the component name string and the component version number string;

[0086] Based on the first prompt word template and multiple second candidate strings, the second language model is used to output the first string whose confidence level reaches the second threshold.

[0087] The first command is used to convert the contents of a component file into a readable string. For example, the `strings` command converts the contents of a firmware file into a readable string.

[0088] The second candidate strings can be obtained through filtering using a second command. This second command is used to search and match based on a preset component name string and component version number string. For example, the `grep -rn {}` command can be used to filter multiple second candidate strings from readable strings that match the preset component name string and component version number string.

[0089] The selected second candidate strings include not only the component name and version number, but also strings containing other information. For example, in the component "busybox", the strings "BusyBox v1.4.2 (2018-12-12 03:35:45 CST)" are matched. Besides the component name "busybox", these strings also include the component version number "1.4.2", the time information "2018-12-12 03:35:45 CST", "busybox", "1.4.2", "2018-12-12 03:35:45 CST", comments, paths, and irrelevant text. The time information, comments, paths, and irrelevant text strings constitute the other information strings.

[0090] The specific process of outputting the first string is as follows: input the first prompt word template and multiple second candidate strings into the second language model, use the second language model to calculate the confidence of each second candidate string, and output the string whose confidence reaches the second threshold as the first string. The format of the output first string is JSON (JavaScript Object Notation).

[0091] The first prompt word template is a prompt word used to extract the component name and component version number from each of the second candidate strings. The style of the first prompt word template is shown in Table 2. The second language model can be LLM. The first string is a string that includes the first component name and the first component version number.

[0092]

[0093] In this embodiment, the content of the component file is converted into a readable string, and a preset component name string, component version number string, and first prompt word template are obtained. Multiple second candidate strings that match the component name string and component version number string are filtered from the readable strings. Based on the first prompt word template and multiple second candidate strings, a second language model is used to output a first string with a confidence level reaching a second threshold. In this way, the powerful contextual understanding, semantic understanding, and confidence evaluation capabilities of the second language model can be utilized to accurately filter out the first string of the first component name and the first component version number from multiple second candidate strings, thereby improving the accuracy of the first string.

[0094] In one embodiment, the process of determining the second component name and second component version number corresponding to each vulnerability in the vulnerability database in step S2 includes:

[0095] Obtain the vulnerability database and check whether each vulnerability in the vulnerability data is associated with the name and version number of the second component.

[0096] When no component information is associated with the target vulnerability, a preset second prompt word template is obtained; the component information includes the second component name and the second component version number.

[0097] Based on the second prompt word template and the vulnerability summary of the target vulnerability, the third component name and third component version number in the vulnerability summary of the target vulnerability are output using a third language model;

[0098] The target vulnerability is a second component whose name is the name of the third component, and a second component whose version number is the version number of the third component.

[0099] The vulnerability database includes first vulnerabilities associated with a second component name and version number, and may also include second vulnerabilities not associated with any component information. Component information includes the second component name and version number.

[0100] A target vulnerability refers to a vulnerability that is not associated with the version number of the second component and the name of the second component.

[0101] The process of outputting the third component name and version number includes: inputting the second prompt word template and the vulnerability summary of the target vulnerability into the third language model, and outputting the third component name and version number from the vulnerability summary of the target vulnerability. The second prompt word template is used to extract the third component name and version number from the vulnerability summary. The second prompt word template is shown in Table 3. The second prompt word template in Table 3 first clarifies the task "analyze the provided vulnerability summary and extract the component name and component version number," then proposes specific constraints: "return the result in JSON object format, containing the following fields: 'software_name' and 'version'," "if the vulnerability summary contains the component name and version number, extract them according to the content in the vulnerability summary," "if no relevant information is found, return the corresponding field as 'n / a' (unavailable / no data available)," "ensure the JSON format is correct, and field names are enclosed in double quotes." Finally, an example output is given. This design of the second prompt word template breaks down the problem, giving the third language model a specific task, steps to complete the task, and an example output result, allowing the third language model to better understand the task requirements and achieve the expected results. The third language model can be an LLM.

[0102]

[0103] In some embodiments, if the target vulnerability is not associated with a second component name, the third component name in the vulnerability summary of the target vulnerability is output using a third language model, and the third component name is used as the second component name; if the target vulnerability is not associated with a second component version number, the third component version number in the vulnerability summary of the target vulnerability is output using a third language model, and the third component version number is used as the second component version number.

[0104] In a specific application, the downloaded vulnerability database is scanned, and the "product" and "version" entries associated with each vulnerability are checked for "n / a" (unavailable). If "n / a" is found in either the "product" or "version" entry, the vulnerability is identified as a target vulnerability. A query is constructed based on the second prompt word template and the vulnerability summary of the target vulnerability, and input into the LLM (Local Management Module) to obtain information. After receiving the LLM's response, the "software_name" and "version" entries are extracted, and the "product" and "version" entries are associated with the target vulnerability. The completed vulnerability database is as follows: Figure 3 As shown, from Figure 3 As can be seen, before information completion, the "product" and "version" of the target vulnerability were "n / a" (unavailable), while after information completion, "product" and "version" were completed as "Apache Struts" and "2.x before 2.3.28" respectively. This shows that the information completion effect of this application on vulnerability data is good.

[0105] In this embodiment, by acquiring a vulnerability database, it is detected whether each vulnerability in the vulnerability data is associated with a second component name and a second component version number. When the target vulnerability is not associated with component information, a preset second prompt word template is acquired. The component information consists of the second component name and the second component version number. Based on the second prompt word template and the vulnerability summary of the target vulnerability, a third language model is used to output the third component name and the third component version number in the vulnerability summary of the target vulnerability. The third component name is used as the second component name of the target vulnerability, and the third component version number is used as the second component version number of the target vulnerability. This can complete the component information for target vulnerabilities for which the vulnerability database is not associated with component information, thereby improving the accuracy of matching when determining multiple first candidate strings that match the first string from the strings of each vulnerability in the vulnerability database.

[0106] In one embodiment, the process of determining the second prompt word template includes:

[0107] Preset initial prompt word template;

[0108] Based on the initial prompt word template, the fourth language model is used to extract the fourth component name and the fourth component version number from the test set; the test set includes multiple vulnerability summaries, each of which includes the actual component name and the actual component version number;

[0109] If the name of the fourth component does not match the name of the actual component and / or the version number of the fourth component does not match the version number of the actual component, the initial prompt word template is modified until the name of the fourth component matches the name of the actual component and the version number of the fourth component matches the version number of the actual component, thus obtaining the second prompt word template.

[0110] The initial prompt word template is a template that has not yet been trained. After the initial prompt word template is trained, it can be used to extract the component name and component version number from the vulnerability summary. The initial prompt word template is shown in Table 4.

[0111]

[0112] The test set is a collection of vulnerability summaries used to adjust the initial warning word template. The actual component name and version number in each vulnerability summary within the test set are pre-known, real data.

[0113] The fourth component name and fourth component version number are the extraction results output by the fourth language model under the current initial prompt word template. The matching results between the fourth component name and the actual component name, and between the fourth component version number and the actual component version number, can be obtained through string matching, similarity algorithm calculation, or regular expression matching. Specifically, the strings of the fourth component name and the actual component name in the same vulnerability summary are compared for consistency. If they match, the fourth component name and the actual component name match. Similarly, the strings of the fourth component version number and the actual component version number in the same vulnerability summary are compared for consistency. If they match, the fourth component version number and the actual component version number match. The similarity between the fourth component name and the actual component name in the same vulnerability summary is calculated, and the similarity between the fourth component version number and the actual component version number in the same vulnerability summary is calculated. If the similarity is greater than a third threshold, a match is found. Finally, regular expressions are used to determine whether the fourth component name and the actual component name in the same vulnerability summary match, and whether the fourth component version number in the same vulnerability summary matches.

[0114] Scenarios for modifying the initial prompt word template include: the fourth component name and the actual component name of any vulnerability summary do not match; the fourth component version number and the actual component version number of any vulnerability summary do not match; and the fourth component version number and the actual component version number of any vulnerability summary do not match, and the fourth component name and the actual component name do not match.

[0115] When modifying the initial prompt template, adjustments will be made based on the extracted fourth component name and version number. For example, if the fourth language model outputs a functional description instead of a component version number, it indicates that the fourth language model misunderstands the meaning of "component name and version number." In this case, a definition can be added to the initial prompt template: the component version number should be in numeric format, such as 1.2.3 or v1.2.3, rather than a functional description.

[0116] In a specific application, this application first presets an initial prompt word template as shown in Table 3, and constructs a test set containing 100 vulnerability summaries to test the initial prompt word template. Combining the test set and the initial prompt word template, questions are posed to the fourth language model to check whether the name of the fourth component output by the fourth language model matches the actual component name and whether the version number of the fourth component matches the actual component version number. This verifies whether the initial prompt word template has problems such as unclear tasks or incomplete descriptions. If the name of the fourth component does not match the actual component name and / or the version number does not match the actual component version number, the initial prompt word template is modified until the name of the fourth component matches the actual component name and the version number matches the actual component version number, resulting in a second prompt word template as shown in Table 2.

[0117] In this embodiment, when the name of the fourth component and the actual component name do not match and / or the version number of the fourth component does not match the version number of the actual component, the initial prompt word template is modified until the name of the fourth component and the actual component name and the version number of the fourth component match, thus obtaining the second prompt word template. This allows the final second prompt word template to more accurately describe the extraction task, enabling the third language model to output the accurate name of the third component and the version number of the third component based on the second prompt word template and the vulnerability summary of the target vulnerability.

[0118] In one embodiment, the method further includes:

[0119] When the firmware file is a non-component file in text format, the text content in the firmware file is converted into a third string, and the third prompt word template is obtained;

[0120] Based on the third string and the third prompt word template, the fifth language model is used to output the fourth string containing the firmware name and firmware version number from the third string;

[0121] From the strings of each vulnerability in the vulnerability database, identify multiple third candidate strings that match the fourth string;

[0122] The third candidate string is filtered based on preset filtering conditions to obtain the fifth string, and the vulnerability to which the fifth string belongs is identified as a vulnerability in the firmware file.

[0123] Non-component files in text format are not modules that directly participate in firmware function execution in binary code form, but they play an important auxiliary role in firmware operation and management. Non-component files mainly refer to the device's firmware upgrade files and configuration files. Firmware upgrade files are used to update the device's internal low-level software to fix vulnerabilities, improve performance, or add new features. Configuration files are used to set device operating parameters; they do not contain program code, only the parameters and options required for device operation. The firmware name and firmware version number are mainly found in firmware upgrade files and configuration files. Furthermore, firmware upgrade files can be identified based on the firmware file's file extension, file structure, file name, or file size. Similarly, configuration files can be identified based on the firmware file's file extension, file structure, file size, or text content within the firmware file.

[0124] The text content in the firmware file can be converted into a third-party string using the "strings" command.

[0125] The third prompt word template is used to extract the fourth string, which includes the firmware name and firmware version number, from the third string. The output fourth string can be in JSON format. The third prompt word templates are shown in Table 5. The output string is the third string.

[0126]

[0127] The process of using the fifth language model to output the fourth string, which contains the firmware name and firmware version number from the third string, is as follows: The third string and the third prompt word template are input into the fifth language model. Based on the third prompt word template, the fifth language model analyzes and outputs the fourth string, which contains the firmware name and firmware version number from the third string. The fourth string can be output in JSON format, and the fifth language model can be an LLM (Local Language Model).

[0128] The vulnerability string is a string that includes the firmware name and firmware version number associated with the vulnerability.

[0129] The third candidate string can be obtained using regular expressions. Specifically, the fourth string is input into the vulnerability database, a regular expression is used to search for it, and multiple third candidate strings that match the fourth string are output. Each third candidate string corresponds to a vulnerability.

[0130] The fifth string is the string that meets the filtering criteria from the third candidate strings. The vulnerability to which the fifth string belongs is the vulnerability corresponding to the fifth string in the vulnerability database. For example, if the fifth string corresponds to vulnerability A in the vulnerability database, then the vulnerability to which the fifth string belongs is vulnerability A, and vulnerability A is a vulnerability in the firmware file.

[0131] In this embodiment, when the firmware file is a non-component file in text format, the text content in the firmware file is converted into a third string, and a third prompt word template is obtained. Based on the third string and the third prompt word template, a fourth string containing the firmware name and firmware version number from the third string is output using a fifth language model. This leverages the powerful semantic understanding of the fifth language model to accurately extract the fourth string containing the firmware name and firmware version number from the third string. By identifying multiple third candidate strings that match the fourth string from the strings of various vulnerabilities in the vulnerability database, and filtering the third candidate strings based on preset filtering conditions, a fifth string is obtained. The vulnerability to which the fifth string belongs is then identified as a vulnerability in the firmware file. This dual filtering mechanism achieves accurate filtering of the fifth string, reduces the error rate, and improves the accuracy of firmware file vulnerability identification.

[0132] In one embodiment, the third candidate string is filtered based on preset filtering conditions to obtain the fifth string, including:

[0133] If the third candidate string is the same as the fourth string, then the third candidate string is the fifth string;

[0134] If the set of firmware version numbers in the third candidate string includes firmware version numbers, and the firmware name in the third candidate string is the same as the firmware name in the fourth string, then the third candidate string is the fifth string;

[0135] If the type of the affected device of the vulnerability to which the third candidate string belongs matches the type of firmware, then the third candidate string is the fifth string.

[0136] The fact that the third candidate string and the fourth string are the same indicates that the firmware name extracted from the firmware file is the same as the firmware name contained in the third candidate string, and the firmware version number extracted from the firmware file is the same as the firmware version number contained in the third candidate string.

[0137] A firmware version number range is not a single version number, but rather a set of all version numbers from one version number to another. For example, if the firmware version number range is v1.0 to v1.5, and the firmware version number in the fourth string is within the firmware version number range v1.0 to v1.5, and the firmware name in the third candidate string is the same as the firmware name in the fourth string, then the third candidate string is the fifth string.

[0138] The affected device type refers to the type of device affected by the vulnerability. For example, if the device is a router, but the vulnerability to which the third candidate string belongs can affect a Windows driver, then the third candidate string is not the fifth string.

[0139] In some embodiments, vulnerabilities with vague vulnerability summaries or those that do not mention firmware are excluded. For example, if a vulnerability's summary only states "affects a certain device" without specifying the brand, then the third candidate string for that vulnerability is not the fifth string.

[0140] In this embodiment, the third candidate string is determined to be the fifth string when it matches the fourth string. The third candidate string is also determined to be the fifth string when the firmware version number range in the third candidate string includes the firmware version number and the firmware name in the third candidate string matches the firmware name in the fourth string. The third candidate string is also determined to be the fifth string when the type of vulnerability to which it belongs matches the type of firmware. This can eliminate some vulnerabilities that are obviously not firmware vulnerabilities.

[0141] In one embodiment, the method further includes:

[0142] Preset keyword database and file extension database; the keyword database includes multiple preset first keywords, and the file extension database includes multiple preset first file extensions;

[0143] When the second keyword in the firmware file matches any of the first keywords, or when the second file extension of the firmware file matches any of the first file extensions, the firmware file is determined to be a non-component file in text form.

[0144] In this embodiment, when the second keyword in the firmware file matches any of the first keywords, or when the second file extension of the firmware file matches any of the first file extensions, the firmware file is determined to be a non-component file in text form. This enables rapid identification of non-component files in the firmware file.

[0145] This application also provides an application scenario in which the above-described device firmware vulnerability detection method is applied. Specifically, the application of the device firmware vulnerability detection method in this scenario is as follows:

[0146] For component files, the command "string{} grep -rn {}" is first used to collect multiple second candidate strings containing the component name and version number. A first prompt word template is obtained, and the first prompt word template and multiple second candidate strings are input into a second language model for initial filtering. Based on confidence levels, a first string with a confidence level reaching a second threshold is selected. This first string includes the first component name and the first component version number, and is output in JSON format. Then, a search is performed in the vulnerability database to identify multiple first candidate strings that match the first string. Finally, these multiple first candidate strings are input into the first language model for secondary filtering. The first language model assigns a confidence level based on the third component name and the third component version number in the vulnerability summary. The first candidate strings with confidence levels reaching the first threshold are designated as second strings, and the vulnerability associated with the second string is identified as a vulnerability in the firmware file. This information is returned in JSON format. The specific process is as follows: Figure 4 As shown. For non-component files, the "strings" command is used to adjust the text content in the firmware file into a third string. This third string and the third prompt word template are then input into the fifth language model. The fifth language model analyzes the data and outputs a fourth string (containing the firmware name and version number) in JSON format. This fourth string is then input into a vulnerability database for regular expression searching, outputting multiple third candidate strings that match the fourth string. Finally, filtering conditions are used to filter these third candidate strings, eliminating vulnerabilities that are clearly not firmware vulnerabilities. The specific process is as follows: Figure 5 As shown.

[0147] In a specific application, the steps for performing vulnerability detection on the device firmware are as follows:

[0148] (1) Vulnerability database completion:

[0149] If the vulnerability summary is "Apache Tomcat 9.0.76 has a remote code execution vulnerability, which attackers can exploit to execute arbitrary code on the target system," then the vulnerability database completion method in this application can yield the following results: the component name "Apache Tomcat" and the component version number "9.0.76," which can then be filled into the corresponding fields in the vulnerability database. A partial log obtained by completing the entire vulnerability database is shown below. Figure 6 As shown.

[0150] (2) Identification of N-day vulnerabilities in component files:

[0151] Using the component name as an index, use the command "grep -rn component_name" to find the component version number, such as... Figure 7 As shown, for the component "libcurl", the component version number is found to be "7.63.0", and then the N-day vulnerability "CVE-2018-16890", "CVE-2019-3822", "CVE-2019-5435" and "CVE-2021-22890" are found in the vulnerability database; for the component "bzip2", the component version number is found to be "1.0.0", and then the N-day vulnerability "CVE-2018-8008" is found in the vulnerability database; for the component "pppd", the component version number is found to be "2.4.7", and then the N-day vulnerability "CVE-2020-8597" is found in the vulnerability database; for the component "busybox", the component version number is found to be "3.29.3", and then the N-day vulnerability "CVE-2021-28831" is found in the vulnerability database.

[0152] (3) Identification of N-day vulnerabilities in non-component files:

[0153] First, extract files whose filenames contain keywords from the firmware files. Then, use the "strings" command to convert these files into strings and input them into the fifth language model. Design a third prompt word template for the fifth language model to analyze and output the firmware name and firmware version number in JSON format. The fifth language model recognizes the string "TOTOLINK A3300R" as the firmware name and finds the firmware version number "v17.0.0cu" before and after this string. Then, it searches the vulnerability database and finds an N-day vulnerability in this firmware. The specific results are as follows. Figure 8 As shown.

[0154] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0155] Based on the same inventive concept, this application also provides a device for detecting device firmware vulnerabilities to implement the aforementioned device firmware vulnerability detection method. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations in one or more device firmware vulnerability detection device embodiments provided below can be found in the limitations of the device firmware vulnerability detection method described above, and will not be repeated here.

[0156] In one embodiment, such as Figure 9 As shown, a device firmware vulnerability detection apparatus is provided, comprising:

[0157] The first string acquisition module is used to acquire the firmware file of the device. When the firmware file is a component file in binary form, it acquires a first string containing the first component name and the first component version number from the firmware file.

[0158] The matching module is used to determine multiple first candidate strings that match the first string from the strings of each vulnerability in the vulnerability database; the first candidate strings are strings of the second component name and the second component version number corresponding to the vulnerability.

[0159] The confidence calculation module is used to determine the vulnerability digest corresponding to each of the first candidate strings, and to determine the confidence of each of the first candidate strings based on the third component name and third component version number in the vulnerability digest using a first language model.

[0160] The vulnerability determination module is used to determine the vulnerability of the firmware file by taking the first candidate string with a confidence level reaching a first threshold as the second string.

[0161] The various modules in the aforementioned device firmware vulnerability detection device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0162] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10As shown. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores firmware files, a first string, a vulnerability database, first candidate strings, confidence levels for each of the first candidate strings, a first threshold, and a second string. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a method for detecting vulnerabilities in device firmware.

[0163] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0164] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0165] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0166] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0167] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0168] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0169] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for detecting vulnerabilities in device firmware, characterized in that, The method includes: S1. Obtain the device's firmware file. When the firmware file is a component file in binary form, obtain a first string containing the first component name and the first component version number from the firmware file. S2. From the strings of each vulnerability in the vulnerability database, determine a plurality of first candidate strings that match the first string; the first candidate strings are the strings of the second component name and the second component version number corresponding to the vulnerability; S3. Determine the vulnerability summary corresponding to each of the first candidate strings, and use the first language model to determine the confidence level of each of the first candidate strings based on the third component name and third component version number in the vulnerability summary. S4. Using the first candidate string whose confidence level reaches the first threshold as the second string, the vulnerability to which the second string belongs is determined to be a vulnerability in the firmware file; The methods for obtaining the first string in step S1 include: The contents of the component file are converted into readable strings, and the preset component name string, component version number string, and first prompt word template are obtained; Filter from the readable string to select multiple second candidate strings that match the component name string and the component version number string; Based on the first prompt word template and multiple second candidate strings, the second language model is used to output the first string whose confidence reaches the second threshold. The process of determining the name and version number of the second component corresponding to each vulnerability in the vulnerability database in step S2 includes: Obtain the vulnerability database and check whether each vulnerability in the vulnerability database is associated with the name of the second component and the version number of the second component; When no component information is associated with the target vulnerability, a preset second prompt word template is obtained; the component information is the name of the second component and the version number of the second component. Based on the second prompt word template and the vulnerability summary of the target vulnerability, the third component name and the third component version number in the vulnerability summary of the target vulnerability are output using a third language model; The name of the third component is used as the name of the second component of the target vulnerability, and the version number of the third component is used as the version number of the second component of the target vulnerability.

2. The method according to claim 1, characterized in that, The process of determining the second prompt word template includes: Preset initial prompt word template; Based on the initial prompt word template, the fourth component name and fourth component version number are extracted from the test set using the fourth language model; the test set includes multiple vulnerability summaries, each of which includes the actual component name and the actual component version number; When the name of the fourth component does not match the name of the actual component and / or the version number of the fourth component does not match the version number of the actual component, the initial prompt word template is modified until the name of the fourth component matches the name of the actual component and the version number of the fourth component matches the version number of the actual component, thus obtaining the second prompt word template.

3. The method according to claim 2, characterized in that, The method further includes: When the firmware file is a non-component file in text form, the text content in the firmware file is converted into a third string, and a third prompt word template is obtained; Based on the third string and the third prompt word template, the fifth language model is used to output the fourth string containing the firmware name and firmware version number in the third string; From the strings of each vulnerability in the vulnerability database, determine multiple third candidate strings that match the fourth string; The third candidate string is filtered based on preset filtering conditions to obtain the fifth string, and the vulnerability to which the fifth string belongs is identified as a vulnerability in the firmware file.

4. The method according to claim 3, characterized in that, The fifth string is obtained by filtering the third candidate string based on preset filtering conditions, including: If the third candidate string is the same as the fourth string, then the third candidate string is the fifth string; If the firmware version number range in the third candidate string includes the firmware version number, and the firmware name in the third candidate string is the same as the firmware name in the fourth string, then the third candidate string is the fifth string; If the type of the device affected by the vulnerability to which the third candidate string belongs matches the type of the firmware, then the third candidate string is the fifth string.

5. The method according to claim 3, characterized in that, The method further includes: A preset keyword database and a file extension database; the keyword database includes multiple preset first keywords, and the file extension database includes multiple preset first file extensions; When the second keyword in the firmware file matches any of the first keywords, or when the second file extension of the firmware file matches any of the first file extensions, the firmware file is determined to be a non-component file in text form.

6. A device firmware vulnerability detection apparatus, used to perform the method according to any one of claims 1-5, characterized in that, The device includes: The first string acquisition module is used to acquire the firmware file of the device. When the firmware file is a component file in binary form, it acquires a first string containing the first component name and the first component version number from the firmware file. The matching module is used to determine multiple first candidate strings that match the first string from the strings of each vulnerability in the vulnerability database; the first candidate strings are strings of the second component name and the second component version number corresponding to the vulnerability. The confidence calculation module is used to determine the vulnerability digest corresponding to each of the first candidate strings, and to determine the confidence of each of the first candidate strings based on the third component name and third component version number in the vulnerability digest using a first language model. The vulnerability determination module is used to determine the vulnerability of the firmware file by taking the first candidate string with a confidence level reaching a first threshold as the second string.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 5.

Images