CN111062040A

CN111062040A - Method for determining unknown vulnerability, server and computer readable storage medium

Info

Publication number: CN111062040A
Application number: CN201911315486.7A
Authority: CN
Inventors: 雷承霖
Original assignee: Chengdu Fengchuang Technology Co Ltd
Current assignee: Chengdu Fengchuang Technology Co Ltd
Priority date: 2019-12-19
Filing date: 2019-12-19
Publication date: 2020-04-24

Abstract

The application is applicable to the technical field of computer security, and provides a method, a server and a computer readable storage medium for determining unknown vulnerabilities, which comprises the following steps: acquiring a target vulnerability source file of a target known vulnerability and an expected execution result of the target vulnerability source file; controlling the equipment to be tested to execute the target vulnerability source file in the test environment to obtain an actual execution result of the target vulnerability source file; if the actual execution result is the same as the expected execution result, the unknown vulnerability identical to the target known vulnerability in the device to be tested is judged, so that a user can find the unknown vulnerability in the device to be tested, and the safety risk of the device to be tested is reduced.

Description

Method for determining unknown vulnerability, server and computer readable storage medium

Technical Field

The present application belongs to the field of computer security technologies, and in particular, to a method, a server, and a computer-readable storage medium for determining an unknown vulnerability.

Background

With the development of networking and intellectualization of industrial control systems and the continuous deepening of industrial internet construction, more and more general protocols, hardware and software are adopted in industrial control system products and are connected with public networks such as the internet in various ways, industrial control equipment, wireless access equipment, edge terminal equipment, important network equipment and the like designed by the industrial internet are gradually exposed with more and more security holes, and once the industrial control equipment is utilized by an attacker, the reliable operation of the equipment is seriously influenced. The traditional assessment of vulnerability of the industrial control system only focuses on discovery of security vulnerabilities, namely, only the discovered security vulnerabilities are simply listed and displayed, so that a user cannot find unknown security vulnerabilities in the industrial control system by browsing the displayed security vulnerabilities, and the security risk of the industrial control system is increased to a certain extent.

Disclosure of Invention

The embodiment of the application provides a method for determining an unknown bug, a server and a computer readable storage medium, which can enable a user to find the unknown bug existing in a device to be tested and reduce the security risk of the device to be tested.

In a first aspect, an embodiment of the present application provides a method for determining an unknown vulnerability, including:

obtaining a target exploit source file of a target known exploit and an expected execution result of the target exploit source file;

controlling the equipment to be tested to execute the target vulnerability source file in a test environment to obtain an actual execution result of the target vulnerability source file;

and if the actual execution result is the same as the expected execution result, judging that an unknown bug which is the same as the target known bug exists in the equipment to be tested.

Further, before obtaining the exploit source file of the known exploit and the expected execution result of the exploit source file, the method further includes:

acquiring vulnerability information of each known vulnerability from a public vulnerability database; the vulnerability information comprises vulnerability identification and original attribute information;

standardizing the original attribute information of each known bug based on a preset rule to obtain standardized attribute information of each known bug;

based on a vulnerability dictionary and standardized attribute information of each known vulnerability, performing duplicate removal processing on all the known vulnerabilities;

and storing the vulnerability identification of each known vulnerability remaining after the deduplication processing and the standardized attribute information into a preset vulnerability database in an associated manner.

Further, the vulnerability information also comprises a vulnerability source file and an expected execution result of the vulnerability source file; before the obtaining a target exploit source file of a target known exploit and an expected execution result of the target exploit source file, the method further includes:

storing the bug identification of each known bug, the bug source file and the expected execution result of the bug source file which are left after the deduplication processing into a preset bug file library in an associated manner;

correspondingly, the obtaining a target exploit source file of a target known exploit and an expected execution result of the target exploit source file include:

and acquiring a target vulnerability source file of the target known vulnerability and an expected execution result of the target vulnerability source file from the preset vulnerability file library.

Further, the vulnerability information also comprises a vulnerability patch file; the method for determining the unknown vulnerability further comprises the following steps:

and storing the vulnerability identification of each known vulnerability remaining after the deduplication processing and the vulnerability patch file into a preset vulnerability patch library in a correlation mode.

Further, after it is determined that an unknown bug the same as the known bug exists in the device under test, the method further includes:

acquiring a vulnerability patch file of the target known vulnerability from the preset vulnerability patch library;

and controlling the equipment to be tested to repair the unknown vulnerability based on the vulnerability patch file of the target known vulnerability.

Further, before controlling the device under test to execute the target exploit source file in the test environment, the method further includes:

constructing a target test environment matched with the target known vulnerability based on the standardized attribute information of the target known vulnerability;

correspondingly, the controlling the device to be tested to execute the target exploit source file in the test environment includes:

and accessing the equipment to be tested into the target test environment, and controlling the equipment to be tested to execute the target vulnerability source file in the target test environment.

Further, before the obtaining a target exploit source file of a target known exploit and an expected execution result of the target exploit source file, the method further includes:

detecting the port state of each asset device in a preset network area;

and determining the asset equipment with the port state being in an open state as the equipment to be tested.

In a second aspect, an embodiment of the present application provides a server, including:

the first obtaining unit is used for obtaining a target vulnerability source file of a target known vulnerability and an expected execution result of the target vulnerability source file;

the first testing unit is used for controlling the equipment to be tested to execute the target vulnerability source file in a testing environment to obtain an actual execution result of the target vulnerability source file;

and the judging unit is used for judging that the unknown vulnerability identical to the target known vulnerability exists in the equipment to be tested if the actual execution result is identical to the expected execution result.

In a third aspect, an embodiment of the present application provides a server, including:

a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the method for determining an unknown vulnerability as described in any of the first aspects above when executing the computer program.

In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the computer program implements the steps of the method for determining an unknown vulnerability according to any one of the above first aspects.

In a fifth aspect, an embodiment of the present application provides a computer program product, which, when running on a terminal device, causes the terminal device to execute a method for determining an unknown vulnerability according to any one of the above first aspects.

It is understood that the beneficial effects of the second aspect to the fifth aspect can be referred to the related description of the first aspect, and are not described herein again.

Compared with the prior art, the embodiment of the application has the advantages that:

according to the method for determining the unknown vulnerability, a target vulnerability source file of a target known vulnerability and an expected execution result of the target vulnerability source file are obtained; controlling the equipment to be tested to execute the target vulnerability source file in the test environment to obtain an actual execution result of the target vulnerability source file; if the actual execution result is the same as the expected execution result, it is determined that an unknown bug which is the same as the target known bug exists in the device to be tested.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

Fig. 1 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to an embodiment of the present disclosure;

fig. 2 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application;

FIG. 3 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to still another embodiment of the present application;

FIG. 4 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application;

FIG. 5 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application;

FIG. 6 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application;

FIG. 7 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application;

fig. 8 is a schematic structural diagram of a server provided in an embodiment of the present application;

fig. 9 is a schematic structural diagram of a server according to another embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to" determining "or" in response to detecting ". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

Fig. 1 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability, according to the present embodiment, an execution subject of the method for determining an unknown vulnerability is a server, and the server includes but is not limited to a smart phone, a tablet computer, or a desktop computer.

A method for determining an unknown vulnerability as shown in fig. 1 includes the following steps:

in S101, a target exploit source file of a target known exploit and an expected execution result of the target exploit source file are obtained.

In practical application, when a user needs to detect whether an unknown vulnerability exists in some asset devices, for example, needs to detect whether an unknown vulnerability exists in some network devices, the user may trigger a preset vulnerability detection request in a server. The asset device is a device connected to a public network such as the internet in various ways, including but not limited to: industrial control devices, wireless access devices, network devices, etc.

In this embodiment of the application, the server may detect that the user triggers the preset vulnerability detection request: and detecting that a user triggers a preset operation. The preset operation may be determined according to actual requirements, and is not limited herein. For example, the preset operation may be clicking a preset control, that is, if the server detects that the user clicks the preset control, the server considers that the preset operation is triggered, that is, the server considers that the user triggers the preset vulnerability detection request.

It can be understood that, when some asset devices are detected by the server for vulnerabilities, the server needs to be in communication connection with the asset devices so that data interaction can be performed between the server and the asset devices.

It should be noted that, in the embodiment of the present application, a vulnerability library and a vulnerability file library are preset in a server. The vulnerability database is used for storing vulnerability information of known vulnerabilities, and exemplarily, the vulnerability information includes vulnerability identification, attribute information and the like. The exploit library is used for storing an exploit source file corresponding to a known exploit and an expected execution result corresponding to the exploit source file.

In the embodiment of the application, the exploit source file is used for storing an exploit source code. The vulnerability exploitation source code is uncompiled program code written according to a certain programming language specification and is a series of computer language instruction sets. The Programming Language is used to define grammar rules of The computer program, and may be, for example, an object-oriented Programming Language such as The Combined Programming Language (C Language).

The expected execution result refers to a result expected to be obtained after the exploit source code is executed.

When the server detects a preset vulnerability detection request, a target vulnerability source file and an expected execution result of the target vulnerability source file of a target known vulnerability are obtained from the vulnerability file library. The target known vulnerability refers to a known vulnerability to be detected, and the target known vulnerability may be any known vulnerability in a vulnerability library. It is understood that, in the embodiment of the present application, the target known vulnerability may be one or more.

As an embodiment of the present application, when there are at least two target known vulnerabilities, the server may sequentially obtain a target exploit source file of the target known vulnerability and an expected execution result of the target exploit source file according to a preset sequence. The preset sequence may be set according to actual needs, and is not limited herein. For example, the preset sequence may be: and detecting the priority, namely the server can sequentially acquire the target exploit source file of the target known exploit and the expected execution result of the target exploit source file according to the detection priority from high to low.

In S102, the device to be tested is controlled to execute the target exploit source file in the test environment, so as to obtain an actual execution result of the target exploit source file.

It should be noted that the process of executing the target exploit source file is a process of attacking the device to be tested based on the target known exploit, and therefore, after the device to be tested executes the target exploit source file, the device to be tested or other related devices that are running may be affected to some extent, or even crashed. The testing environment is a virtual experimental environment constructed by the server.

Based on this, in the embodiment of the application, after the server obtains the target exploit source file with the known target exploit and the expected execution result of the target exploit source file, the device to be tested may be controlled to access the test environment, so that the device to be tested executes the target exploit source file in the test environment, and an actual execution result of the target exploit source file is obtained. The equipment to be tested refers to equipment needing vulnerability detection.

As an embodiment of the present application, in combination with S101, if a server obtains a target exploit source file and an expected execution result of the target exploit source file of at least two target known vulnerabilities, the server may sequentially control a device to be tested to execute the target exploit source file in a test environment according to a preset sequence. Therefore, the target vulnerability source file needing important testing can be guaranteed to be executed preferentially, and the execution processes among different target vulnerability source files cannot influence each other.

In the embodiment of the present application, there may be one or more devices under test.

In another embodiment of the present application, when there are at least two devices to be tested, the server may sequentially control the devices to be tested to execute the target exploit source file in the test environment according to a preset sequence. The preset sequence may be set according to actual needs, and is not limited herein. For example, the preset sequence may be: and testing the priority, namely the server can sequentially control the equipment to be tested to execute the target vulnerability source file in the testing environment according to the sequence from high to low of the testing priority.

In the embodiment of the application, after obtaining the actual execution result of the target exploit source file, the server compares the actual execution result of the target exploit source file with the expected execution result thereof. If the server detects that the actual execution result is the same as the expected execution result, the server executes S103.

In S103, if the actual execution result is the same as the expected execution result, it is determined that an unknown bug that is the same as the target known bug exists in the device under test.

In the embodiment of the application, when the server detects that the actual execution result is the same as the expected execution result, it is determined that an unknown bug which is the same as the target known bug exists in the device to be tested.

As an embodiment of the application, when the server detects that an actual execution result is different from an expected execution result, it is determined that an unknown bug identical to a target known bug does not exist in the device to be tested.

As another embodiment of the application, after determining that an unknown bug the same as a target known bug exists in the device to be tested, the server may generate and output first prompt information, where the first prompt information is used to prompt a user that the unknown bug exists in the device to be tested.

As can be seen from the above, in the method for determining an unknown vulnerability provided in the embodiment of the present application, a target vulnerability source file of a target known vulnerability and an expected execution result of the target vulnerability source file are obtained; controlling the equipment to be tested to execute the target vulnerability source file in the test environment to obtain an actual execution result of the target vulnerability source file; if the actual execution result is the same as the expected execution result, it is determined that an unknown bug which is the same as the target known bug exists in the device to be tested.

Referring to fig. 2, fig. 2 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application. In this embodiment, relative to the embodiment corresponding to fig. 1, the method for determining an unknown vulnerability provided in this embodiment may further include, before S101, implementation in S01 to S04 shown in fig. 2, which is detailed as follows:

in S01, acquiring vulnerability information of each known vulnerability from the public vulnerability database; the vulnerability information comprises vulnerability identification and original attribute information.

In this embodiment, before the server performs vulnerability detection on the device to be tested, vulnerability information of each known vulnerability may be obtained from the public vulnerability database. Specifically, the server may use an automatic collection tool to obtain vulnerability information for each known vulnerability from the public vulnerability database. The vulnerability information comprises vulnerability identification and original attribute information. In practical applications, public vulnerability databases include, but are not limited to: a national information security vulnerability library, a national information security vulnerability sharing platform and the like. Automated collection tools include, but are not limited to: a security vulnerability detection tool (metaspoit), a vulnerability information collection platform (explicit-DB), and the like.

It should be noted that, in this embodiment, the vulnerability identifier may be a serial number of the vulnerability, and the original attribute information includes, but is not limited to: vulnerability name, vulnerability details, vulnerability score, model of the specific device affected by the vulnerability, and the like.

As an embodiment of the application, the server may obtain vulnerability information of each known vulnerability from the public vulnerability database based on a preset time interval, so as to obtain latest vulnerability information of the known vulnerability in time. The preset time interval may be set according to actual needs, and is not limited herein.

As another embodiment of the present application, the server may obtain vulnerability information of each known vulnerability from the public vulnerability database based on preset requirements. The preset requirement may be set according to actual needs, and is not limited herein. For example, the preset requirement may be a degree of damage of a known vulnerability, that is, the server may obtain vulnerability information of a known vulnerability with a high degree of damage from the public vulnerability database according to the degree of damage of the known vulnerability.

In S02, the original attribute information of each known vulnerability is standardized based on a preset rule, so as to obtain standardized attribute information of each known vulnerability.

In practical application, vulnerability information of known vulnerabilities is acquired from different public vulnerability databases, formats of vulnerability information provided by the databases are different, and original attribute information included in the vulnerability information is different, so that the collected original attribute information of the vulnerability information needs to be standardized to obtain standardized attribute information of the known vulnerabilities.

Based on this, in this embodiment, after the server obtains the vulnerability information of the known vulnerabilities, the server performs standardization processing on the original attribute information of each known vulnerability based on a preset rule to obtain standardized attribute information of each known vulnerability. The preset rule may be set according to actual needs, and is not limited here. For example, the preset rule may be that information of the known vulnerabilities uniformly includes vulnerabilities titles, vulnerabilities details, vulnerability scores, and specific devices affected by the vulnerabilities.

In S03, all the known vulnerabilities are deduplicated based on the vulnerability dictionary and the standardized attribute information of each of the known vulnerabilities.

In this embodiment, after obtaining the standardized attribute information of each known bug, the server performs deduplication processing on all known bugs based on the bug dictionary and the standardized attribute information of each known bug. Specifically, the server compares the standardized attribute information of each known bug one by one according to the bug dictionary and the standardized attribute information of each known bug, and if at least two known bugs with the substantially same standardized attribute information exist, the server performs deduplication processing on the known bugs. Wherein, the deduplication processing means to eliminate known vulnerabilities with substantially the same standardized attribute information.

It should be noted that the vulnerability dictionary refers to a tool for giving a Common name to widely recognized known Vulnerabilities, and may be, for example, Common Vulnerabilities and Exposures (CVE).

In S04, the vulnerability identity and the standardized attribute information of each remaining known vulnerability after the deduplication processing are stored in a preset vulnerability library in an associated manner.

In this embodiment, after the server performs deduplication processing on all known vulnerabilities, the vulnerability identification and the standardized attribute information of each remaining known vulnerability after deduplication processing are stored in a preset vulnerability database in an associated manner.

As can be seen from the above, in the method for determining an unknown vulnerability provided by this embodiment, vulnerability information of each known vulnerability is obtained from the public vulnerability database; standardizing the original attribute information of each known bug based on a preset rule to obtain standardized attribute information of each known bug; based on the vulnerability dictionary and the standardized attribute information of each known vulnerability, performing duplicate removal processing on all known vulnerabilities; the vulnerability identification and the standardized attribute information of each residual known vulnerability after duplicate removal processing are stored in the preset vulnerability database in an associated mode, the latest known vulnerability information can be stored in the preset vulnerability database in real time, moreover, the server can conveniently acquire the corresponding known vulnerability according to needs by carrying out standardized processing on the vulnerability information of the known vulnerability, vulnerability searching time is saved, and vulnerability acquisition efficiency is improved.

Referring to fig. 3, fig. 3 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to still another embodiment of the present application. With respect to the embodiment corresponding to fig. 2, in the method for determining an unknown vulnerability provided in this embodiment, the vulnerability information further includes a vulnerability source file and an expected execution result of the vulnerability source file, based on which, before S101, S05 may be further included, and accordingly, S101 specifically includes S1011, which is detailed as follows:

in S05, storing the bug identifications of the known bugs, the bug source files, and the expected execution results of the bug source files, which are left after the deduplication processing, in a preset bug file library in an associated manner.

In this embodiment, the vulnerability information of the known vulnerability further includes a vulnerability source file and an expected execution result of the vulnerability source file, and therefore, after the server performs deduplication processing on the known vulnerability, the vulnerability identifier of each known vulnerability remaining after the deduplication processing, the vulnerability source file, and the expected execution result of the vulnerability source file are stored in the preset vulnerability file library in an associated manner. Wherein the exploit source file is used for storing the exploit source code.

In practical applications, the exploit source codes of known vulnerabilities may be one or more groups, and therefore, the exploit source file corresponding to the known vulnerability includes at least one group of exploit source codes.

In S1011, a target exploit source file of the target known exploit and an expected execution result of the target exploit source file are obtained from the preset exploit file library.

In this embodiment, since the server is preset with the preset exploit file library, and the vulnerability identifier of the known vulnerability, the exploit source file, and the expected execution result of the exploit source file are stored in the preset exploit file library in an associated manner, the server can obtain the target exploit source file of the target known vulnerability and the expected execution result of the target exploit source file from the preset exploit file library.

It is understood that, in the present embodiment, the target known vulnerability may be one or more.

As an embodiment of the application, when there are at least two target known vulnerabilities, the server may sequentially obtain, according to a preset order, a target vulnerability source file of the target known vulnerabilities and an expected execution result of the target vulnerability source file from a preset vulnerability file library. The preset sequence may be set according to actual needs, and is not limited herein. For example, the preset sequence may be: and detecting the priority, namely the server can sequentially obtain a target vulnerability source file of the target known vulnerability and an expected execution result of the target vulnerability source file from a preset vulnerability file library according to the sequence from high to low of the detection priority.

As an embodiment of the present application, in order to avoid that an unknown vulnerability is attacked and utilized, after finding the unknown vulnerability, the server may control the device to be tested to perform corresponding repair on the unknown vulnerability, based on this, in this embodiment, the vulnerability information may further include a vulnerability patch file corresponding to a vulnerability source file, and based on this, after S04, the implementation may further include S06 as shown in fig. 4, which is detailed as follows:

in S06, storing the bug identifications of the known bugs remaining after the deduplication processing in a preset bug patch library in association with the bug patch files.

In this embodiment, each known vulnerability is configured with a vulnerability patch file corresponding to its vulnerability source file. After the server performs deduplication processing on the known vulnerabilities, vulnerability identifications and vulnerability patch files of the known vulnerabilities remaining after the deduplication processing can be stored in a preset vulnerability patch library in an associated mode.

As can be seen from the above, in the method for determining an unknown vulnerability provided in this embodiment, the vulnerability identification, the vulnerability source file, and the expected execution result of the vulnerability source file of each remaining known vulnerability after deduplication processing are stored in the preset vulnerability file library in an associated manner, and the target vulnerability source file of the target known vulnerability and the expected execution result of the target vulnerability source file are obtained from the preset vulnerability file library, so that when a server needs to obtain the vulnerability source file to detect a device to be tested, the server can be directly obtained from the preset vulnerability file library based on the vulnerability identification, internet searching is not needed, and the working efficiency of the server is improved.

Referring to fig. 5, fig. 5 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application. In this embodiment, relative to the embodiment corresponding to fig. 1, after S103, the method for determining an unknown vulnerability provided in this embodiment may further include implementation in S104 to S105 shown in fig. 5, which is described in detail as follows:

in S104, obtaining the vulnerability patch file of the target known vulnerability from the preset vulnerability patch library.

In this embodiment, after the server determines that an unknown bug the same as the target known bug exists in the device to be tested, in order to avoid the unknown bug being attacked and utilized, and thus causing the device to be tested to malfunction, the server obtains a bug patch file of the target known bug from a preset bug patch library. Specifically, the server obtains a vulnerability patch file of the target known vulnerability, which is stored in association with the vulnerability identification of the target known vulnerability, from a preset vulnerability patch library based on the vulnerability identification of the target known vulnerability.

In S105, controlling the device to be tested to repair the unknown vulnerability based on the vulnerability patch file of the target known vulnerability.

In this embodiment, after the server obtains the vulnerability patch file of the target known vulnerability, the server controls the device to be tested to repair the unknown vulnerability based on the vulnerability patch file of the target known vulnerability.

As can be seen from the above, in the method for determining an unknown vulnerability provided by this embodiment, a vulnerability patch file of a target known vulnerability is obtained from a preset vulnerability patch library; and controlling the device to be tested to repair the unknown bug based on the bug patch file of the target known bug, so that the unknown bug of the device to be tested is prevented from being attacked and utilized, and the safety factor of the device to be tested is improved.

Referring to fig. 6, fig. 6 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application. With respect to the embodiment corresponding to fig. 1, the method for determining an unknown vulnerability provided in this embodiment may further include, before S102, S201 shown in fig. 6, and accordingly, S102 specifically includes S1021, which is detailed as follows:

in S201, a target test environment matched with the target known vulnerability is constructed based on the standardized attribute information of the target known vulnerability.

In practical application, because the process of executing the target exploit source file is a process of attacking the device to be tested based on the target known exploit source file, after the device to be tested executes the target exploit source file, certain influence or even breakdown is generated on the device to be tested or other related devices which are running, so that in order to avoid the above situations, a test environment needs to be constructed in advance. Further, in order to enable the target vulnerability source file to normally run, a target test environment matched with the target known vulnerability needs to be constructed based on the standardized attribute information of the target known vulnerability.

Based on this, in this embodiment, after obtaining the target exploit source file of the target known vulnerability and the expected execution result of the target exploit source file, the server constructs a target test environment matched with the target known vulnerability based on the standardized attribute information of the target known vulnerability.

As an embodiment of the present application, in combination with S101, if a server obtains a target exploit source file and an expected execution result of the target exploit source file of at least two target known vulnerabilities, a target test environment matched with the target known vulnerabilities may be sequentially constructed according to a preset order. The preset sequence may be set according to actual needs, and is not limited herein. For example, the preset sequence may be: and constructing the priority, namely the server can sequentially construct the target test environment matched with the known target vulnerability according to the sequence from high to low of the construction priority.

In S1021, the device under test is accessed to the target test environment, and the device under test is controlled to execute the target exploit source file in the target test environment.

In this embodiment, after the server constructs a target test environment matched with the known target vulnerability, the device to be tested is accessed to the target test environment, and the device to be tested is controlled to execute the target vulnerability utilization source file in the target test environment.

As an embodiment of the present application, in combination with S201, if the server constructs at least two target test environments, the server may sequentially access the device to be tested to the target test environments according to the sequence from high to low detection priority, and control the device to be tested to execute the target exploit source file in the target test environments. Therefore, the target vulnerability source file needing important testing can be guaranteed to be executed preferentially, and the execution processes among different target vulnerability source files cannot influence each other.

As another embodiment of the present application, when there are at least two devices to be tested, the server may sequentially control the devices to be tested to execute the target exploit source file in the target test environment according to a preset sequence. The preset sequence may be set according to actual needs, and is not limited herein. For example, the preset sequence may be: and testing the priority, namely the server can sequentially control the equipment to be tested to execute the target vulnerability source file in the target testing environment according to the sequence from high to low of the testing priority.

As can be seen from the above, in the method for determining an unknown vulnerability, a target test environment matched with a target known vulnerability is established based on standardized attribute information of the target known vulnerability, the device to be tested is accessed to the target test environment, and the device to be tested is controlled to execute a target vulnerability source file in the target test environment, so that the target vulnerability source file can be normally executed in the device to be tested, and other devices are not affected and do not interfere with each other.

Referring to fig. 7, fig. 7 is a flowchart illustrating an implementation of a method for determining an unknown vulnerability according to another embodiment of the present application. With respect to the embodiment corresponding to fig. 1, before S101, the method for determining an unknown vulnerability provided in this embodiment may further include S001 to S002 shown in fig. 7, which are detailed as follows:

in S001, the port states of the asset devices in the preset network area are detected.

In this embodiment, when the server detects the preset vulnerability detection request, the server detects the port states of the asset devices in the preset network area. The network area refers to a range of Internet Protocol addresses (IP addresses). The preset network area refers to a range of an IP address to which the asset device to be detected belongs, and the preset network area may be set according to actual needs, which is not limited herein.

It should be noted that, in this embodiment, a port refers to a port in a Transmission Control Protocol (TCP)/Internet Protocol (IP), which is a logical port. Wherein, one IP address can have a plurality of ports, and one port corresponds to one asset device.

As an embodiment of the present application, the server may detect, by using a preset scanning tool, a port state of each asset device in a preset network area. The preset scanning tool can be determined according to actual needs, and is not limited herein.

As another embodiment of the present application, when the server detects the port state of each asset device in the preset network area, each asset device may also be detected based on the port detection list. The port detection list is used for storing the corresponding relation between each port and each asset device.

In this embodiment, when the server detects the port state of each asset device in the preset area, if the asset device whose port state is the open state is detected, S002 is executed.

In S002, the asset device whose port state is the open state is determined as the device under test.

In this embodiment, when the server detects an asset device whose port state is in an open state, it is determined that the asset device can be accessed, and meanwhile, the port of the asset device returns specific information of the asset device, where the specific information includes, but is not limited to: model number and software version, etc. Therefore, the server determines the asset device as a device to be tested and obtains the specific model of the asset device.

As can be seen from the above, the method for determining an unknown vulnerability provided by this embodiment detects the port states of each asset device in a preset network region; the asset equipment with the port state in the open state is determined as the equipment to be tested, so that the server can determine which asset equipment can become the equipment to be tested according to the port state, the equipment to be tested does not need to be determined manually, the operation is simple, and the detection efficiency is improved.

It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Corresponding to the method for determining an unknown vulnerability described in the foregoing embodiments, fig. 7 shows a structural block diagram of a server provided in the embodiments of the present application, and for convenience of description, only a part related to the embodiments of the present application is shown.

Referring to fig. 8, the server 800 includes: a first acquisition unit 81, a first test unit 82, and a determination unit 83. Wherein:

the first obtaining unit 81 is configured to obtain a target exploit source file of a target known exploit and an expected execution result of the target exploit source file.

The first testing unit 82 is configured to control the device under test to execute the target exploit source file in the testing environment, so as to obtain an actual execution result of the target exploit source file.

The determining unit 83 is configured to determine that an unknown bug identical to the target known bug exists in the device under test if the actual execution result is identical to the expected execution result.

As an embodiment of the present application, the server 800 may further include: the device comprises a second acquisition unit, a processing unit, a duplicate removal unit and a first storage unit. Wherein:

the second acquisition unit is used for acquiring vulnerability information of each known vulnerability from the public vulnerability database; the vulnerability information comprises vulnerability identification and original attribute information.

The processing unit is used for carrying out standardization processing on the original attribute information of each known bug based on a preset rule to obtain the standardized attribute information of each known bug.

And the duplication removing unit is used for carrying out duplication removing processing on all the known bugs based on the bug dictionary and the standardized attribute information of the known bugs.

And the first storage unit is used for storing the bug identification and the standardized attribute information of each known bug which are left after the deduplication processing into a preset bug library in an associated manner.

As an embodiment of the present application, the exploit information further includes an exploit source file and an expected execution result of the exploit source file; the server 800 may further include: the second storage unit, correspondingly, the first obtaining unit specifically includes: and a third acquisition unit. Wherein:

and the second storage unit is used for storing the bug identification of each known bug, the bug source file and the expected execution result of the bug source file which are left after the deduplication processing into a preset bug file library in an associated manner.

The third obtaining unit is used for obtaining a target vulnerability source file of the target known vulnerability and an expected execution result of the target vulnerability source file from the preset vulnerability file library.

As an embodiment of the present application, the exploit information further includes an exploit source file and an expected execution result of the exploit source file; the server 800 may further include: and a third storage unit. Wherein:

and the third storage unit is used for storing the bug identification of each known bug left after the deduplication processing and the bug patch file into a preset bug patch library in a correlation manner.

As an embodiment of the present application, the server 800 may further include: a fourth acquisition unit and a repair unit. Wherein:

and the fourth obtaining unit is used for obtaining the vulnerability patch file of the target known vulnerability from the preset vulnerability patch library.

And the repairing unit is used for controlling the equipment to be tested to repair the unknown bug based on the bug patch file of the target known bug.

As an embodiment of the present application, the server 800 may further include: the building unit, correspondingly, first test unit specifically includes: a second test unit. Wherein:

the construction unit is used for constructing a target test environment matched with the target known vulnerability based on the standardized attribute information of the target known vulnerability.

The second testing unit is used for accessing the equipment to be tested into the target testing environment and controlling the equipment to be tested to execute the target vulnerability utilizing source file in the target testing environment.

As an embodiment of the present application, the server 800 may further include: a detection unit and a determination unit.

Wherein:

the detection unit is used for detecting the port state of each asset device in a preset network area.

The determining unit is configured to determine the asset device with the port state being an open state as the device under test.

As can be seen from the above, the server provided by the application obtains a target exploit source file of a target known exploit and an expected execution result of the target exploit source file; controlling the equipment to be tested to execute the target vulnerability source file in the test environment to obtain an actual execution result of the target vulnerability source file; if the actual execution result is the same as the expected execution result, it is determined that an unknown bug which is the same as the target known bug exists in the device to be tested.

It should be noted that, for the information interaction, the execution process, and other contents between the above units, the specific functions and the technical effects of the embodiments of the method of the present application are based on the same concept, and specific reference may be made to the above embodiments of the method, and details are not described here.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

Fig. 9 is a schematic structural diagram of a server according to an embodiment of the present application. As shown in fig. 9, the server 9 of this embodiment includes: at least one processor 90 (only one shown in fig. 9), a memory 91, and a computer program 92 stored in the memory 91 and executable on the at least one processor 90, the processor 90 implementing the steps in any of the above method embodiments of determining an unknown vulnerability when executing the computer program 92.

The server 9 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The server may include, but is not limited to, a processor 90, a memory 91. Those skilled in the art will appreciate that fig. 9 is merely an example of the server 9, and does not constitute a limitation on the server 9, and may include more or less components than those shown, or combine certain components, or different components, such as input output devices, network access devices, etc.

The Processor 90 may be a Central Processing Unit (CPU), and the Processor 90 may be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The storage 91 may in some embodiments be an internal storage unit of the server 9, such as a hard disk or a memory of the server 9. The memory 91 may also be an external storage device of the server 9 in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, which are provided on the server 9. Further, the memory 91 may also include both an internal storage unit of the server 9 and an external storage device. The memory 91 is used for storing an operating system, an application program, a BootLoader (BootLoader), data, and other programs, such as program codes of the computer program. The memory 91 may also be used to temporarily store data that has been output or is to be output.

An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored, and when being executed by a processor, the computer program may implement the steps in any of the above method embodiments for determining an unknown vulnerability.

The embodiment of the present application provides a computer program product, which when running on a mobile terminal, enables the mobile terminal to implement the steps in any one of the above method embodiments for determining an unknown vulnerability when executed.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium and can implement the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a photographing apparatus/terminal apparatus, a recording medium, computer Memory, Read-Only Memory (ROM), random-access Memory (RAM), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a usb-disk, a removable hard disk, a magnetic or optical disk, etc. In certain jurisdictions, computer-readable media may not be an electrical carrier signal or a telecommunications signal in accordance with legislative and patent practice.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed method and server for determining an unknown vulnerability may be implemented in other manners. For example, the above-described server embodiments are merely illustrative, and for example, the division of the modules or units is only one logical functional division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. A method for determining an unknown vulnerability, comprising:

2. The method of determining an unknown vulnerability of claim 1, wherein before obtaining the vulnerability source file of a known vulnerability and the expected execution result of the vulnerability source file, further comprising:

3. The method of determining an unknown vulnerability of claim 2, wherein the vulnerability information further includes a vulnerability source file and an expected execution result of the vulnerability source file; before the obtaining a target exploit source file of a target known exploit and an expected execution result of the target exploit source file, the method further includes:

4. The method of determining an unknown vulnerability of claim 2, wherein the vulnerability information further includes vulnerability patch files; the method for determining the unknown vulnerability further comprises the following steps:

5. The method according to claim 4, wherein after determining that there is an unknown vulnerability identical to the known vulnerability in the device under test, the method further comprises:

6. The method for determining an unknown vulnerability of claim 2, wherein before controlling the device under test to execute the target vulnerability source file in the test environment, further comprising:

7. The method for determining an unknown vulnerability according to any of claims 1 to 6, wherein before obtaining the target vulnerability source file of the target known vulnerability and the expected execution result of the target vulnerability source file, further comprising:

detecting the port state of each asset device in a preset network area;

8. A server, comprising:

9. A server, comprising: memory, processor and computer program stored in the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 7.