Vulnerability scanning method and device, storage medium and computer equipment

Abstract

The embodiment of the invention provides a vulnerability scanning method and device, a storage medium and computer equipment, and the method comprises the steps: obtaining a flow graph description which is obtained by compiling the concept verification names of a plurality of concept verifications in a concept verification library according to a flow graph rule; converting the flow graph description into a syntax tree, wherein the syntax tree comprises a concept verification name of each concept verification and an execution rule between the concept verifications; and calling each concept verification according to an execution rule in the syntax tree to perform vulnerability scanning to obtain a scanning result, and expressing combinational logic of a plurality of POCs in an abstract mode of a flow graph rule through flow graph description, so that the computer equipment converts the flow graph description into the syntax tree, and performs vulnerability scanning on the syntax tree. According to the method, the execution rule between the POCs is visually presented in a tree form, so that each POC is called in sequence for vulnerability scanning, the POCs stored in a POC library are prevented from being recompiled, and the POC reusability and vulnerability scanning efficiency are improved.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a vulnerability scanning method, device, storage medium and computer equipment. Background Art

[0002] Vulnerability scanning is an important part of network security management, which helps organizations protect their assets from potential attacks. Through regular vulnerability scanning, organizations can promptly discover and fix security vulnerabilities and reduce the risk of being attacked. Proof of Concept (POC) in vulnerability scanning refers to a description or an example of an attack. POC is used to verify whether a discovered vulnerability actually exists and the extent of the vulnerability. It can help security researchers show how to exploit vulnerabilities to attack, obtain sensitive information, or damage the system.

[0003] In the related art, some simple POCs are stored in the POC library. When users need to perform complex vulnerability scans and involve the combined use of some POCs in the POC library, the specific implementation codes of these POCs need to be recompiled, resulting in poor POC reusability and reduced vulnerability scanning efficiency. Therefore, the related art urgently needs to propose a vulnerability scanning method to solve the above technical problems. Summary of the invention

[0004] The main purpose of this application is to provide a vulnerability scanning method, apparatus, storage medium and computer equipment, which can avoid recompiling the POC stored in the POC library, improve the reusability of the POC and the efficiency of vulnerability scanning.

[0005] In a first aspect, an embodiment of the present application provides a vulnerability scanning method, comprising: Obtain a flow graph description, where the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in the concept verification library according to the flow graph rule; Converting the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; Each of the concept verifications is called according to the execution rules in the syntax tree to perform vulnerability scanning and obtain a scanning result.

[0006] In a second aspect, an embodiment of the present application provides a vulnerability scanning device, including: An acquisition unit is used to acquire a flow graph description, where the flow graph description is obtained by compiling concept verification names of multiple concept verifications in a concept verification library according to a flow graph rule; A conversion unit, configured to convert the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; The vulnerability scanning unit is used to call each of the concept verifications according to the execution rules in the syntax tree to perform vulnerability scanning and obtain scanning results.

[0007] In a third aspect, an embodiment of the present application provides a storage medium, wherein the computer-readable storage medium stores a plurality of instructions, which are suitable for loading by a processor to execute any of the vulnerability scanning methods described above.

[0008] In a fourth aspect, an embodiment of the present application provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements any of the above vulnerability scanning methods when executing the computer program.

[0009] In an embodiment of the present application, a flow graph description is obtained by compiling the proof-of-concept names of multiple proof-of-concepts in a proof-of-concept library according to flow graph rules; the flow graph description is converted into a syntax tree, the syntax tree includes the proof-of-concept name of each of the proof-of-concepts, and the execution rules between each of the proof-of-concepts; each of the proof-of-concepts is called according to the execution rules in the syntax tree to perform a vulnerability scan to obtain a scan result. Compared with the related art, when some POCs in the POC library are used in combination, it is necessary to recompile the specific implementation codes of these POCs. In the embodiment of the present application, the combination logic of multiple POCs is represented in an abstract manner of flow graph rules through a flow graph description, so that the computer device converts the flow graph description into a syntax tree, and intuitively presents the execution rules between POCs in a tree form, so that each POC is called in turn for vulnerability scanning, avoiding recompilation of POCs stored in the POC library, and improving POC reusability and vulnerability scanning efficiency.

[0010] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0012] Figure 1 A schematic diagram of combining and using certain POCs in a POC library in the related technology provided in an embodiment of the present application.

[0013] Figure 2 A scenario diagram of a vulnerability scanning system provided in an embodiment of the present application.

[0014] Figure 3 A flowchart of a vulnerability scanning method provided in an embodiment of the present application.

[0015] Figure 4 A schematic diagram of the interaction framework between the client and the server provided in an embodiment of the present application.

[0016] Figure 5 A schematic diagram of the structure of a vulnerability scanning device provided in an embodiment of the present application.

[0017] Figure 6 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0019] It should be noted that in some processes described in the specification, claims and the above-mentioned drawings, multiple steps appearing in a specific order are included, but it should be clearly understood that these steps may not be executed in the order in which they appear in this document or may be executed in parallel. The step numbers are only used to distinguish different steps, and the numbers themselves do not represent any execution rules. In addition, descriptions such as "first", "second" or "target" in this document are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0020] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations: Proof of Concept (POC), in the field of cybersecurity, POC usually refers to a piece of code or a method used to verify whether a specific vulnerability exists in the target system. After security researchers discover a potential vulnerability, they will write a POC to prove that the vulnerability can be exploited. For example, for a software that may have an input validation vulnerability, the POC may be a piece of code that causes the software to behave abnormally (such as crashing or leaking information) when a specific character is entered.

[0021] Here is a simple example of a vulnerability scan using a POC (Proof of Concept): SQL injection vulnerability scanning,SQL injection is a common web application vulnerability. Attackers may obtain sensitive information in the database, tamper with data, or perform unauthorized database operations by injecting malicious SQL statements into user input fields (such as login forms, search boxes, etc.).

[0022] For example, there is a simple World Wide Web (Web) application that has a login page where the user needs to enter a username and password to log in. The application uses SQL statements in the background to validate the user input, such as: A normal SQL query statement may be: SELECT * FROM users WHERE username = 'user_input_username' AND password = 'user_input_password'; The POC constructed by the attacker (to verify whether there is a SQL injection vulnerability) may be as follows: In the User Name input box, enter: 'OR'1'='1 Enter any password (such as 123).

[0023] At this point, the SQL statement actually executed by the application background becomes: SELECT * FROM users WHERE username = '' OR '1' = '1' AND password = '123'; Since the '1'='1' condition is always true, this maliciously constructed input may bypass normal login verification, causing the application to mistakenly allow attackers to log in, which verifies that the web application has a SQL injection vulnerability.

[0024] POC usage during vulnerability scanning Vulnerability scanning tools include POCs for common vulnerabilities such as SQL injection.

[0025] The scanner will automatically send malicious input similar to the above structure to various places in the target web application where user input may exist (such as forms, query parameters, etc.).

[0026] The scanner will then determine whether there is a SQL injection vulnerability based on the response of the target application. For example, if after sending malicious input, you can successfully log in to an account that you should not log in to, or get a database-related error message, the scanner will report that a SQL injection vulnerability has been found.

[0027] This is just a simple example of a POC for vulnerability scanning. In the actual field of network security, there are also POCs for various vulnerabilities such as cross-site scripting (XSS), file inclusion vulnerabilities, remote command execution vulnerabilities, etc., which are used to discover and verify security risks in the target system.

[0028] In the related art, some simple POCs are stored in the POC library for users to use when performing vulnerability scanning. However, when users need to perform complex vulnerability scanning and involve the combined use of certain POCs in the POC library, the specific implementation codes of these POCs need to be recompiled to form a new POC, resulting in poor reusability of the POC and reduced vulnerability scanning efficiency.

[0029] Flow Graph is a graphical representation method used to describe the flow relationship between various elements in a system. It consists of nodes and edges. Nodes usually represent entities, states, operations or events in the system, while edges represent the relationship between these nodes, such as the flow direction of data, the transfer order of control, the execution order of operations, etc.

[0030] like Figure 1 As shown, Figure 1 A schematic diagram of combining and using certain POCs in a POC library in the related technology provided in an embodiment of the present application.

[0031] The user expects the vulnerability scan to execute the following rules: after A is executed, BC is executed several times in a loop, and then D is executed. Since the existing tools do not support the POC loop rule, the target POC has to add redundant POC implementations. That is, all the implementation codes of POC B and POC C are recompiled into a new POC E, so that the final POC includes POC A, POC E, and POC D. Since all the implementation codes of POC B and POC C are recompiled into a new POC E, the compilation content included in POCE is lengthy and complex, and since it is manually compiled, compilation errors are easily caused, resulting in poor reusability of POC and reduced vulnerability scanning efficiency.

[0032] In order to solve the above problems, the embodiment of the present application obtains a flow graph description, which is obtained by compiling the concept verification names of multiple concept verifications in the concept verification library according to the flow graph rules; converting the flow graph description into a syntax tree, which includes the concept verification name of each concept verification and the execution rules between each concept verification; calling each concept verification according to the execution rules in the syntax tree to perform vulnerability scanning to obtain the scanning result. Compared with the related art, when some POCs in the POC library are used in combination, it is necessary to recompile the specific implementation code of these POCs. The embodiment of the present application uses the flow graph description to represent the combination logic of multiple POCs in an abstract way of flow graph rules, so that the computer device converts the flow graph description into a syntax tree, and intuitively presents the execution rules between POCs in a tree form, so as to call each POC in turn for vulnerability scanning, avoid recompiling the POCs stored in the POC library, and improve the reusability of POCs and the efficiency of vulnerability scanning. Please continue to refer to the following specific embodiments for details.

[0033] See also Figure 2 , Figure 2 A schematic diagram of a vulnerability scanning system provided in an embodiment of the present application, which includes a client 110, the Internet 130, a gateway 120, a server 140, etc.

[0034] The client 110 includes but is not limited to pre-configured electronic devices such as desktop computers, laptop computers, tablet computers, etc. In addition, it can be a single device or a collection of multiple devices. The client 110 can communicate with the Internet 130 in a wired or wireless manner to exchange data.

[0035] The server 140 refers to a computer system that can provide certain services to the client 110. Compared with the common client 110, the server 140 has higher requirements in terms of stability, security, performance, etc. The server 140 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a part of a high-performance computer (such as a virtual machine), a combination of parts of multiple high-performance computers (such as virtual machines), etc.

[0036] The gateway 120 is also called an internetwork connector or a protocol converter. The gateway realizes network interconnection at the transport layer and is a computer system or device that acts as a converter. The gateway is a translator between two systems that use different communication protocols, data formats or languages, or even completely different architectures. At the same time, the gateway can also provide filtering and security functions. The message sent by the client 110 to the server 140 must be sent to the corresponding server 140 through the gateway 120. The message sent by the server 140 to the client 110 must also be sent to the corresponding client 110 through the gateway 120.

[0037] The vulnerability scanning method of the disclosed embodiment may be implemented on the server 140 .

[0038] It should be noted that Figure 2 The scenario diagram of the vulnerability scanning system shown is only an example. The vulnerability scanning system and scenario described in the embodiment of the present application are intended to more clearly illustrate the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided in the embodiment of the present application. Ordinary technicians in this field can know that with the evolution of image processing technology and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

[0039] In this embodiment, the description will be made from the perspective of a vulnerability scanning device, which can be specifically integrated in a client having a storage unit and a microprocessor installed therein and having computing capabilities.

[0040] See also Figure 3 , Figure 3 A schematic diagram of a vulnerability scanning method provided in an embodiment of the present application. The vulnerability scanning method includes: In step 201, a flow graph description is obtained, where the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in a concept verification library according to a flow graph rule.

[0041] The flow graph is described by treating the existing POC as flow graph point elements, and the flow graph rules as flow graph edge elements. Point elements and edge elements construct new complex POCs. Flow graph rules are a series of criteria used to define and constrain the relationship and behavior between points and edges in the flow graph. These rules determine how information, data, control flow, etc. are transmitted, processed, and interacted in the system or process described by the flow graph. Flow graph rules cover control branch rules, loop rules, sequential execution rules, etc.

[0042] For example, a flow graph description is “flow: POC A&&POC B”, which includes the proof-of-concept names of two proofs of concepts, namely, POC A and POC B, and “&&” is the flow graph rule.

[0043] In step 202, the flow graph description is converted into a syntax tree, where the syntax tree includes a proof-of-concept name of each proof-of-concept and execution rules between each proof-of-concept.

[0044] Among them, since the flow graph description is a relatively complex text representation, it contains the execution rules and logical relationships between multiple proofs of concept (POC). Therefore, in order for the computer device to perform corresponding processing according to the flow graph description, it needs to be converted into a syntax tree to display these relationships in a more intuitive and clear tree structure.

[0045] For example, the syntax tree includes the proof-of-concept name of each proof-of-concept and the execution rules between each proof-of-concept. Through the nodes and branches, it is easy to see whether the execution order of different POCs is serial or parallel, whether there are conditional branches (such as selecting different POC execution paths according to different conditions), etc. This clear representation method helps computer devices better understand the execution rules of the entire vulnerability scanning process.

[0046] In some implementations, converting the flow graph description into a syntax tree includes: (1) performing lexical analysis on the flow graph description to obtain a plurality of lexical units; (2) filtering out the rule lexical unit corresponding to the flow graph rule from the plurality of lexical units, and filtering out each concept verification name; (3) determining the execution rule corresponding to each of the rule lexical units; (4) Performing grammatical analysis on the plurality of lexical units to construct a grammatical tree for the plurality of concept verification names according to the execution rules to obtain a grammatical tree.

[0047] First, the flow graph description is lexically analyzed. It is mainly responsible for decomposing the input character stream (such as the source code of a programming language) into lexical units (Tokens) from left to right. These lexical units are the basic grammatical units of programming languages. This process is like splitting sentences into words when reading an article, and it will decompose the code string into lexical units (tokens).

[0048] For example, the flow graph rule module defines the flow keyword, && operator, for keyword, set keyword, dedupe keyword, and internal keyword. When POC A || POC B appears in POC, the lexical structure does not conform to the flow graph rule, and an error will be reported during lexical analysis.

[0049] After obtaining each rule lexical unit, its corresponding execution rule will be determined.

[0050] For example, the rule lexical unit "&&" means that the content before "&&" is executed first, and then the content after "&&" is executed. Taking "flow: POC A&&POC B" as an example, POC A is executed first, and then POCB is executed after POC A is executed.

[0051] In this way, by determining the execution rule corresponding to each rule lexical unit, the specific execution method can be known.

[0052] After obtaining each lexical unit, filter out the rule lexical units corresponding to the flow graph rules (such as flow, &&, for, etc.) from multiple lexical units, and filter out each proof of concept name (such as POC A, POC B, etc.).

[0053] Secondly, based on the lexical analysis, grammatical analysis will be performed. The main task is to analyze the sequence of lexical units (Tokens) obtained from the lexical analysis according to the grammatical rules of the given language to determine whether the sequence constitutes a legal sentence (in programming languages, legal program statements). Syntax analysis constructs a data structure that represents the grammatical structure of the input code, usually a syntax tree (Syntax Tree) or an abstract syntax tree (AST). This is similar to analyzing the grammatical structure of a sentence, and it checks whether the combination of these lexical units is legal according to the defined grammatical rules. If the code does not conform to the grammatical rules, a syntax error will occur.

[0054] In step 203, each concept verification is called according to the execution rules in the syntax tree to perform vulnerability scanning and obtain a scanning result.

[0055] Among them, the execution rules between each POC are extracted from the syntax tree, and then the corresponding POC in the proof-of-concept library is called according to these rules to execute the specific implementation code for vulnerability scanning, so as to obtain the final scanning result after the execution is completed.

[0056] In some implementations, calling each of the concept verifications according to the execution rules in the syntax tree to perform vulnerability scanning on the target object to obtain a scanning result includes: (1) converting the syntax tree into a plurality of execution codes, each of which complies with the execution rule; (2) executing each of the execution codes according to the execution rules; (3) If the currently executed target execution code includes any target concept verification name in the concept verification name, the target concept verification of the target concept verification name is called to perform vulnerability scanning until each of the execution codes is executed and the scanning result is obtained.

[0057] Among them, after the code is parsed in the previous stage, the code generation stage converts the parsed abstract syntax tree (AST) or intermediate representation into machine code or bytecode that can be actually executed on the target platform, so that the computer hardware can directly understand and perform the corresponding operations, and finally realize the functions defined by the code. Then these codes will be executed, and the computer will perform the operations according to the generated instruction sequence. For example, the "POC A&&POC B" code is converted into three execution codes, namely: execute POC A, check whether POC A is executed, and execute POC B after POC A is executed, and execute each execution code according to this execution rule.

[0058] Specifically, if the currently executing target execution code includes any target concept verification name in the concept verification name, the target concept verification of the target concept verification name is called to perform vulnerability scanning until each of the execution codes is executed to obtain a scanning result.

[0059] For example, there are three execution codes, namely: execute POC A, check whether POC A is executed, and execute POC B after POC A is executed. The execution codes at both ends, namely, execute POC A and execute POC B after POC A is executed, include the name of POC A and the name of POC B respectively. If the target execution code currently being executed is POC A executed and then POC B executed, POC B will be called for vulnerability scanning until each execution code is executed and the scanning result is obtained.

[0060] In some implementations, the calling of the target concept verification of the target concept verification name to perform vulnerability scanning includes: (1.1) obtaining a target concept verification method for a target concept verification of the target concept verification name; (1.2) determining a target execution engine corresponding to the target concept verification method according to a preset mapping relationship between the concept verification method and the execution engine; (1.3) Calling the target concept verification through the target execution engine to perform vulnerability scanning.

[0061] Different proof-of-concept methods (such as TCP, HTTP, DNS, etc.) have their own unique operating mechanisms and possible vulnerability types. In order to efficiently and accurately detect vulnerabilities related to these protocols, special vulnerability detection codes, namely POC statements, are designed for different protocols. Different execution engines are used to execute the proof-of-concept corresponding to different proof-of-concept methods.

[0062] For example, the TCP engine is responsible for executing these POC statements related to the TCP protocol. It uses its in-depth understanding of the TCP protocol and related network programming techniques to operate network connections according to the instructions in the POC statements, such as establishing TCP connections, sending TCP packets in a specific format, receiving and analyzing the returned data, etc., to determine whether the target system has corresponding TCP protocol vulnerabilities. The HTTP engine focuses on executing these POC statements related to the HTTP protocol. According to the requirements of the POC statements, it will send specific HTTP requests (including different request methods such as GET, POST, etc., and set different request headers and request bodies), receive and analyze the HTTP responses returned by the server, and thus determine whether the target system has HTTP protocol-related vulnerabilities. The DNS engine is responsible for executing these POC statements related to the DNS protocol. It will perform DNS query operations (such as sending different types of DNS requests, including A record queries, CNAME record queries, etc.) according to the instructions of the POC statements, analyze the response data returned by the DNS server, and then determine whether the target DNS server has related vulnerabilities. Through this division of labor, different engines focus on the protocol areas they are good at, and can complete vulnerability detection work more professionally and efficiently.

[0063] Thus, when a vulnerability detection code such as POC A, which is specifically used to detect a TCP proof-of-concept vulnerability detection method, is called, the TCP engine will be called to execute the execution code of POC A to perform a vulnerability scan.

[0064] In some implementations, each of the concept verifications includes sub-concept verifications of different scan object types, and before the target execution engine calls the target concept verification to perform vulnerability scanning, it also includes: (1.1) Get the specified target scanning object type; The step of calling the target concept verification by the target execution engine to perform vulnerability scanning includes: (1.2) Determining the target sub-concept verification corresponding to the target scanning object type in the target concept verification; (1.3) Calling the target sub-concept verification through the target execution engine to perform vulnerability scanning.

[0065] The scan object type is the type of scan object configured by the user for vulnerability scanning. In the POC library, each POC includes multiple sub-POCs for different scan object types, that is, sub-concept proofs. In this way, when performing vulnerability scanning, the target sub-concept proof corresponding to the target scan object type can be selected from each concept proof called to perform vulnerability scanning according to the target scan object type specified by the user.

[0066] For example, different computer operating systems can be divided into Windows type, macOS type, Linux type, etc. Taking the proof of concept POC A as an example, it includes POC A1 for Windows type, POC A2 for macOS type, and POC A3 for Linux type. When the user specifies to perform a vulnerability scan of Windows type, POC A1 in POC A can be called to perform a vulnerability scan of Windows type.

[0067] In some implementations, before the target execution engine calls the target sub-concept verification to perform vulnerability scanning, the method further includes: (1.1) Obtaining the current load ratio of the target execution engine; (1.2) If the current load ratio is greater than or equal to the preset load ratio, the load ratio of the target execution engine is detected in real time; (1.3) When it is detected that the load proportion of the target execution engine is less than the preset load proportion, the step of performing vulnerability scanning by calling the target sub-concept verification through the target execution engine is executed.

[0068] Among them, before the target execution engine calls the target sub-concept verification to perform vulnerability scanning, in order to avoid the problem of low execution efficiency or direct abnormal downtime caused by excessive engine execution load, it is necessary to obtain the current load ratio of the target execution engine. If the current load ratio is greater than or equal to the preset load ratio, it means that the load of the target execution engine is high, and the load ratio of the target execution engine is detected in real time. When it is detected that the load ratio of the target execution engine is less than the preset load ratio, it means that the load of the target execution engine is low at this time, and then the step of calling the target sub-concept verification through the target execution engine to perform vulnerability scanning is performed to avoid low execution efficiency or direct abnormal downtime caused by excessive load, and improve system stability.

[0069] In some embodiments, the method further comprises: When it is detected that the duration when the load ratio of the target execution engine is greater than or equal to the preset load ratio reaches a preset duration, a prompt message is generated, where the prompt message is used to prompt that the vulnerability scan has timed out.

[0070] Among them, in the process of real-time detection of the load ratio of the target execution engine, if the load ratio of the target execution engine is greater than or equal to the preset load ratio for a preset time period, it means that the target execution engine may have an abnormality or crash, and a prompt message is generated to prompt that the vulnerability scan has timed out to avoid long waiting times for users.

[0071] As can be seen from the above, the embodiment of the present application obtains a flow graph description, which is obtained by compiling the concept verification names of multiple concept verifications in the concept verification library according to the flow graph rules; converting the flow graph description into a syntax tree, the syntax tree including the concept verification name of each of the concept verifications, and the execution rules between each of the concept verifications; calling each of the concept verifications according to the execution rules in the syntax tree to perform vulnerability scanning to obtain a scanning result. Compared with the related art, when some POCs in the POC library are used in combination, it is necessary to recompile the specific implementation codes of these POCs. In the embodiment of the present application, the combination logic of multiple POCs is represented in an abstract manner of flow graph rules through a flow graph description, so that the computer device converts the flow graph description into a syntax tree, and intuitively presents the execution rules between POCs in a tree form, thereby calling each POC in turn for vulnerability scanning, avoiding recompilation of POCs stored in the POC library, and improving POC reusability and vulnerability scanning efficiency.

[0072] See also Figure 4 , Figure 4 A schematic diagram of the interaction framework between the client and the server provided in the embodiment of the present application. The client includes a newly added POC function module, a configuration function module, and a report function module. The server includes a POC library module, a configuration module, a scheduler module, a flow graph rule module, an execution engine module, a flow graph engine module, and an analyzer module.

[0073] For the client, the newly added POC function module allows users to customize POC content, and the configuration function module allows users to automate and customize vulnerability scanning through configuration scripts. For example, when executing all POCs or specific POCs at one time, the configuration report only displays vulnerabilities with a severity level above the critical level, and the report function module shows the user the results of this POC execution, including the severity of the vulnerability, the name of the vulnerability, the type of vulnerability, the description of the vulnerability, etc.

[0074] For the server, the POC library module mainly includes user-defined POC and third-party POC. The POC library needs to update new POCs regularly to ensure the completeness of the vulnerability scanning tool. The configuration module is used to receive the configuration parameters of the client configuration function module as the configuration parameter module of the server module. It mainly provides parameter basis for the scheduler scheduling. Various configuration parameters for vulnerability scanning in this module. The scheduler is the core module of the server. By obtaining various configuration parameters of the configuration module and the POC of the POC library, the POC to be executed is scheduled to their respective execution engines and the results are returned to the analyzer. Common execution engines include execution engine 1, execution engine 2, etc. The analyzer module is responsible for the analysis and integration of the results of the entire POC scheduler, and finally sends the analysis report to the client's report function module. The flow graph rule module is mainly responsible for the definition of reused POC rules, including control branch rules, loop rules, etc. The flow graph engine module is mainly responsible for the parsing of flow graph rules. Through this module, the existing POC in the POC library can be associated with the execution flow to achieve fast calling of existing POCs.

[0075] Among them, the flow chart rule module is responsible for the implementation of user-defined POC rules. Through rich flow chart rules, users can implement complex POC more simply and efficiently. The detailed flow chart rules are described as follows.

[0076] Rule 1, control branches: For example: A user is using the default username and password to brute-force WordPress login information. First, check if the target is a WordPress website. If so, use the default credentials to brute-force the login information. Set the check for target existence as POC A and the brute-force attack as POC B. Before this invention, the user needs to add POC C as shown below. The part in {} requires the user to copy the implementation of POC AB to POC C. This is equivalent to writing an extra redundant code.

[0077] Execute {Implementation of POC A} if website exists: Execute {implementation of POC B} else: If the detection target does not exist, it will not be executed; However, this application can directly reuse POC A and POC B without adding POC C. The final flow graph is described as "flow: POC A&&POC B". In this way, a new flow definition is added, and the control branch is implemented through the && symbol. Only when POC A is executed successfully can POC B continue to execute. Otherwise, POC B will not be executed.

[0078] Rule 2, loop: For example: All domain names found in the SSL request are brute-forced against the request. First, use the SSL request to find all domain names, and then brute-force all domain names. Set the SSL request to POC A, and the brute-force attack to POCB. Before this invention, the user needs to add POC C as shown below. The execution result of POC A contains all domain name fields, and POC B receives the domain name parameters and executes. Set is responsible for setting the domain name parameters to parameters that POC B can recognize. The part in {} requires the user to copy the implementation of POC AB to POC C. It is equivalent to writing an extra redundant code.

[0079] All domains = execute {implementation of POC A} for domain name in all domains: set(domain name, new domain name) {Implementation of POC B} (New domain name) However, this application can directly reuse POC A and POC B without adding POC C. The final flow diagram is described as “flow: All domains = execute POC A for domain name in all domains: set(domain name, new domain name) POC B (new domain name)” Add a new flow definition, use the for symbol to implement the control branch, the execution result of POC A contains all the domain name fields, and POC B receives the domain name parameters and executes. Set is responsible for setting the domain name parameters to parameters that POC B can recognize.

[0080] Rule three, named call: As described in rules 1 and 2, POC A and POC B do not need to re-implement and write redundant code, they can be called directly by name. This rule can quickly implement complex and efficient workflows.

[0081] Rule 4, set parameter passing: As described in rules 1 and 2, Set is responsible for setting the domain name parameters to parameters that POC B can recognize. Set helps users pass parameters between POCs. POC B relies on the domain name parameters of POC A, and sets the domain name to a new domain name parameter that POC B can recognize through set.

[0082] Rule 5, log log: Through the log statement, you can display the current POC execution status or POC result view, etc., to help users easily and quickly locate problems found during the POC customization process.

[0083] Rule 6, deduplication: The dedupe statement can be used to remove duplicates from the POC results. For example, in rule 2, if there are duplicate domain names, dedupe can be used to remove the duplicate domain names. If the domain name before removal is {domain name 1, domain name 2, domain name 3, domain name 3}, it will become {domain name 1, domain name 2, domain name 3} after dedupe. Rule 7, Skip: For example, in rule 1, there are two steps, POC A and POC B. By adding an internal statement in the implementation of POC A, the execution result of POC A can be regarded as the intermediate content of the flow graph execution. Users may not care about the execution result of POC A, but more about the execution result of POCB. Therefore, through this internal statement, users can shield the useless intermediate result, that is, the execution result of POC A, and view the result of POC B more friendly.

[0084] The whole process includes: Building a POC library. Starting to customize POC, including responsible POC. Building a target POC library, and conducting vulnerability scanning through the POC library. Calling flow chart rules. Responsible POC construction, through the grammatical rules provided by the flow rule module, can quickly and efficiently build responsible POC, without the need to add additional redundant POC. Configuring scanning. Through the configuration module on the user side, you can implement the global scanning parameter configuration of vulnerability scanning. Including scanning all POC libraries or specific scanning. The scheduler module on the server side obtains the user configuration from the configuration module and completes the configuration preparation before scanning. After the scheduler module loads the user configuration, it loads the POC instance from the POC library. POC instances include simple POC and complex POC. When the scheduler module executes the POC containing flow chart rule statements, it needs to call the flow chart engine module to parse the flow chart rule language. As described in detail in the flow chart engine module, after the flow chart rule language parsing is completed, the execution of the POC begins. If the POC does not contain flow chart rule statements, this step is skipped. After the scheduler module completes the flow chart engine parsing, it will perform the specific execution of the POC. The specific execution is completed by the execution engine. For example, the TCP engine is responsible for the execution of TCP POC statements, the HTTP engine is responsible for the execution of HTTP POC statements, and the DNS engine is responsible for the execution of DNS POC statements. After the execution engine is finished, the execution result is returned to the scheduler. The scheduling engine calls the analyzer. The analyzer is responsible for statistics and analysis of all the execution results of the scheduler. Including the execution status of the POC, the severity level of the vulnerability, logs, etc. After all POCs complete the vulnerability scan, the analyzer generates a vulnerability report and reports it to the user.

[0085] The specific implementation of the above steps can be found in the previous embodiments, which will not be described in detail here.

[0086] In order to better implement the vulnerability scanning method provided in the embodiment of the present application, the embodiment of the present application also provides a device based on the above vulnerability scanning method. The meanings of the terms are the same as those in the above vulnerability scanning method, and the specific implementation details can refer to the description in the method embodiment.

[0087] See also Figure 5 , Figure 5 The schematic diagram of the structure of the vulnerability scanning device provided in the embodiment of the present application is applied to a computer device, wherein the vulnerability scanning device may include an acquisition unit 601, a conversion unit 602, and a vulnerability scanning unit 603.

[0088] An acquisition unit 601 is used to acquire a flow graph description, where the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in a concept verification library according to a flow graph rule; A conversion unit 602, configured to convert the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; The vulnerability scanning unit 603 is used to call each of the concept verifications according to the execution rules in the syntax tree to perform vulnerability scanning and obtain a scanning result.

[0089] In some embodiments, the conversion unit 602 includes: A lexical analysis subunit, used for performing lexical analysis on the flow graph description to obtain a plurality of lexical units; A screening subunit, used to screen out the rule lexical unit corresponding to the flow graph rule from the plurality of lexical units, and to screen out each concept verification name; A first determination subunit, used to determine the execution rule corresponding to each of the rule lexical units; The syntax analysis subunit is used to perform syntax analysis on the multiple lexical units, so as to construct syntax trees for the multiple concept verification names through the execution rules to obtain syntax trees.

[0090] In some embodiments, the vulnerability scanning unit 603 includes: A conversion subunit, used for converting the syntax tree into a plurality of execution codes, each of which complies with the execution rule; An execution subunit, configured to execute each of the execution codes according to the execution rules; The calling subunit is used to call the target concept verification of the target concept verification name to perform vulnerability scanning if the currently executed target execution code includes any target concept verification name in the concept verification name, until each of the execution codes is executed and the scanning result is obtained.

[0091] In some embodiments, a subunit is called to: Obtain a target concept verification method for a target concept verification of the target concept verification name; Determining a target execution engine corresponding to the target concept verification method according to a preset mapping relationship between the concept verification method and the execution engine; The target concept verification is called by the target execution engine to perform vulnerability scanning.

[0092] In some embodiments, each of the concept verifications includes sub-concept verifications with different scan object types, and the calling sub-unit is further used to: Get the specified target scanning object type; Determine a target sub-concept verification corresponding to the target scanning object type in the target concept verification; The target sub-concept verification is called by the target execution engine to perform vulnerability scanning.

[0093] In some embodiments, the calling subunit is further configured to: Obtaining the current load ratio of the target execution engine; If the current load ratio is greater than or equal to the preset load ratio, the load ratio of the target execution engine is detected in real time; When it is detected that the load proportion of the target execution engine is less than the preset load proportion, the step of performing vulnerability scanning by calling the target sub-concept verification through the target execution engine is executed.

[0094] In some embodiments, the calling subunit is further configured to: When it is detected that the duration when the load ratio of the target execution engine is greater than or equal to the preset load ratio reaches a preset duration, a prompt message is generated, where the prompt message is used to prompt that the vulnerability scan has timed out.

[0095] The specific implementation of each of the above units can be found in the previous embodiments, which will not be described in detail here.

[0096] As can be seen from the above, the embodiment of the present application obtains the flow graph description through the acquisition unit 601, and the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in the concept verification library according to the flow graph rules; the conversion unit 602 converts the flow graph description into a syntax tree, and the syntax tree includes the concept verification name of each concept verification and the execution rules between each concept verification; the vulnerability scanning unit 603 calls each concept verification according to the execution rules in the syntax tree to perform vulnerability scanning and obtain the scanning result. Compared with the related art, when it involves the combination of some POCs in the POC library, it is necessary to recompile the specific implementation code of these POCs. In the embodiment of the present application, the combination logic of multiple POCs is expressed in an abstract way of flow graph rules through the flow graph description, so that the computer device converts the flow graph description into a syntax tree, and intuitively presents the execution rules between POCs in a tree form, so as to call each POC in turn for vulnerability scanning, avoid recompiling the POCs stored in the POC library, and improve the reusability of POCs and the efficiency of vulnerability scanning.

[0097] The specific implementation of each of the above units can be found in the previous embodiments, which will not be described in detail here.

[0098] Reference Figure 6 , Figure 6 A block diagram of a portion of a computer device 1000 as a server for implementing an embodiment of the present disclosure. The computer device 1000 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 622 (e.g., one or more processors) and a memory 632, and one or more storage media 630 (e.g., one or more mass storage devices) storing application programs 642 or data 644. Among them, the memory 632 and the storage medium 630 may be temporary storage or permanent storage. The program stored in the storage medium 630 may include one or more modules (not shown in the figure), each of which may include a series of instruction operations on the server 1000. Furthermore, the central processing unit 622 may be configured to communicate with the storage medium 630 to execute a series of instruction operations in the storage medium 630 on the server 1000.

[0099] The computer device 1000 may also include one or more power supplies 626, one or more wired or wireless network interfaces 650, one or more input and output interfaces 658, and / or one or more operating systems 641, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0100] The central processor 622 in the computer device 1000 may be used to execute the vulnerability scanning method of the embodiment of the present disclosure, for example: Obtain a flow graph description, where the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in the concept verification library according to the flow graph rule; Converting the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; Each of the concept verifications is called according to the execution rules in the syntax tree to perform vulnerability scanning and obtain a scanning result.

[0101] The embodiments of the present disclosure also provide a computer-readable storage medium, which is used to store program codes, and the program codes are used to execute the vulnerability scanning methods of the aforementioned embodiments.

[0102] The present disclosure also provides a computer program product, which includes a computer program. The processor of a computer device reads and executes the computer program, so that the computer device executes the vulnerability scanning method. For example: Obtain a flow graph description, where the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in the concept verification library according to the flow graph rule; Converting the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; Each of the concept verifications is called according to the execution rules in the syntax tree to perform vulnerability scanning and obtain a scanning result.

[0103] In addition, the terms "comprises" and "includes" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or apparatus that includes a series of steps or elements is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, method, product or apparatus.

[0104] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0105] It should be understood that in the description of the embodiments of the present application, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.

[0106] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0107] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0108] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0109] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0110] It should also be understood that the various implementations provided in the embodiments of the present application can be combined arbitrarily to achieve different technical effects.

[0111] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories), or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0112] The above is a specific description of the implementation method of the present application, but the present application is not limited to the above-mentioned implementation method. Technical personnel familiar with the field can also make various equivalent modifications or substitutions without violating the spirit of the present application. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present application.

Claims

1. A vulnerability scanning method, characterized in that: include: Obtain a flow graph description, where the flow graph description is obtained by compiling the concept verification names of multiple concept verifications in the concept verification library according to the flow graph rule; Converting the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; Each of the concept verifications is called according to the execution rules in the syntax tree to perform vulnerability scanning and obtain a scanning result.

2. The vulnerability scanning method according to claim 1, characterized in that: The converting the flow graph description into a syntax tree comprises: Performing lexical analysis on the flow graph description to obtain a plurality of lexical units; Filtering out the rule lexical units corresponding to the flow graph rule from the plurality of lexical units, and filtering out each concept verification name; Determine the execution rule corresponding to each of the rule lexical units; The plurality of lexical units are subjected to grammatical analysis to construct a grammatical tree for the plurality of concept verification names according to the execution rules to obtain a grammatical tree.

3. The vulnerability scanning method according to claim 1 or 2, characterized in that: The step of calling each of the concept verifications according to the execution rules in the syntax tree to perform vulnerability scanning on the target object and obtaining a scanning result includes: Converting the syntax tree into a plurality of execution codes, each of the execution codes conforming to the execution rule; Execute each of the execution codes according to the execution rules; If the currently executed target execution code includes any target concept verification name in the concept verification name, the target concept verification of the target concept verification name is called to perform vulnerability scanning until each of the execution codes is executed and the scanning result is obtained.

4. The vulnerability scanning method according to claim 3, characterized in that: The target concept verification of calling the target concept verification name to perform vulnerability scanning includes: Obtain a target concept verification method for a target concept verification of the target concept verification name; Determining a target execution engine corresponding to the target concept verification method according to a preset mapping relationship between the concept verification method and the execution engine; The target concept verification is called by the target execution engine to perform vulnerability scanning.

5. The vulnerability scanning method according to claim 4, characterized in that: Each of the concept verifications includes sub-concept verifications of different scan object types, and before the target concept verification is called by the target execution engine to perform vulnerability scanning, it also includes: Get the specified target scanning object type; The step of calling the target concept verification by the target execution engine to perform vulnerability scanning includes: Determine a target sub-concept verification corresponding to the target scanning object type in the target concept verification; The target sub-concept verification is called by the target execution engine to perform vulnerability scanning.

6. The vulnerability scanning method according to claim 4, characterized in that: Before the target execution engine calls the target sub-concept verification to perform vulnerability scanning, the method further includes: Obtaining the current load ratio of the target execution engine; If the current load ratio is greater than or equal to the preset load ratio, the load ratio of the target execution engine is detected in real time; When it is detected that the load proportion of the target execution engine is less than the preset load proportion, the step of performing vulnerability scanning by calling the target sub-concept verification through the target execution engine is executed.

7. The vulnerability scanning method according to claim 5, characterized in that: The method further comprises: When it is detected that the duration when the load ratio of the target execution engine is greater than or equal to the preset load ratio reaches a preset duration, a prompt message is generated, where the prompt message is used to prompt that the vulnerability scan has timed out.

8. A vulnerability scanning device, characterized in that: include: An acquisition unit is used to acquire a flow graph description, where the flow graph description is obtained by compiling concept verification names of multiple concept verifications in a concept verification library according to a flow graph rule; A conversion unit, configured to convert the flow graph description into a syntax tree, wherein the syntax tree includes a concept verification name of each concept verification and an execution rule between each concept verification; The vulnerability scanning unit is used to call each of the concept verifications according to the execution rules in the syntax tree to perform vulnerability scanning and obtain scanning results.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor to execute the vulnerability scanning method according to any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the vulnerability scanning method according to any one of claims 1 to 7 is implemented.

Images