Device component vulnerability verification method and device, and electronic device

Abstract

The application discloses a vulnerability verification method and device for a device component and electronic equipment, and the method comprises the following steps: collecting component information of at least one associated component of a first device, and concept verification information associated with a vulnerability of the associated component; generating corresponding concept verification data sets based on the component information and the concept verification information of the associated component; determining the component information of a first component currently associated with the first device based on firmware information of the first device, wherein the first component corresponds to the associated component; performing concept verification on the component information of the first component to generate a first verification result; and comparing the first verification result with the concept verification data sets to determine whether there is a vulnerability in the first component. The method can conveniently verify the associated components associated with the terminal device related to the Internet of Things, thereby accurately detecting whether the associated components have vulnerabilities, reducing the false positive rate, and improving the detection efficiency.

Description

Technical Field

[0001] This application relates to the field of information security, and in particular to a method, apparatus and electronic device for vulnerability verification of device components. Background Technology

[0002] With the advent of the Internet of Things (IoT) era, IoT-related terminal devices, such as IoT devices, have been rapidly applied and developed. However, this development has also brought widespread security risks to IoT devices. Currently, most IoT-related IoT devices exhibit a clear trend towards fragmentation and distribution, making it difficult to unify security requirements and standards, and lacking unified management methods. Therefore, vulnerability analysis and assessment related to IoT firmware are challenging. For example, to save development costs and improve efficiency, IoT device firmware developers may allow IoT devices to directly call unverified third-party components, without considering whether these components contain vulnerabilities. This makes these vulnerabilities easily exploitable by attackers, leading to losses. Summary of the Invention

[0003] The purpose of this application is to provide a method, apparatus, and electronic device for vulnerability verification of device components. This method can conveniently examine associated components of IoT-related terminal devices, thereby accurately detecting whether there are vulnerabilities in the associated components, reducing false alarm rates, and improving detection efficiency.

[0004] To achieve the above objectives, this application provides a vulnerability verification method for device components, comprising:

[0005] Collect component information of at least one associated component of the first device, as well as proof-of-concept information associated with vulnerabilities of the associated component;

[0006] Based on the component information of the associated components and the proof-of-concept information, a corresponding proof-of-concept dataset is generated;

[0007] Based on the firmware information of the first device, determine the component information of the first component currently associated with the first device, wherein the first component corresponds to the associated component;

[0008] Perform a proof-of-concept analysis on the component information of the first component to generate a first verification result;

[0009] The first verification result is compared with the proof-of-concept dataset to determine whether there are any vulnerabilities in the first component.

[0010] Optionally, the step of generating a corresponding proof-of-concept dataset based on the component information of the associated components and the proof-of-concept information includes:

[0011] The component information of the associated components is used as the index of the proof-of-concept dataset;

[0012] Perform the proof of concept on the associated component containing the vulnerability to generate a second verification result;

[0013] Based on the traffic response information and log information in the second verification result, the proof-of-concept dataset is generated.

[0014] Optionally, determining the component information of the first component currently associated with the first device based on the firmware information of the first device includes:

[0015] The firmware information is decomposed to obtain the binary file of the firmware of the first device;

[0016] Based on the binary file, the import method of the first component is determined, wherein the import method includes static link import and dynamic link import;

[0017] Based on the aforementioned introduction method, a corresponding analysis method is adopted to determine the component information of the first component.

[0018] Optionally, based on the introduction method, the determination of the component information of the first component using an adapted analysis method includes:

[0019] If it is determined that the first component is introduced via dynamic linking, the header file of the first component is obtained;

[0020] Compare the header file of the first component with the header file of the associated component;

[0021] Based on the comparison results, determine the component information of the first component; or,

[0022] Obtain a specific data table from the firmware of the first device;

[0023] Based on the library name loaded in the specific data table, the component information of the first component is determined.

[0024] Optionally, based on the introduction method, the determination of the component information of the first component using an adapted analysis method includes:

[0025] If it is determined that the first component is introduced by static link, the component name string in the first component is used as the taint source, and the flow function of the component name of the first component is used as the taint convergence point.

[0026] The component name and / or version string of the first component are determined by taint tracing.

[0027] Optionally, performing a proof-of-concept on the component information of the first component to generate a first verification result specifically includes:

[0028] The component information of the first component is compared with the component information of the associated components collected.

[0029] If the degree of matching between the component information of the first component and the component information of the associated component satisfies the first condition, a proof-of-concept is performed on the component information of the first component based on the version string of the first component.

[0030] Optionally, comparing the first verification result with the proof-of-concept dataset to determine whether a vulnerability exists in the first component includes:

[0031] The traffic response information and log information in the first verification information are compared with the corresponding content in the first verification result to determine whether there is a vulnerability in the first component.

[0032] This application also provides a vulnerability verification device for a device component, including:

[0033] A collection module is configured to collect component information of at least one associated component of the first device, as well as proof-of-concept information associated with vulnerabilities of the associated component;

[0034] Based on the component information of the associated components and the proof-of-concept information, a corresponding proof-of-concept dataset is generated;

[0035] An analysis module is configured to determine component information of a first component currently associated with the first device based on the firmware information of the first device, wherein the first component corresponds to the associated component;

[0036] The verification module is configured to perform a proof-of-concept on the component information of the first component and generate a first verification result;

[0037] The feedback module is configured to compare the first verification result with the proof-of-concept dataset to determine whether there is a vulnerability in the first component.

[0038] This application also provides an electronic device, including: a memory and a processor, wherein the memory stores an executable program, and the processor executes the executable program to implement the steps of the method described above.

[0039] This application also provides a storage medium carrying one or more computer programs, which, when executed by a processor, implement the steps of the method described above.

[0040] The vulnerability verification method of this application embodiment can conveniently examine the associated components of IoT-related terminal devices, thereby accurately detecting whether there are vulnerabilities in the associated components, reducing the false alarm rate and improving detection efficiency. Attached Figure Description

[0041] Figure 1 This is a flowchart of a vulnerability verification method for device components according to an embodiment of this application;

[0042] Figure 2 Examples of embodiments of this application Figure 1 A flowchart of one embodiment of step S200;

[0043] Figure 3 Examples of embodiments of this application Figure 1 A flowchart of one embodiment of step S300;

[0044] Figure 4 Examples of embodiments of this application Figure 3 A flowchart of an embodiment of step S330;

[0045] Figure 5 Examples of embodiments of this application Figure 3 A flowchart of another embodiment of step S330;

[0046] Figure 6 Examples of embodiments of this application Figure 3 A flowchart of another embodiment of step S330;

[0047] Figure 7 Examples of embodiments of this application Figure 1 A flowchart of one embodiment of step S400;

[0048] Figure 8 This is a schematic diagram illustrating the process of determining the component information of the first component based on a binary file, according to an embodiment of this application.

[0049] Figure 9 This is a structural block diagram of a vulnerability verification device for a device component according to an embodiment of this application;

[0050] Figure 10 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0051] Various embodiments and features of this application are described herein with reference to the accompanying drawings.

[0052] It should be understood that various modifications can be made to the embodiments described herein. Therefore, the above description should not be considered as limiting, but merely as an example of embodiments. Other modifications within the scope and spirit of this application will be apparent to those skilled in the art.

[0053] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the present application and, together with the general description of the present application given above and the detailed description of the embodiments given below, serve to explain the principles of the present application.

[0054] These and other features of this application will become apparent from the following description of preferred forms of embodiments given as non-limiting examples, with reference to the accompanying drawings.

[0055] It should also be understood that although this application has been described with reference to some specific examples, those skilled in the art can certainly implement many other equivalent forms of this application.

[0056] The above and other aspects, features and advantages of this application will become more apparent when taken in conjunction with the accompanying drawings and in view of the following detailed description.

[0057] Specific embodiments of this application are described thereafter with reference to the accompanying drawings; however, it should be understood that the claimed embodiments are merely examples of this application, which can be implemented in various ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that could obscure the application. Therefore, the specific structural and functional details claimed herein are not intended to be limiting, but merely serve as the basis and representative basis for the claims to teach those skilled in the art to use this application in a variety of substantially any suitable detailed structures.

[0058] This specification may use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in other embodiments,” all of which may refer to one or more of the same or different embodiments according to this application.

[0059] This application provides a vulnerability verification method for device-associated components. This method can identify and verify vulnerabilities in third-party components associated with a target device. The target device can be an Internet of Things (IoT) related device, such as an IoT device. The third-party component can be a component directly invoked by the IoT device to implement corresponding functions.

[0060] Figure 1 This is a flowchart of a vulnerability verification method for device components according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0061] S100, collect component information of at least one associated component of the first device, as well as proof-of-concept information associated with vulnerabilities of the associated component.

[0062] For example, the first device can be an IoT device used in the Internet of Things (IoT). This first device can be associated with one or more associated components. These associated components are third-party components different from the first device itself, and each associated component has its own function. After being associated with an associated component, the first device can possess the corresponding function. In one embodiment, any component that can be associated with the first device can be considered an associated component. Therefore, the associated components of the first device can be one or more different components.

[0063] The associated component has component information, which may include the component name, version number, and log file information. This component information can be collected based on historical data, the target database, and / or specific identifiers within the associated component.

[0064] For example, collect deb packages, rpm packages, and tar packages from the source websites that distribute Linux software, extract the names and version numbers of associated components, and generate the corresponding component information.

[0065] The proof-of-concept information associated with the vulnerability of the associated component can be a proof of concept (POC) information. The content of the POC information can prove the functionality and / or performance of the first device, and of course it is also associated with relevant information about the vulnerability. For example, the proof-of-concept information can include vulnerability verification code and / or attack examples targeting the vulnerability.

[0066] In this embodiment, proof-of-concept information associated with vulnerabilities in related components can be collected based on historical data, target databases, and / or specific identifiers in related components. For example, a POC dataset can be collected from open-source POC communities and websites associated with vulnerabilities, such as https: / / www.exploit-db.com / and https: / / packetstormsecurity.com / . POC operations are then performed on related components containing the vulnerable versions, and corresponding proof-of-concept information is collected. For example, traffic response information and log information from the POC execution results are collected and analyzed to establish a set of key strings for the POC verification results.

[0067] S200, Based on the component information of the associated components and the proof-of-concept information, generate a corresponding proof-of-concept dataset.

[0068] For example, component information can be associated with proof-of-concept information, thereby associating each sub-information within the component information with the proof-of-concept information, and generating a proof-of-concept dataset based on all associated proof-of-concept information. The proof-of-concept dataset includes content related to vulnerability verification.

[0069] Continuing with the above embodiments, for example, traffic response information and log information of POC execution results are collected and analyzed to establish a set of key strings for POC verification results, forming multiple proof-of-concept information. The multiple proof-of-concept information are combined with component information such as component name, version number and log file of associated components to generate a corresponding proof-of-concept dataset.

[0070] In one embodiment, the vulnerability-related information represented in the proof-of-concept dataset can be verified to determine the correctness of the data.

[0071] S300, based on the firmware information of the first device, determine the component information of the first component currently associated with the first device, wherein the first component corresponds to the associated component.

[0072] For example, firmware is a program written into the EPROM or EEPROM of the first device. Firmware refers to the device "driver" stored inside the device, which is the software that performs the underlying work of a system. Through firmware, specific machine operations can be implemented according to standard device drivers; for example, optical drives and CD burners all have internal firmware.

[0073] The firmware information in this application refers to the program or information stored in the firmware of the first device. The firmware information records relevant information about the components associated with the first device, and these components may also be loaded into the firmware.

[0074] In this embodiment, the first device can be associated with different components at different times. The component currently associated with the first device can be identified as the first component, which can be one of the associated components. After identifying the first component, its component information can then be determined.

[0075] S400, Perform a proof-of-concept on the component information of the first component and generate a first verification result.

[0076] For example, performing a proof-of-concept on the component information of the first component can refer to generating corresponding vulnerability verification code and / or attack examples targeting the vulnerability based on the component information. For instance, generating corresponding vulnerability verification code and / or attack examples targeting the vulnerability based on the version string of the first component forms a first verification result. The first verification result includes relevant information about the vulnerability corresponding to the first component. Based on this first verification result, it can be determined whether the first component contains a vulnerability.

[0077] S500, compare the first verification result with the proof-of-concept dataset to determine whether there is a vulnerability in the first component.

[0078] For example, a proof-of-concept dataset includes data related to vulnerabilities in associated components, as well as component information such as component name, version number, and log files. This vulnerability-related data can be correlated with the component information, and based on this information, related information can be obtained.

[0079] In this embodiment, the first verification result can be compared one by one with all corresponding data in the proof-of-concept dataset. For example, the first verification result includes unverified vulnerability information that the first component may have, such as unverified vulnerability verification code generated for the first vulnerability and unverified attack examples generated for the first vulnerability. This unverified vulnerability information can be compared with the vulnerability-related data contained in the proof-of-concept dataset. If the unverified vulnerability information matches successfully in the proof-of-concept dataset, it is determined that a vulnerability exists, indicating that the first component currently used by the first device has a vulnerability.

[0080] The vulnerability verification method of this application embodiment can conveniently examine the associated components of IoT-related terminal devices, thereby accurately detecting whether there are vulnerabilities in the associated components, reducing the false alarm rate and improving detection efficiency.

[0081] In one embodiment of this application, the generation of a corresponding proof-of-concept dataset is based on the component information of the associated components and the proof-of-concept information, such as... Figure 2 As shown, it includes:

[0082] S210, the component information of the associated component is used as the index of the proof-of-concept dataset.

[0083] For example, using component information as an index for a proof-of-concept dataset allows for querying, associating, and managing specific content within the dataset based on that component information. For instance, using the component name as an index allows for querying, associating, and managing content within the proof-of-concept dataset corresponding to that associated component.

[0084] S220, Perform the proof of concept on the associated component containing the vulnerability to generate a second verification result.

[0085] For example, the associated components can be multiple components related to the first device. The first device can use various different associated components to achieve corresponding functions. A vulnerability is identified in one of the associated components, and this vulnerability has relevant characteristics. In this embodiment, a proof-of-concept operation can be performed on the associated components, thereby generating corresponding vulnerability verification code and / or attack examples targeting the vulnerability. Based on the vulnerability verification code and / or attack examples targeting the vulnerability, traffic response information can be generated, which records the POC verification results for the vulnerability. Then, based on the traffic response information and log information, a second verification result can be generated. The second verification result contains relevant content characterizing the vulnerability's features.

[0086] S230, Based on the traffic response information and log information in the second verification result, the proof-of-concept dataset is generated.

[0087] For example, the traffic response information records the verification results of the vulnerability proof-of-concept (POC), while the log information shows the entire proof-of-concept process. Therefore, based on the traffic response information and log information, a proof-of-concept dataset can be accurately and comprehensively generated, enhancing the logical coherence of various vulnerability-related data within the dataset and ensuring that all data accurately expresses its meaning.

[0088] In one embodiment of this application, the step of determining the component information of the first component currently associated with the first device based on the firmware information of the first device is as follows: Figure 3 As shown, it includes:

[0089] S310, the firmware information is decomposed to obtain the binary file of the firmware of the first device.

[0090] For example, decomposing firmware information can identify the first component. Therefore, in this embodiment, firmware information can be decomposed, including unpacking the firmware information to obtain a binary file of the firmware. This binary file can be used for analysis to determine the specific content within the firmware information.

[0091] S320, based on the binary file, determine the import method of the first component, wherein the import method includes static link import and dynamic link import.

[0092] For example, the first device can be associated with the first component through an import method. Specifically, the firmware of the first device can include two import methods when importing the first component: static linking and dynamic linking. Static linking is a linking method that completes all symbol references before loading the first component. Dynamic linking postpones the relocation of symbols until the first component runs.

[0093] In this embodiment, the binary file can be analyzed to determine its contents, including a description of how the first component is introduced. Therefore, the method by which the first component is introduced into the first device can be determined based on the specific contents of the binary file.

[0094] S330, based on the aforementioned introduction method, an appropriate analysis method is adopted to determine the component information of the first component.

[0095] For example, different import methods correspond to their respective analysis methods, so as to accurately analyze the component information of the first component according to the logic of the import method. For example, for static link imports, the first analysis method can be used to analyze firmware information and other content related to component information to determine the component information. For dynamic link imports, the second analysis method can be used to analyze firmware information and other content related to component information to determine the component information.

[0096] Furthermore, based on the aforementioned introduction method, a suitable analysis method is adopted to determine the component information of the first component, such as... Figure 4 as well as Figure 5 As shown, and in combination Figure 8 This includes the following steps:

[0097] S331, if it is determined that the first component is introduced by dynamic linking, obtain the header file of the first component;

[0098] S332, compare the header file of the first component with the header file of the associated component;

[0099] S333, Based on the comparison results, determine the component information of the first component; or,

[0100] S334, Obtain a specific data table from the firmware of the first device;

[0101] S335, Based on the library name loaded in the specific data table, determine the component information of the first component.

[0102] For example, if it is determined that the first component is introduced into the first device (the firmware introduced into the first device) via dynamic linking, a dynamic linking tool can be used to extract the ELF file header of the IoT dynamic linking component and compare it with the ELF file headers of components collected in the proof-of-concept dataset, or analyze the import directory table (i.e., a specific data table) in the decomposed IoT firmware that records the names of the loaded libraries. These two methods can be used to confirm the component information of the first component (third-party component) referenced by the dynamic linking of the IoT firmware.

[0103] Furthermore, based on the aforementioned introduction method, a suitable analysis method is adopted to determine the component information of the first component, such as... Figure 6 As shown and combined Figure 8 This includes the following steps:

[0104] S336, if it is determined that the first component is introduced by static link, the component name string in the first component is used as the taint source, and the flow function of the component name of the first component is used as the taint convergence point.

[0105] S337, determine the component name and / or version string of the first component through taint tracing.

[0106] For example, when the first component is introduced by static linking, there is no intuitive way to directly determine the component information of the first component referenced by the firmware of the first device. In this embodiment, the component name string is obtained by taint tracking.

[0107] Stain analysis can be performed using a triplet.<sources,sinks,sanitizers> Let's use an abstract representation. Here, "source" represents the taint source, indicating that untrusted data can be directly introduced into the program from external input; "sink" represents the taint sink, indicating sensitive operations; and "sanitizer" represents the process of neutralizing taints. Taint analysis is the process of analyzing how data introduced from taint sources flows into the sink step by step and whether it undergoes neutralization.

[0108] In the first device, sensitive data such as usernames and passwords are usually encrypted to prevent leakage. Therefore, the encryption library functions should be identified as harmless processing modules. Thus, the taint tracking part may not use the sanitizers part.

[0109] The key component name string is used as the taint source, and the final flow function of the component name is used as the taint convergence point. The relative import address of the component name and version string is found through taint tracing, and the corresponding value is obtained. Then, the component name and / or version string of the first component are determined.

[0110] In one embodiment of this application, the proof-of-concept is performed on the component information of the first component to generate a first verification result, such as... Figure 7 As shown, it specifically includes:

[0111] S410, compare the component information of the first component with the collected component information of the associated components;

[0112] S420, if it is determined that the matching degree between the component information of the first component and the component information of the associated component satisfies the first condition, a proof-of-concept is performed on the component information of the first component based on the version string of the first component.

[0113] For example, an associated component can be associated with and used by a first device. The collected associated components may be vulnerable components, and their component information includes the component name, version number, etc. A first component can also be associated with the first device. The first component may or may not be one of the associated components. To this end, the component information of the first component can be compared with the component information of the associated components, such as comparing their respective component names, to determine whether the first component matches an associated component. For example, if the component name of the first component is the same as or similar to the component name of a collected associated component, then it can be determined that the first component matches an associated component, and the degree of matching satisfies the first condition.

[0114] If the matching degree between the component information of the first component and the component information of the associated components meets the first condition, then the first component can be identified as the target for judgment, which may contain vulnerabilities. Then, based on the version string of the first component, a proof-of-concept operation is performed on the component information of the first component, generating a first verification result. Of course, if it is determined that the matching degree between the component information of the first component and the component information of the associated components does not meet the first condition, then it is unnecessary to perform the proof-of-concept operation on the component information of the first component, thus improving processing efficiency and saving time.

[0115] In one embodiment of this application, comparing the first verification result with the proof-of-concept dataset to determine whether a vulnerability exists in the first component includes the following steps:

[0116] The traffic response information and log information in the second verification result are compared with the corresponding content in the first verification result to determine whether there is a vulnerability in the first component.

[0117] For example, a proof-of-concept operation is performed on the associated component, generating a second verification result. The traffic response information in the second verification result records the verification result of the vulnerability POC, and the log information in the second verification result indicates the entire proof-of-concept process for the associated component.

[0118] The first component is the component currently associated with the first device. A proof-of-concept is performed on the component information of the first component to generate a first verification result. The first verification result contains information about the vulnerability corresponding to the first component. The traffic response information in the second verification result can be compared with the relevant content in the first verification result; the log information in the second verification result can also be compared with the relevant content in the first verification result.

[0119] For example, if the traffic response information and log information in the second verification result are identical to their respective contents in the first verification result, and a vulnerability is also confirmed in the associated component corresponding to the second verification result, then it can be determined that the first component currently used by the first device also has a vulnerability. Otherwise, if the traffic response information and log information in the second verification result are all different from their respective contents in the first verification result, then it can be determined that the first component currently used by the first device does not have a vulnerability.

[0120] The following specific embodiment is used to verify the vulnerability of the third-party component currently associated with the first device (i.e., the first component mentioned above).

[0121] First, collect deb, rpm, and tar packages from Linux software distribution source websites. Extract the component names and version numbers of associated third-party components as indexes for the POC dataset. Collect and build the POC dataset from vulnerability-related open-source POC communities and websites such as https: / / www.exploit-db.com / and https: / / packetstormsecurity.com / . Perform POC operations on the vulnerable associated components, collect and analyze the traffic response information and log information from the POC execution results, and build a set of key strings for POC verification results.

[0122] Secondly, the IoT firmware information is decomposed. Most firmware uses standard compression algorithms, which can be unpacked using reverse engineering tools such as binwalk to obtain a binary file that can be analyzed.

[0123] Secondly, in combination Figure 8After obtaining the firmware binary file, the first referenced component can be analyzed using different methods. For dynamically linked components, tools such as ldd can be used to compare the ELF file header of the associated component or the import directory table recording the names of loaded libraries to confirm the first referenced component. For statically linked components, taint analysis techniques are used. All strings in the IoT firmware are traversed, and the code sequences of strings involving component names are transformed into an abstract syntax tree. Strings matching characteristics like "vision%s" are found, and their relative reference addresses are obtained. Then, the function objects of all functions referencing these addresses are obtained, and the code index of the function object's instruction sequence is analyzed to finally confirm the version string of the referenced first component.

[0124] Fourth, further execute POC verification of the vulnerability. Based on the obtained first component and version string, compare the component name and version string of all related components. If the component name of a related component matches, perform POC verification on the component information of the first component. If the component name of the first component does not match a related component, it is filtered out. After screening, for the first component that does not exist in the POC library, additional POCs can be queried for verification and the POC data can be added to the POC library.

[0125] Fifth, perform feature rule base detection on the POC execution results. Match the data traffic packets of associated components and the log information of the firmware process after the POC operation is completed with the corresponding result feature information in the first verification result. If they match the expected key feature information, it is determined that the first component introduced by the firmware of the first device has introduced a vulnerability into the firmware itself.

[0126] Based on the same inventive concept, embodiments of this application also provide a vulnerability verification device for device-associated components, such as... Figure 9 As shown, it includes:

[0127] The collection module is configured to collect component information of at least one associated component of the first device, as well as proof-of-concept information associated with vulnerabilities of the associated components; and generate a corresponding proof-of-concept dataset based on the component information of the associated components and the proof-of-concept information.

[0128] For example, the first device can be an IoT device used in the Internet of Things (IoT). This first device can be associated with one or more associated components. These associated components are third-party components different from the first device itself, and each associated component has its own function. After being associated with an associated component, the first device can possess the corresponding function. In one embodiment, any component that can be associated with the first device can be considered an associated component. Therefore, the associated components of the first device can be one or more different components.

[0129] The associated component has component information, which may include the component name, version number, and log files. The collection module can collect this component information based on historical data, the target database, and / or specific identifiers within the associated component.

[0130] For example, the collection module collects deb packages, rpm packages, and tar packages from the source websites that distribute Linux software, extracts the names and version numbers of associated components, and generates corresponding component information.

[0131] The proof-of-concept information associated with the vulnerability of the associated component can be a proof of concept (POC) information. The content of the POC information can prove the functionality and / or performance of the first device, and of course it is also associated with relevant information about the vulnerability. For example, the proof-of-concept information can include vulnerability verification code and / or attack examples targeting the vulnerability.

[0132] In this embodiment, the collection module can collect proof-of-concept information associated with vulnerabilities in related components based on historical data, target databases, and / or specific identifiers in related components. For example, it can collect and build a POC dataset from open-source POC communities and websites associated with vulnerabilities, such as https: / / www.exploit-db.com / and https: / / packetstormsecurity.com / . It can also execute POC operations on related components containing vulnerable versions and collect corresponding proof-of-concept information. For example, it can collect and analyze traffic response information and log information from POC execution results to build a set of key strings for POC verification results.

[0133] For example, the collection module can associate component information with proof-of-concept information, thereby associating each sub-information in the component information with the proof-of-concept information, and generating a proof-of-concept dataset based on all the associated proof-of-concept information. The proof-of-concept dataset includes content related to vulnerability verification.

[0134] Continuing with the above embodiments, for example, the collection module collects and analyzes the traffic response information and log information of the POC execution results, establishes a set of key strings for POC verification results, forms multiple proof-of-concept information, and combines the multiple proof-of-concept information with the component information such as the component name, version number, and log file of the associated components to generate the corresponding proof-of-concept dataset.

[0135] In one embodiment, the vulnerability-related information represented in the proof-of-concept dataset can be verified to determine the correctness of the data.

[0136] An analysis module is configured to determine component information of a first component currently associated with the first device based on the firmware information of the first device, wherein the first component corresponds to the associated component.

[0137] For example, firmware is a program written into the EPROM or EEPROM of the first device. Firmware refers to the device "driver" stored inside the device, which is the software that performs the underlying work of a system. Through firmware, specific machine operations can be implemented according to standard device drivers; for example, optical drives and CD burners all have internal firmware.

[0138] The firmware information in this application refers to the program or information stored in the firmware of the first device. The firmware information records relevant information about the components associated with the first device, and these components may also be loaded into the firmware.

[0139] In this embodiment, the first device can be associated with different components at different times. The component currently associated with the first device can be identified as the first component by the analysis module, and the first component can be one of the associated components. After identifying the first component, the analysis module can then determine the component information of the first component.

[0140] The verification module is configured to perform a proof-of-concept on the component information of the first component and generate a first verification result;

[0141] For example, the verification module performs a proof-of-concept on the component information of the first component, which may refer to generating corresponding vulnerability verification code and / or attack examples targeting the vulnerability based on the component information. For instance, the verification module generates corresponding vulnerability verification code and / or attack examples targeting the vulnerability based on the version string of the first component, forming a first verification result. The first verification result includes relevant information about the vulnerability corresponding to the first component. Based on this first verification result, it can be determined whether the first component has a vulnerability.

[0142] The feedback module is configured to compare the first verification result with the proof-of-concept dataset to determine whether there is a vulnerability in the first component.

[0143] For example, a proof-of-concept dataset includes data related to vulnerabilities in associated components, as well as component information such as component name, version number, and log files. This vulnerability-related data can be correlated with the component information, and based on this information, related information can be obtained.

[0144] In this embodiment, the feedback module can compare the first verification result with all corresponding data in the proof-of-concept dataset. For example, the first verification result includes unverified vulnerability information that the first component may have, such as the unverified vulnerability verification code and attack examples generated by the feedback module for the first vulnerability. The feedback module can compare this unverified vulnerability information with the vulnerability-related data contained in the proof-of-concept dataset. If the unverified vulnerability information matches successfully in the proof-of-concept dataset, a vulnerability is determined to exist, indicating that the first component currently used by the first device has a vulnerability.

[0145] In one embodiment of this application, the collection module is further configured as follows:

[0146] The component information of the associated components is used as the index of the proof-of-concept dataset;

[0147] Perform the proof of concept on the associated component containing the vulnerability to generate a second verification result;

[0148] Based on the traffic response information and log information in the second verification result, the proof-of-concept dataset is generated.

[0149] In one embodiment of this application, the analysis module is further configured as follows:

[0150] The firmware information is decomposed to obtain the binary file of the firmware of the first device;

[0151] Based on the binary file, the import method of the first component is determined, wherein the import method includes static link import and dynamic link import;

[0152] Based on the aforementioned introduction method, a corresponding analysis method is adopted to determine the component information of the first component.

[0153] In one embodiment of this application, the analysis module is further configured as follows:

[0154] If it is determined that the first component is introduced via dynamic linking, the header file of the first component is obtained;

[0155] Compare the header file of the first component with the header file of the associated component;

[0156] Based on the comparison results, determine the component information of the first component; or,

[0157] Obtain a specific data table from the firmware of the first device;

[0158] Based on the library name loaded in the specific data table, the component information of the first component is determined.

[0159] In one embodiment of this application, the analysis module is further configured as follows:

[0160] If it is determined that the first component is introduced by static link, the component name string in the first component is used as the taint source, and the flow function of the component name of the first component is used as the taint convergence point.

[0161] The component name and / or version string of the first component are determined by taint tracing.

[0162] In one embodiment of this application, the verification module is further configured as follows:

[0163] The component information of the first component is compared with the component information of the associated components collected.

[0164] If the degree of matching between the component information of the first component and the component information of the associated component satisfies the first condition, a proof-of-concept is performed on the component information of the first component based on the version string of the first component.

[0165] In one embodiment of this application, the feedback module is further configured as follows:

[0166] The traffic response information and log information in the first verification information are compared with the corresponding content in the first verification result to determine whether there is a vulnerability in the first component.

[0167] Based on the same inventive concept, embodiments of this application also provide an electronic device, such as... Figure 10 As shown, it includes: a memory and a processor, wherein the memory stores an executable program, and the processor executes the executable program to implement the steps of the method described above.

[0168] The aforementioned processor can be a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0169] The aforementioned memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0170] This application also provides a storage medium that carries one or more computer programs, which, when executed by a processor, implement the steps of the method described above.

[0171] The storage medium in this embodiment may be included in an electronic device / system; or it may exist independently and not assembled into an electronic device / system. The storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0172] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0173] The above embodiments are merely exemplary embodiments of this application and are not intended to limit this application. The scope of protection of this application is defined by the claims. Those skilled in the art can make various modifications or equivalent substitutions to this application within its substance and scope of protection, and such modifications or equivalent substitutions should also be considered to fall within the scope of protection of this application.

Claims

1. A method for vulnerability verification of a device component, characterized in that, include: Collect component information of at least one associated component of the first device, as well as proof-of-concept information associated with vulnerabilities of the associated component; Based on the component information of the associated components and the proof-of-concept information, a corresponding proof-of-concept dataset is generated; Based on the firmware information of the first device, determine the component information of the first component currently associated with the first device, wherein the first component corresponds to the associated component; Perform a proof-of-concept analysis on the component information of the first component to generate a first verification result; The first verification result is compared with the proof-of-concept dataset to determine whether there are any vulnerabilities in the first component; The generation of a corresponding proof-of-concept dataset based on the component information of the associated components and the proof-of-concept information includes: The component information of the associated components is used as the index of the proof-of-concept dataset; Perform the proof of concept on the associated component containing the vulnerability to generate a second verification result; Based on the traffic response information and log information in the second verification result, the proof-of-concept dataset is generated.

2. The method according to claim 1, characterized in that, The step of determining the component information of the first component currently associated with the first device based on the firmware information of the first device includes: The firmware information is decomposed to obtain the binary file of the firmware of the first device; Based on the binary file, the import method of the first component is determined, wherein the import method includes static link import and dynamic link import; Based on the aforementioned introduction method, a corresponding analysis method is adopted to determine the component information of the first component.

3. The method according to claim 2, characterized in that, Based on the aforementioned introduction method, and employing a compatible analysis approach, the component information of the first component is determined, including: If it is determined that the first component is introduced via dynamic linking, the header file of the first component is obtained; Compare the header file of the first component with the header file of the associated component; Based on the comparison results, determine the component information of the first component; or, Obtain a specific data table from the firmware of the first device; Based on the library name loaded in the specific data table, the component information of the first component is determined.

4. The method according to claim 2, characterized in that, Based on the aforementioned introduction method, and employing a compatible analysis approach, the component information of the first component is determined, including: If it is determined that the first component is introduced by static link, the component name string in the first component is used as the taint source, and the flow function of the component name of the first component is used as the taint convergence point. The component name and / or version string of the first component are determined by taint tracing.

5. The method according to claim 1, characterized in that, The step of performing a proof-of-concept on the component information of the first component and generating a first verification result specifically includes: The component information of the first component is compared with the component information of the associated components collected. If the degree of matching between the component information of the first component and the component information of the associated component satisfies the first condition, a proof-of-concept is performed on the component information of the first component based on the version string of the first component.

6. The method according to claim 1, characterized in that, The step of comparing the first verification result with the proof-of-concept dataset to determine whether there is a vulnerability in the first component includes: The traffic response information and log information in the first verification information are compared with the corresponding content in the first verification result to determine whether there is a vulnerability in the first component.

7. A vulnerability verification device for a device component, characterized in that, include: A collection module is configured to collect component information of at least one associated component of the first device, as well as proof-of-concept information associated with vulnerabilities of the associated component; Based on the component information of the associated components and the proof-of-concept information, a corresponding proof-of-concept dataset is generated; An analysis module is configured to determine component information of a first component currently associated with the first device based on the firmware information of the first device, wherein the first component corresponds to the associated component; The verification module is configured to perform a proof-of-concept on the component information of the first component and generate a first verification result; The feedback module is configured to compare the first verification result with the proof-of-concept dataset to determine whether there is a vulnerability in the first component; The generation of a corresponding proof-of-concept dataset based on the component information of the associated components and the proof-of-concept information includes: The component information of the associated components is used as the index of the proof-of-concept dataset; Perform the proof of concept on the associated component containing the vulnerability to generate a second verification result; Based on the traffic response information and log information in the second verification result, the proof-of-concept dataset is generated.

8. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores an executable program, and the processor executes the executable program to implement the steps of the method as claimed in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium carries one or more computer programs, which, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 6.

Images