Vulnerability information processing method, service device and vulnerability detection module

Abstract

The present application proposes a vulnerability information processing method, a service device, and a vulnerability detection module. The technical solution is as follows: determine a first component included in an IoT device; search for vulnerability trigger information corresponding to the first component in a first vulnerability library; wherein the vulnerability trigger information is used to trigger the first component to call a vulnerability function to determine whether the first component has a vulnerability. According to the embodiments of the present application, the accuracy of the vulnerability detection result can be improved.

Description

Technical Field

[0001] The present application relates to the field of Internet of Things, and in particular to a vulnerability information processing method, a service device and a vulnerability detection module. Background Art

[0002] With the booming development of IoT (Internet of Things) business, security issues of IoT devices are constantly exposed. IoT device vulnerabilities, as an important breakthrough point for IoT attacks, have become one of the key concerns in the field of IoT security. Since open source components are introduced into IoT devices, vulnerability detection of components in IoT devices is the key content of IoT device vulnerability detection. However, the development of IoT devices is fragmented, with multiple system architectures, multiple compilation tools, and software reduction to save space, which leads to low accuracy of vulnerability detection results of components in IoT devices. Summary of the invention

[0003] The embodiment of the present application provides a vulnerability information processing method, a service device and a vulnerability detection module to solve the problems existing in the related technologies. The technical solution is as follows:

[0004] In a first aspect, an embodiment of the present application provides a vulnerability information processing method, including:

[0005] Identify the first component that an IoT device contains;

[0006] The vulnerability triggering information corresponding to the first component is searched in the first vulnerability library; wherein the vulnerability triggering information is used to trigger the first component to call the vulnerability function to determine whether there is a vulnerability in the first component.

[0007] In a second aspect, an embodiment of the present application provides a vulnerability information processing method, including:

[0008] Identify the first component that an IoT device contains;

[0009] Sending identification information of the first component to the service device to obtain vulnerability triggering information corresponding to the first component searched by the service device in the first vulnerability library;

[0010] The first component is triggered to call the vulnerability function based on the vulnerability triggering information to determine whether the first component has a vulnerability.

[0011] In a third aspect, an embodiment of the present application provides a service device, including a memory, a processor, and a computer program stored in the memory, and the processor implements the method provided in any embodiment of the present application when executing the computer program.

[0012] In a fourth aspect, an embodiment of the present application provides a vulnerability detection module for being set in an Internet of Things device. The vulnerability detection module includes a memory, a processor, and a computer program stored in the memory. When the processor executes the computer program, it implements the method provided in any embodiment of the present application.

[0013] In a fifth aspect, an embodiment of the present application provides an Internet of Things device, including a vulnerability detection module provided by any embodiment of the present application.

[0014] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the method provided in any embodiment of the present application is implemented.

[0015] According to an embodiment of the present application, a first vulnerability library for storing vulnerability triggering information of components can be pre-constructed. For a first component included in the Internet of Things device, the corresponding vulnerability triggering information can be searched in the first vulnerability library, and the vulnerability triggering information corresponding to the first component can be used to trigger the first component to call a vulnerability function to determine whether a vulnerability actually exists in the component, thereby avoiding false vulnerability detection due to the fragmented scenario characteristics of IoT devices, thereby improving the accuracy of vulnerability detection results.

[0016] The above summary is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments and features described above, further aspects, embodiments and features of the present application will be readily apparent by reference to the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the multiple drawings represent the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings only depict some embodiments disclosed in the present application and should not be regarded as limiting the scope of the present application.

[0018] Figure 1 A schematic diagram of an exemplary application scenario of an embodiment of the present application.

[0019] Figure 2 The figure is a flowchart of a vulnerability information processing method according to an embodiment of the present application.

[0020] Figure 3 The figure is a flowchart of a vulnerability information processing method according to another embodiment of the present application.

[0021] Figure 4 The figure is a flowchart of a vulnerability information processing method according to another embodiment of the present application.

[0022] Figure 5This is a structural block diagram of the vulnerability information processing system in the application example of this application.

[0023] Figure 6 This is a structural block diagram of the IoT device vulnerability operation and maintenance framework in the application example of this application.

[0024] Figure 7 This is a structural block diagram of the feature operation and maintenance framework of IoT device components in the application example of this application.

[0025] Figure 8 This is a structural block diagram of the IoT device component data collection and component identification framework in the application example of this application.

[0026] Fig. 9 This is a structural block diagram of the IoT device vulnerability identification framework in the application example of this application.

[0027] Fig.10 A structural block diagram of an electronic device for implementing the method of an embodiment of the present application. DETAILED DESCRIPTION

[0028] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the spirit or scope of the present application. Therefore, the drawings and descriptions are considered to be exemplary and non-restrictive in nature.

[0029] To facilitate understanding of the technical solution of the embodiments of the present application, an application scenario of the vulnerability information processing method that can be used to implement the embodiments of the present application is first introduced.

[0030] Figure 1 A schematic diagram of an exemplary application scenario is shown. Figure 1As shown, in this application scenario, a service device for vulnerability detection is deployed. The service device can access a public vulnerability library to obtain information security vulnerabilities disclosed in the public vulnerability library. For example, the public vulnerability library may include CVE (Common Vulnerabilities & Exposures), which is similar to a dictionary table, providing a public name for widely recognized information security vulnerabilities for users or related services to query. Based on the information obtained from the public vulnerability library, the vulnerability service device can analyze the IoT device components involved in each vulnerability. In some scenarios, the service device can also access the source code library to obtain the source code of the IoT device components. In this way, the service device can further analyze the corresponding vulnerability trigger information for the IoT device components involved in the vulnerability, such as the functions involved in the vulnerability, the function parameters that trigger the vulnerability, and the return value corresponding to the function parameters based on the vulnerability. Based on one or more of the above information, the service device can build a dedicated vulnerability library to use the dedicated vulnerability library for more accurate vulnerability detection.

[0031] like Figure 1 As shown, in some application scenarios, by accessing the source code library, the service device can also build a component feature library. For example, the service device can compile the binary file of the IoT device component based on the source code of the IoT device component obtained from the source code library, and then obtain the identification features of the IoT device component by analyzing the binary file. In some embodiments of the present application, it is proposed to adopt identification features that are independent of the device system and architecture. In some scenarios, these identification features can also be optimized to overcome the impact of multiple operating systems, multiple architectures, diverse compilation conditions, and software tailoring in the fragmented IoT scenario on component identification. Based on the above identification features, the service device can build a component feature library so that the relevant components in the IoT device can be identified using the component feature library.

[0032] like Figure 1 As shown, a vulnerability detection module can be configured in the IoT device to interact with the service device to complete vulnerability detection. Exemplarily, the vulnerability detection module can access the component feature library to identify the relevant components in the IoT device using the identification features of the components related to the vulnerability in the component feature library. Furthermore, the vulnerability detection module can send the information of the relevant components to the service device so that the service device returns the information corresponding to the component in the dedicated vulnerability library. The vulnerability detection module can use this information to accurately determine whether the vulnerability actually exists.

[0033] In order to enable a more detailed understanding of the features and technical contents of the embodiments of the present application, the implementation of the embodiments of the present application is described in detail below in conjunction with the accompanying drawings. The attached drawings are for reference only and are not used to limit the embodiments of the present application.

[0034] Figure 2 A flowchart of a vulnerability information processing method according to an embodiment of the present application is shown. Figure 2 As shown, the method may include:

[0035] S210, determining a first component included in the IoT device;

[0036] S220. Searching for vulnerability triggering information corresponding to the first component in the first vulnerability library; wherein the vulnerability triggering information is used to trigger the first component to call a vulnerability function to determine whether the first component has a vulnerability.

[0037] Optionally, the above steps can be performed by Figure 1 The service device shown is executed. Exemplarily, the service device can determine the first component included in the IoT device by interacting with the vulnerability detection module in the IoT device, for example, by receiving the component information sent by the IoT device, and determining the first component included in the IoT device based on the component information. After the service device searches for the vulnerability trigger information corresponding to the first component in the first vulnerability library, it can also send the vulnerability trigger information to the vulnerability detection module to use the vulnerability detection module to trigger the first component to call the vulnerability function to determine whether the first component has a vulnerability. The vulnerability detection module can be a functional module integrated into the device firmware of the IoT device, or it can be a functional module that is independent of the IoT device and can be assembled on the IoT device. It can be understood that since the vulnerability detection module provides security functions for the IoT device, the vulnerability detection module can also be understood as a security agent module in the IoT device. It can be seen that the program module used to implement the above steps S210 and S220 in the service device and the vulnerability detection module in the IoT device constitute an IoT device vulnerability identification framework, which determines whether the vulnerability really exists by calling the vulnerability function.

[0038] Optionally, the above steps may also be performed by a vulnerability detection module in the IoT device. For example, the vulnerability detection module may determine the first component by itself, and access the first vulnerability library to search for corresponding vulnerability trigger information to call the vulnerability function.

[0039] Optionally, the components in the embodiments of the present application may include open source components in an IoT device.

[0040] Optionally, the first vulnerability library is used to store a plurality of vulnerability triggering information corresponding to a plurality of components. The plurality of components may include components with vulnerability risks. Exemplarily, the first vulnerability library may be as follows: Figure 1 The dedicated vulnerability library shown, in which component information and vulnerability triggering information are obtained based on the public vulnerability library and source code library.

[0041] Optionally, the first vulnerability library can be used to store description information of vulnerabilities corresponding to multiple components, and store vulnerability trigger information corresponding to each vulnerability. Based on this, in the above step S220, the description information of the vulnerability corresponding to the first component can be first searched in the first vulnerability library, and then the corresponding vulnerability trigger information can be obtained based on the description information of the vulnerability.

[0042] Optionally, the first component may include any component in the IoT device, or may include a specific component in the IoT device, such as a component with a vulnerability risk.

[0043] For example, the vulnerability detection module in the IoT device can periodically perform vulnerability detection on any component in the IoT device, and send the identification information of the component, such as name, version number, etc., to the service device, which searches for relevant information of the component in the first vulnerability library. If not, it is considered that the component does not have a vulnerability; if so, the vulnerability triggering information of the component is returned to the vulnerability detection module, so that the vulnerability detection module triggers the component to call the vulnerability function, and determines whether the vulnerability really exists based on the return result of the vulnerability function.

[0044] For another example, the vulnerability detection module in the IoT device can access a pre-built component feature library, such as a component feature library built based on the source code of the component involved in the vulnerability, and compare the identification features of the components in the IoT device with the identification features of each component in the component feature library to determine whether the IoT device contains a component in the component feature library, that is, the component with vulnerability risk in the IoT device. If it does, the identification information of the component is sent to the service device, and the service device searches for the vulnerability triggering information of the component in the first vulnerability library, and returns the vulnerability triggering information of the component to the vulnerability detection module, so that the vulnerability detection module triggers the component to call the vulnerability function, and determines whether the vulnerability really exists according to the return result of the vulnerability function.

[0045] Optionally, the vulnerability function includes a function in a component that is related to a vulnerability, and can be determined by analyzing the source code of the component and vulnerability information such as vulnerability patches provided by a public vulnerability library.

[0046] Optionally, the vulnerability triggering information may include the vulnerability function, function parameters for triggering the vulnerability function, and a preset return value. The function parameter may be a function parameter that triggers the vulnerability determined by analyzing the source code of the component and the vulnerability information provided by the public vulnerability library. The preset return value may be a function return value caused by the function parameter and the vulnerability, which may be determined by analyzing the source code of the component and the vulnerability information provided by the public vulnerability library. If the preset return value is the same as the return value obtained by calling the vulnerability function based on the function parameter in the actual application, it can be considered that the first component has a vulnerability; if the preset return value is different from the return value obtained by calling the vulnerability function based on the function parameter in the actual application, it can be considered that the component does not have a vulnerability. That is, the function parameter is used to call the vulnerability function in the first component to obtain the return value of the vulnerability function. The preset return value is used to compare with the return value of the vulnerability function to determine whether the first component has a vulnerability.

[0047] It can be seen that according to the above method, a first vulnerability library for storing vulnerability triggering information of components can be pre-built. For the first component included in the IoT device, the corresponding vulnerability triggering information can be found in the first vulnerability library, and the vulnerability triggering information corresponding to the first component can be used to trigger the first component to call the vulnerability function to determine whether a vulnerability actually exists in the component, thereby avoiding false vulnerability detection due to the fragmented scenario characteristics of IoT devices, thereby improving the accuracy of vulnerability detection results.

[0048] Optionally, the embodiment of the present application also provides an operation and maintenance method of the first vulnerability library. Specifically, the method may also include:

[0049] Read vulnerability information in a second vulnerability database to determine a second component related to the vulnerability;

[0050] Determine vulnerability triggering information of the second component based on the vulnerability information and the source code of the second component;

[0051] The identification information and vulnerability triggering information of the second component are stored in the first vulnerability library.

[0052] The above steps can be performed by the service device, or by an IoT device vulnerability operation and maintenance framework including the service device. The framework connects to the second vulnerability library and the source code library, and outputs information to be stored in the first vulnerability library.

[0053] Among them, the second vulnerability library can be a public vulnerability library, such as CVE, including NVD (National Vulnerability Database, the United States National Common Vulnerability Database), CNNVD (China National Vulnerability Database of Information, China National Information Security Vulnerability Database), CNVD (China National Vulnerability Database, National Information Security Vulnerability Sharing Platform), etc.

[0054] The vulnerability information in the second vulnerability database may include components with vulnerability risks, component version information, vulnerability patches, etc. In some scenarios, the vulnerability information may also include a specific description of the vulnerability, the cause of the vulnerability, etc.

[0055] In an embodiment of the present application, the second component is a component related to the vulnerability determined based on the vulnerability information in the second vulnerability library. After determining the second component, the source code of the second component can be obtained from the source code library, and based on the vulnerability information such as vulnerability patches, the cause of the vulnerability, and the source code, the vulnerability triggering information of the second component can be determined, including the vulnerability function in the second component and the function parameters and preset return values ​​that trigger the vulnerability. The above-mentioned vulnerability triggering information is stored in the first vulnerability library. When the IoT device needs to check for vulnerability risks, the vulnerability triggering information of the relevant components can be found by accessing the first vulnerability library to determine whether there are real vulnerabilities in the components of the IoT device.

[0056] As described above, in some embodiments of the present application, it is also proposed to use identification features that are independent of the device system and architecture to identify components in IoT devices, so as to overcome the impact of multiple operating systems, multiple architectures, diverse compilation conditions, and software tailoring on component identification in the fragmented IoT scenario. For example, Figure 3 A vulnerability information processing method according to another embodiment of the present application is shown. The method can be performed by Figure 1 The method is executed by the service device shown, or by the IoT component feature operation and maintenance framework including the service device, but is not limited to this. The method includes:

[0057] S310, reading identification information of the third component in the first vulnerability library, and acquiring multiple source codes corresponding to multiple versions of the third component based on the identification information;

[0058] S320, obtaining multiple binary files based on multiple source codes;

[0059] S330, respectively parsing the multiple binary files to obtain multiple invariant sets corresponding to the multiple binary files;

[0060] S340. Based on multiple invariant sets, obtain at least one component identification feature of the third component; wherein the at least one component identification feature is used to identify whether the Internet of Things device includes the third component.

[0061] Exemplarily, the third component may include any component in the first vulnerability library. For example, the third component may represent each component in the first vulnerability library. It can be seen that the above embodiment provides a step of determining at least one component identification feature of the third component. Based on the identification features of each component, a component feature library can be constructed and maintained, so that the vulnerability detection module in the IoT device can identify the components in the IoT device by accessing the component feature library.

[0062] In the above method, multiple source codes corresponding to multiple versions of the third component can be obtained by accessing the source code library. The source code library can be an open source community repository or a local source code library. Exemplarily, based on the list of components related to vulnerabilities provided by the first vulnerability library, the open source community repository can be periodically accessed to pull the source code of each component in the first vulnerability library to build a local source code library. Furthermore, the corresponding binary file can be compiled based on the source code and the mainstream system architecture. Optionally, a binary file repository can also be built to store binary files.

[0063] Exemplarily, the set of invariants obtained by parsing the binary file may include one or more invariants. In an embodiment of the present application, an invariant may refer to field information that always exists in the process of compiling from source code to binary file. Since the Internet of Things has fragmented characteristics such as multiple architectures and multiple systems, and different CPU architectures, operating systems, and compilation optimization options will cause even the same source code to have large differences between the binary files finally compiled and generated. Therefore, the component identification features of the component are obtained based on the invariant set, which can improve the recognition accuracy. Exemplarily, the invariant set may include constant strings, constant values, function lists, function parameter lists, etc.

[0064] According to the above method, for each of the multiple versions of the third component, the corresponding source code, binary file, and invariant set will be determined in turn, thereby obtaining multiple invariant sets corresponding to the multiple versions. In practical applications, multiple invariant sets can be calculated to screen and optimize the invariants to obtain the final component identification features. Specifically, there are a variety of optional implementations for obtaining component identification features based on multiple invariant sets. Several examples are provided below, and it can be understood that those skilled in the art can select one or more of the examples to obtain the component identification features of the third component.

[0065] Example 1:

[0066] Step S340, based on multiple invariant sets, obtaining at least one component identification feature of the third component, including: based on the intersection of multiple invariant sets, obtaining a first component identification feature of the third component.

[0067] Since the intersection of the invariant sets reflects the invariants shared by multiple versions of the third component, accurate component identification features can be obtained based on the intersection.

[0068] Optionally, the intersection of multiple invariant sets can be directly used as the first component identification feature, or the intersection can be used as the first component identification feature after a predetermined process is performed on the intersection. For example, in the intersection of multiple invariant sets, invariants whose component coverage is greater than a first threshold are eliminated to obtain the first component identification feature of the third component.

[0069] Among them, the component coverage of a certain invariant can be obtained by counting the invariants parsed from the binary files of multiple components. Specifically, component coverage is used to characterize the proportion of the number of components containing the invariant relative to the number of all components. For example, the number of occurrences of the invariant in each file in the binary file library can be counted to obtain component coverage.

[0070] According to the above example, invariants whose component coverage is greater than the first threshold are eliminated from the above intersection, thereby avoiding the influence of invariants without personalized characteristics on the recognition effect, which can further improve the recognition accuracy.

[0071] Example 2:

[0072] Step S340, based on multiple invariant sets, obtaining at least one component identification feature of the third component, including: based on the similarity between the multiple invariant sets, obtaining a second component identification feature of the third component.

[0073] Exemplarily, the similarity between multiple invariant sets corresponding to multiple versions of the third component can be directly used as a component identification feature of the third component and stored in the component feature library.

[0074] Among them, the similarity between multiple invariant sets, which characterizes the similarity between multiple versions of the third component, may include the similarity between multiple invariant sets, or may include the similarity between multiple groups of invariant sets, wherein each group of invariant combinations includes two invariant sets, and each group of invariant sets can be selected from the above-mentioned multiple invariant sets based on preset rules.

[0075] Using the similarity between the invariant sets of different versions of the same component as the component identification feature can facilitate storage and speed up component identification.

[0076] Example 3:

[0077] Step S340: Based on multiple invariant sets, obtain at least one component identification feature of the third component, including: constructing a regular expression based on specific strings in the multiple invariant sets, and using the regular expression as the third component identification feature of the third component.

[0078] In some components, specific strings in their binary files contain the name and version information of the component. Based on these specific strings, regular expressions that directly identify components can be constructed. These regular expressions can be used as an identification feature to improve the recognition rate and speed of components.

[0079] In some embodiments of the present application, it is also proposed to use the above-mentioned invariant set to identify the component version. Specifically, the above-mentioned vulnerability information processing method may also include:

[0080] Based on multiple invariant sets, at least one version identification feature of a first version among multiple versions is obtained; wherein the at least one version identification feature is used to identify a version of a third component when the IoT device includes the third component.

[0081] The first version may be any version of the third component, or the first version may represent each version of the third component, that is, for each version, multiple invariant sets of the above components may be used to obtain at least one version identification feature.

[0082] There are multiple optional implementations for obtaining version identification features based on multiple invariant sets. Several examples are provided below, and it is understood that those skilled in the art can select one or more of the examples to obtain the component identification features of the first version of the third component.

[0083] Example 4: Based on multiple invariant sets, obtaining at least one version identification feature of a first version among multiple versions, including: determining a difference between a first invariant set among the multiple invariant sets and other invariant sets among the multiple invariant sets, and obtaining a first version identification feature of the first version based on the difference.

[0084] The first invariant set is an invariant set corresponding to the first version among the multiple invariant sets.

[0085] Exemplarily, the above-mentioned other invariant sets may include all invariant sets in the multiple invariant sets except the first invariant set; or, include invariant sets corresponding to the first N versions of the first version, where N is an integer greater than or equal to 1. For example, the difference between the first invariant set and the other invariant sets may include the difference between the first invariant set and all other invariant sets as a whole, and the difference only contains invariants unique to the first invariant set. Therefore, the first version corresponding to the first invariant set can be accurately identified based on the difference. For another example, the difference between the first invariant set and the other invariant sets may include the invariant set corresponding to the previous version of the first version. Since in the process of technological updating and iteration, algorithm functions are often added on the basis of the previous version, therefore, calculating the above-mentioned difference based on the invariant set corresponding to the previous version can improve efficiency.

[0086] Optionally, the difference set may be directly used as the version identification feature of the first version, or the difference set may be processed in a predetermined manner to obtain the version identification feature of the first version. For example, based on the difference set, obtaining the first version identification feature of the first version includes: removing invariants whose occurrence frequency is greater than a second threshold in the difference set to obtain the first version identification feature of the first version.

[0087] The frequency of occurrence of a certain invariant can be obtained by counting the invariants parsed from the binary files of multiple components. Specifically, the frequency of occurrence is used to characterize the number of times the invariant appears in all components. For example, the number of times the invariant appears in each file in the binary file library can be counted to obtain the frequency of occurrence. If the invariant appears multiple times in different versions of the same component, it can be recorded only once in the frequency of occurrence.

[0088] According to the above example, invariants whose occurrence frequency is greater than the first threshold are eliminated in the above difference set, thereby avoiding the influence of invariants without personalized characteristics on the recognition effect, which can further improve the recognition accuracy.

[0089] Example 5: Based on multiple invariant sets, obtaining at least one version identification feature of a first version among multiple versions includes: based on the similarity between the first invariant set and other invariant sets, obtaining a second version identification feature of the first version.

[0090] Exemplarily, the similarity between the first invariant set corresponding to the first version and other invariant sets can be directly used as a version identification feature of the first version and stored in the component feature library.

[0091] The similarity between the first invariant set and other invariant sets may include the similarity between the first invariant set and each other invariant set. Exemplarily, the similarity may be represented based on a vector, where each element in the vector corresponds to an invariant set, and each element represents the similarity between the first invariant set and the invariant set corresponding to the element.

[0092] Using the similarity between invariant sets as version identification features can facilitate storage and speed up component identification.

[0093] Example 6: Based on multiple invariant sets, obtaining at least one version identification feature of a first version among multiple versions includes: constructing a regular expression based on a specific string in the first invariant set, and using the regular expression as a third version identification feature of the first version.

[0094] In some components, specific strings in their binary files contain component version information. Based on these specific strings, regular expressions that directly identify versions can be constructed. These regular expressions can be used as an identification feature to improve the recognition rate and speed of component versions.

[0095] Through the above description, the corresponding component identification features and version identification features can be obtained for each component in the first vulnerability library, so that the vulnerability detection module in the Internet of Things device can compare these identification features with the identification features of the components in the Internet of Things device to identify the components and versions in the Internet of Things device.

[0096] For example, Figure 4 A vulnerability information processing method according to another embodiment of the present application is shown, which can be executed by a vulnerability detection module in an IoT device, but is not limited thereto. The method may include:

[0097] S410, determining a first component included in the IoT device;

[0098] S420: Send identification information of the first component to the service device to obtain vulnerability trigger information corresponding to the first component searched by the service device in the first vulnerability library;

[0099] S430: Trigger the first component to call the vulnerability function based on the vulnerability triggering information to determine whether the first component has a vulnerability.

[0100] The technical details of the above method can be implemented with reference to the above embodiments and will not be described in detail here.

[0101] Optionally, the vulnerability triggering information may include: a vulnerability function, a function parameter for triggering the vulnerability function, and a preset return value. Accordingly, step S430, triggering the first component to call the vulnerability function based on the vulnerability triggering information to determine whether the first component has a vulnerability, may include:

[0102] Triggering the first component to call the vulnerable function based on the function parameter to obtain a return value of the vulnerable function;

[0103] The return value of the vulnerable function is compared with a preset return value to determine whether the first component has a vulnerability.

[0104] Among them, if the return value of the vulnerability function is consistent with the preset return value, it is determined that the first component has a vulnerability; if the return value of the vulnerability function is inconsistent with the preset return value, it is determined that the first component does not have a vulnerability.

[0105] Optionally, before step S430, it may be determined whether the first component contains the vulnerability function. If the first component does not contain the vulnerability function, it may be determined directly that the first component does not have the vulnerability. If the first component contains the vulnerability parameter, the above step S430 is executed for further determination.

[0106] Optionally, the above step S410, determining the first component included in the IoT device, may include:

[0107] Obtain identification features corresponding to component binary files of IoT devices;

[0108] Based on the identification feature, a first component and / or a version of the first component included in the IoT device is determined.

[0109] Specifically, after obtaining the identification features corresponding to the binary file of the component of the IoT device itself, the identification features corresponding to the binary file of the component and the identification features of multiple components can be compared or calculated by accessing the component feature library to identify the components included in the IoT device. Here, the identification features may include component identification features and / or version identification features, and accordingly, the information obtained by identification may include components and / or component versions.

[0110] Exemplarily, obtaining identification features corresponding to component binary files of IoT devices includes:

[0111] Get the identification information of the component binary files of IoT devices;

[0112] Based on the identification information of the component binary file, the identification features corresponding to the component binary file are downloaded from the cloud.

[0113] Here, the identification information corresponding to the component binary file may include the name and / or path of the binary file. The component binary file may include multiple versions of binary files of a component. Accordingly, based on the identification information of the component binary file, identification features corresponding to multiple versions of binary files may be downloaded from the cloud. The identification feature may include a component identification feature corresponding to the component binary file and / or a version identification feature of each version, or, the component identification feature corresponding to the component binary file and / or a version identification feature of each version may be parsed from the identification feature, thereby using the component identification feature to identify the component in the IoT device, and then using the version identification feature to identify the specific version of the component.

[0114] Exemplarily, the above-mentioned determining the first component and / or the version of the first component included in the IoT device based on the identification feature includes:

[0115] Based on at least one component identification feature corresponding to a component binary file of the Internet of Things device and at least one component identification feature of each of a plurality of pre-stored components, a first component included in the Internet of Things device is determined from the plurality of components.

[0116] The at least one component identification feature can be implemented with reference to the above examples 1-3. Specifically, a condition can be preset for each component identification feature. When each component identification feature of the i-th component among the above multiple components satisfies the condition, it can be determined that the IoT device contains the i-th component, that is, the i-th component is the first component. Where i is an integer greater than or equal to 1.

[0117] For the first component identification feature that contains at least one invariant, the intersection of the first component identification feature corresponding to the device and the first component identification feature of the i-th component can be compared with the first component identification feature of the i-th component. If the number of elements in the intersection accounts for a larger proportion of the number of elements in the first component identification feature of the i-th component than a third threshold, it is considered that the condition is met.

[0118] For the second component identification feature containing a similarity value, the difference between the second component identification feature corresponding to the device and the second component identification feature of the i-th component can be compared with the fourth threshold. If the difference is less than the fourth threshold, it is considered that the condition is met.

[0119] For the third component identification feature containing a regular expression, it can be directly or indirectly determined whether a specific string is contained in the component binary file. If so, it is considered that the condition is met.

[0120] Similarly, in the case where the IoT device includes a first component, determining the first component and / or the version of the first component included in the IoT device based on the identification feature includes:

[0121] Based on at least one version identification feature corresponding to a component binary file of the IoT device and at least one version identification feature of each version of the first component, a version of a first component in the IoT device is determined.

[0122] The at least one version identification feature can be implemented with reference to the above examples 1-4. Specifically, a condition can be preset for each version identification feature. When each version identification feature of the jth version among the multiple versions satisfies the condition, it can be determined that the version of the first component in the IoT device is the jth version. Wherein, j is an integer greater than or equal to 1.

[0123] For the first version identification feature that contains at least one invariant, the intersection of the first version identification feature corresponding to the device and the first version identification feature of the j-th version can be used to compare with the first version identification feature of the j-th version. If the number of elements in the intersection accounts for a larger proportion of the number of elements in the first version identification feature of the j-th version than a third threshold, the condition is considered to be met.

[0124] For the second version identification feature containing a similarity value, the difference between the second version identification feature corresponding to the device and the second version identification feature of the jth version can be compared with the fourth threshold. If the difference is less than the fourth threshold, it is considered that the condition is met.

[0125] For the third version identification feature containing regular expressions, it can be directly or indirectly determined whether a component binary file contains a specific string. If so, it is considered that the condition is met.

[0126] The above identification process can be implemented by using an IoT device component data collection and component identification framework based on a vulnerability detection module in an IoT device. It can be seen that in some application processes of the embodiments of the present application, the IoT device and the service device can form a vulnerability information processing system. The system is based on the connection between the service device and each database, and the interaction between the service device and the vulnerability detection module in the IoT device. It provides IoT device vulnerability operation and maintenance framework, IoT device component feature operation and maintenance framework, IoT device component data collection and component identification framework, IoT device vulnerability identification framework and other functional frameworks, which improve the accuracy of vulnerability detection from many aspects and are not limited by the system and architecture of the device. In order to more clearly present the technical ideas of the present application, a specific application example is provided below from the perspective of these frameworks.

[0127] Figure 5 The structure diagram of the vulnerability information processing system in this application example is shown. Figure 5As shown, the IoT device vulnerability operation and maintenance framework can obtain public vulnerability information, and parse out the relationship between the vulnerability and the component, the function affected by the vulnerability, etc., and store the parsed information in the first vulnerability library it constructs. The IoT device component feature operation and maintenance framework analyzes the binary files of the components affected by the vulnerability to construct the identification features of the components, and stores the identification features in the component feature library it constructs. The IoT device component data collection and component identification framework uses the security agent (security agent module, i.e., the above-mentioned vulnerability detection module) pre-installed on the device to collect device system files and identify specific components and versions based on the identification features of the components to obtain a list of IoT device components. The IoT device vulnerability identification framework obtains vulnerability trigger information from the first vulnerability library based on the IoT device component list, and uses the security agent pre-installed on the device to determine the validity of the vulnerability, and gives the final vulnerability identification result, i.e., the IoT device vulnerability list.

[0128] Figure 6 The structure diagram of the IoT device vulnerability operation and maintenance framework in the system is shown. Figure 6 As shown, the framework collects vulnerability information from public vulnerability libraries such as NVD, CNNVD, CNVD, etc., parses the correspondence between vulnerabilities and components, and stores it in the first vulnerability library; and collects component source code from the open source community warehouse to build a local component source code warehouse. Based on the source code obtained from the local component source code warehouse, combined with the vulnerability patches in the first vulnerability library, the functions of the components affected by the vulnerability are analyzed, and the relationship between the function parameters and the vulnerability is analyzed. For example, if specific parameters are input to the vulnerability function, the vulnerability function returns a specific result, indicating that the vulnerability exists. The analysis results are also stored in the first vulnerability library. The first vulnerability library built based on the framework contains a description of the vulnerability, the correspondence between the vulnerability and the component and version, the correspondence between the vulnerability and the component function, the function parameters that trigger the vulnerability, and the preset return value.

[0129] Figure 7 The structural diagram of the feature operation and maintenance framework of IoT device components in the system is shown. In IoT scenarios, there are various systems and architectures, but the binary files in the final device will have certain invariants, such as constant strings, constant values, function lists, function parameter lists, etc. The set of these invariants of the component can uniquely represent the component, and a subset of them can represent the various versions of the component. Some invariants even directly contain component and version information.

[0130] In this application example, the identification features of components include three levels and multiple dimensions. The first level refers to the inclusion relationship between binary files and components. The component information can be roughly analyzed based on the name of the binary file; the second level refers to the accurate identification of the component name based on the invariant features of the binary file; the third level refers to the accurate identification of which version of the component it belongs to based on the invariant features of the binary file. Multiple dimensions refer to specific invariant combinations that characterize components, similarity values ​​that characterize components, specific invariant combinations that characterize component versions, specific strings that can match component versions, etc.

[0131] like Figure 7 As shown, the framework is based on the first vulnerability library built in the IoT device vulnerability operation and maintenance framework, analyzes the component list involved in the vulnerability, periodically pulls the source code of each component in the component list from the open source community repository, builds a local component source code repository, compiles component binary files based on the mainstream system architecture, and builds a component binary repository.

[0132] Based on the binary file warehouse, we first built a component and binary relationship warehouse, and then parsed the invariants in all component files under different system architectures to build a component invariant warehouse. Based on the warehouse, we calculated the component coverage c and occurrence frequency f of each invariant, set the coverage threshold to C, and set the occurrence threshold to F. The intersection of the invariant sets of different versions of the component is used as the original feature of the component. The invariants with a coverage threshold greater than C are eliminated to form the invariant features of component identification, that is, the first component identification feature. In order to facilitate storage and speed up component identification, the similarity values ​​of the invariants of different versions of the component can also be calculated, such as simhash (similarity hash) as the second component identification feature of the component. The difference set of invariants between different versions of the component is used as the original feature of the component version. The invariants with an occurrence frequency greater than F are eliminated to form the invariant features of the component version identification, that is, the first version identification feature. In most components, some specific invariants contain the name and current version of the component. Based on these invariants, regular expressions that directly identify components and versions can be constructed. These regular expression features can be used as a supplement to component features, such as third component identification features and third version identification features, to further improve component recognition rate and recognition speed. Based on this, a feature warehouse for identifying components, a feature warehouse for identifying component versions, and a regular expression feature warehouse for identifying components and versions were constructed.

[0133] When using component / version invariant features, it is necessary to set a threshold S1 for feature recognition. Based on this threshold, if: Then the binary file can be recognized as the version of the component. When using the invariant similarity feature of the component version, it is necessary to set the similarity S2 for feature recognition. Based on this threshold, if the following condition is met: the difference between the similarity of the set of binary invariants to be recognized and the invariant similarity of the component version < S2, then the binary file can be recognized as the version of the component. When using the regular expression feature of the component version, the component and its version can be directly or indirectly parsed from the invariants of the binary file using regular expressions.

[0134] Figure 8 The structural block diagram of the component data collection and component recognition framework for IoT devices in the system is shown. This framework uses the security Agent running on the IoT device to scan the names and paths of device binary files, downloads the component recognition features of the corresponding files from the cloud, then parses the invariants in the binary files, uses the component features to identify the component names, and then uses the features of the component version to identify the specific version of the component.

[0135] The security Agent used in the recognition process is a security information collection tool running on the IoT device, which can be integrated and compiled into the device firmware or installed on the device later. This tool can collect the static and runtime information of the device when running on the device.

[0136] In the component recognition process, since the invariants are independent of the device system and architecture, it is not affected by the specific operating system and architecture of the device. The invariant features of components and different versions can still provide a high recognition rate even when the components are trimmed, which is suitable for scenarios such as IoT with fragmentation and limited device resources.

[0137] Fig. 9 The structural block diagram of the IoT device vulnerability recognition framework in the system is shown. This framework queries the component vulnerability list in the first vulnerability database according to the recognized component names and version lists, and then uses the security Agent to call the vulnerability function in real time to determine whether the vulnerability actually exists.

[0138] Specifically, on the one hand, as Fig. 9 shown, the correspondence between components and vulnerabilities is recorded in the first vulnerability database, so the vulnerabilities existing in the components can be queried using the recognized component names and version information.

[0139] On the other hand, the functions affected by the vulnerabilities and the vulnerability trigger conditions are recorded in the first vulnerability database. Then, the security Agent is used to actually call the relevant functions on the device, and whether the vulnerability actually exists can be determined according to the function return values. Specifically, it can be divided into several dimensions:

[0140] 1. If the function related to the vulnerability does not exist, then the vulnerability does not exist;

[0141] 2. If the function related to the vulnerability exists and is called with the vulnerability triggering parameters, and the function's return value does not match the result corresponding to the vulnerability, then the vulnerability has been fixed;

[0142] 3. If a function related to the vulnerability exists and is called with the vulnerability triggering parameters, and the function's return value matches the result corresponding to the vulnerability, it means that the vulnerability has not been fixed and the device may be invaded by using the vulnerability.

[0143] By calling the function, the security agent returns the vulnerability determination result and obtains the real vulnerability list of the component.

[0144] It can be seen that according to the embodiment of the present application, a first vulnerability library for storing vulnerability triggering information of components can be pre-constructed. For the first component included in the Internet of Things device, the corresponding vulnerability triggering information can be found in the vulnerability library, and the vulnerability triggering information corresponding to the first component can be used to trigger the first component to call the vulnerability function to determine whether a vulnerability actually exists in the component, thereby avoiding false vulnerability detection due to the fragmented scenario characteristics of IoT devices, thereby improving the accuracy of vulnerability detection results.

[0145] The embodiment of the present application also provides an electronic device for implementing the above method. The electronic device is, for example, a vulnerability detection module in the above service device or an Internet of Things device. Fig.10 FIG. 1 is a block diagram showing a structure of an electronic device according to an embodiment of the present application. Fig.10 As shown, the electronic device includes: a memory 1010 and a processor 1020, wherein the memory 1010 stores a computer program that can be run on the processor 1020. When the processor 1020 executes the computer program, the vulnerability information processing method in the above embodiment is implemented. The number of the memory 1010 and the processor 1020 can be one or more.

[0146] The electronic device also includes:

[0147] The communication interface 1030 is used to communicate with external devices and perform data exchange transmission.

[0148] If the memory 1010, the processor 1020 and the communication interface 1030 are implemented independently, the memory 1010, the processor 1020 and the communication interface 1030 can be connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.10 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0149] Optionally, in a specific implementation, if the memory 1010, the processor 1020 and the communication interface 1030 are integrated on a chip, the memory 1010, the processor 1020 and the communication interface 1030 can communicate with each other through an internal interface.

[0150] An embodiment of the present application also provides an Internet of Things device, including the above-mentioned vulnerability detection module.

[0151] An embodiment of the present application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method provided in any embodiment of the present application.

[0152] An embodiment of the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the method provided in any embodiment of the present application is implemented.

[0153] An embodiment of the present application also provides a chip, which includes a processor for calling and executing instructions stored in the memory from the memory, so that a communication device equipped with the chip executes the method provided by the embodiment of the present application.

[0154] An embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected via an internal connection path, and the processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the method provided in the embodiment of the application.

[0155] It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor supporting the Advanced RISC Machines (ARM) architecture.

[0156] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory, and may also include a non-volatile random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct memory bus random access memory (DR RAM).

[0157] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0158] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.

[0159] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0160] Any process or method description in the flow chart or otherwise described herein can be understood to represent a module, fragment or portion of a code including one or more executable instructions for implementing the steps of a specific logical function or process. And the scope of the preferred embodiment of the present application includes other implementations, in which the functions may not be performed in the order shown or discussed, including in a substantially simultaneous manner or in a reverse order according to the functions involved.

[0161] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, which can be embodied in any computer-readable medium for use by an instruction execution system, apparatus or device (such as a computer-based system, a system including a processor or other system that can fetch instructions from an instruction execution system, apparatus or device and execute instructions), or used in combination with these instruction execution systems, apparatuses or devices.

[0162] It should be understood that the various parts of the present application can be implemented with hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented with software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above embodiment method can be completed by instructing the relevant hardware through a program, which can be stored in a computer-readable storage medium, and when the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0163] In addition, each functional unit in each embodiment of the present application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. If the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium can be a read-only memory, a disk or an optical disk, etc.

[0164] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A vulnerability information processing method, comprising: Identify the first component that an IoT device contains; Searching for vulnerability triggering information corresponding to the first component in a first vulnerability library; wherein the vulnerability triggering information is used to trigger the first component to call a vulnerability function to determine whether the first component has a vulnerability; The method also includes: reading identification information of the third component in the first vulnerability library, and acquiring multiple source codes corresponding to multiple versions of the third component based on the identification information; obtaining multiple binary files based on the multiple source codes; parsing the multiple binary files respectively to obtain multiple invariant sets corresponding to the multiple binary files, wherein the invariants in the invariant sets are field information that always exists in the process of compiling from source code to binary file; and obtaining at least one component identification feature of the third component based on the multiple invariant sets, wherein the at least one component identification feature is used to identify whether the IoT device includes the third component.

2. The method according to claim 1, wherein: The vulnerability triggering information includes the vulnerability function, function parameters for triggering the vulnerability function, and a preset return value; The function parameter is used to call the vulnerable function in the first component to obtain a return value of the vulnerable function; The preset return value is used to compare with the return value of the vulnerability function to determine whether the first component has a vulnerability.

3. The method according to claim 1, wherein: The method further comprises: Read vulnerability information in a second vulnerability database to determine a second component related to the vulnerability; Determining vulnerability triggering information of the second component based on the vulnerability information and the source code of the second component; The identification information of the second component and the vulnerability triggering information are stored in the first vulnerability library.

4. The method according to claim 1, wherein: The step of obtaining at least one component identification feature of the third component based on the multiple invariant sets is as follows: Includes at least one of the following steps: Eliminate invariants whose component coverage is greater than a first threshold from the intersection of the multiple invariant sets to obtain a first component identification feature of the third component; Based on the similarities between the multiple invariant sets, obtaining a second component identification feature of the third component; Based on specific character strings in the plurality of invariant sets, a regular expression is constructed, and the regular expression is used as a third component identification feature of the third component.

5. The method according to claim 4, wherein: The method further comprises: Based on the multiple invariant sets, at least one version identification feature of the first version among the multiple versions is obtained; wherein the at least one version identification feature is used to identify the version of the third component when the Internet of Things device includes the third component.

6. The method according to claim 5, wherein: The step of obtaining at least one version identification feature of a first version among the multiple versions based on the multiple invariant sets is as follows: Includes at least one of the following steps: Determine a difference set between a first invariant set in the multiple invariant sets and other invariant sets in the multiple invariant sets, and remove invariants whose occurrence frequency is greater than a second threshold from the difference set to obtain a first version identification feature of the first version; Obtaining a second version identification feature of the first version based on a similarity between the first invariant set and the other invariant sets; Based on the specific character string in the first invariant set, construct a regular expression, and use the regular expression as a third version identification feature of the first version; The first invariant set is an invariant set corresponding to the first version among the multiple invariant sets.

7. A vulnerability information processing method, comprising: Identify the first component that an IoT device contains; Sending identification information of the first component to a service device to obtain vulnerability triggering information corresponding to the first component searched by the service device in a first vulnerability database; Triggering the first component to call a vulnerability function based on the vulnerability triggering information to determine whether the first component has a vulnerability; The service device is further used to read identification information of the third component in the first vulnerability library, and obtain multiple source codes corresponding to multiple versions of the third component based on the identification information; obtain multiple binary files based on the multiple source codes; parse the multiple binary files respectively to obtain multiple invariant sets corresponding to the multiple binary files, wherein the invariants in the invariant sets are field information that always exists in the process of compiling from source code to binary file; obtain at least one component identification feature of the third component based on the multiple invariant sets, wherein the at least one component identification feature is used to identify whether the Internet of Things device includes the third component.

8. The method according to claim 7, wherein: The first component of determining the IoT device includes: Obtain identification features corresponding to component binary files of IoT devices; Based on the identification feature, determine a first component included in the Internet of Things device and / or a version of the first component.

9. The method according to claim 7 or 8, wherein: The obtaining of identification features corresponding to the binary files of components of the IoT device includes: Obtain identification information of a component binary file of the IoT device; Based on the identification information of the component binary file, an identification feature corresponding to the component binary file is downloaded from the cloud.

10. A service device, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 1 to 6 when executing the computer program.

11. A vulnerability detection module, used to be set in an Internet of Things device, the vulnerability detection module comprises a memory, a processor and a computer program stored in the memory, and the processor implements any one of claims 7-9 when executing the computer program.

12. An Internet of Things device, comprising the vulnerability detection module according to claim 11.

13. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

Images