CN106295348B

CN106295348B - Vulnerability detection method and device for application program

Info

Publication number: CN106295348B
Application number: CN201510289736.XA
Authority: CN
Inventors: 孙伟超
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2015-05-29
Filing date: 2015-05-29
Publication date: 2020-04-10
Anticipated expiration: 2035-05-29
Also published as: CN106295348A

Abstract

The invention discloses a vulnerability detection method and device of an application program. Wherein, the method comprises the following steps: converting an installation file of an application program to be detected into a code file; acquiring description information of a specified function, wherein the specified function is a function for reflecting specified behaviors; and determining a first class function matched with the specified description information in the code file according to the description information, and detecting the vulnerability of the application program according to the first class function. By the technical scheme, the technical problems that the vulnerability detection scheme is low in efficiency and incomplete in detection result are solved.

Description

Vulnerability detection method and device for application program

Technical Field

The invention relates to the field of vulnerability detection, in particular to a vulnerability detection method and device of an application program.

Background

With the rapid development of intelligent mobile terminals, applications based on mobile operating systems are also in a large number, but due to the numerous developers, security holes inevitably exist in the applications. For example, among vulnerabilities existing in Android applications, one vulnerability with a relatively wide influence area is a Java Null Pointer (DOS) vulnerability. This type of bug is mostly caused by a program crash caused by improper processing parameters when the program calls some system APIs, which results in the DOS due to the fact that normal functions cannot be used.

The main way to detect such bugs is currently a Fuzz Testing (Fuzz Testing), which is to send random data to all possible entries of the target program and observe whether the program is abnormal or not. As shown in fig. 1, the principle of whether the Fuzz monitoring program has a bug is as follows;

the distorted sample (sample) is read into a Fuzz framework (frame), analyzed, handed to a conversion module (mutation) for randomized variation, and then handed to a target program (target) through a bridge part (bridge), wherein the target program runs on a Platform (Platform runtime) of the target program, the Fuzz framework monitors the running state of the target program through a monitoring module (monitor), and the abnormal condition is recorded into a log (logger).

This approach cannot guarantee that all code branches of the program are traversed because of the specific execution condition of the program, the vulnerability discovery efficiency is low, and even if the target program is detected, much effort is required to reproduce the exception to determine the specific existing point of the vulnerability and the impact that can be generated because hundreds or thousands of fuzzy use cases may be generated per second. And because the target program is executed on the target platform, some deeper program branches are difficult to find.

In view of the above problems, no effective solution has been proposed.

Disclosure of Invention

The embodiment of the invention provides a vulnerability detection method and device of an application program, and aims to at least solve the technical problems that a vulnerability detection scheme is low in efficiency, incomplete in detection result and the like.

According to an aspect of the embodiments of the present invention, a method for detecting a vulnerability of an application program is provided, including: converting an installation file of an application program to be detected into a code file; acquiring description information of a specified function, wherein the specified function is a function for reflecting specified behaviors; and determining a first class function matched with the specified description information in the code file according to the description information, and detecting the vulnerability of the application program according to the first class function.

According to another aspect of the embodiments of the present invention, there is also provided an apparatus for detecting a vulnerability of an application program, including: the conversion module is used for converting the installation file of the application program to be detected into a code file; the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring the description information of a specified function, and the specified function is a function for reflecting specified behaviors; and the detection module is used for determining a first type of function matched with the specified description information in the code file according to the description information and detecting the vulnerability of the application program according to the first type of function.

In the embodiment of the invention, the installation file of the application program is converted into the code file, the function for reflecting the specified behavior is searched from the code file, and the vulnerability of the application program is detected according to the first type of function matched with the description information and the specified description information, so that the purpose of vulnerability detection through a static analysis mode is achieved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

FIG. 1 is a schematic diagram of a monitoring application utilizing fuzzy according to the related art;

fig. 2 is a block diagram of a hardware structure of a computer terminal for implementing a vulnerability detection method of an application according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of an alternative vulnerability detection method for an application according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of an alternative first CFG generation process according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of a CFG according to an embodiment of the present invention;

FIG. 6 is another schematic diagram illustrating an alternative vulnerability detection method for an application according to an embodiment of the present invention;

FIG. 7 is a schematic diagram of an alternative vulnerability detection apparatus for an application according to an embodiment of the present invention;

FIG. 8 is another schematic diagram of an alternative vulnerability detection apparatus for an application according to an embodiment of the present invention;

fig. 9 is a block diagram of a computer terminal according to an embodiment of the present invention.

Detailed Description

In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Example 1

There is also provided, in accordance with an embodiment of the present invention, a method embodiment of a vulnerability detection method of an application program, it should be noted that the steps illustrated in the flowchart of the accompanying drawings may be executed in a computer system such as a set of computer-executable instructions, and that, although a logical order is illustrated in the flowchart, in some cases, the steps illustrated or described may be executed in an order different from that herein.

The method provided by the first embodiment of the present application may be executed in a mobile terminal, a computer terminal, or a similar computing device. Taking the example of running on a computer terminal, fig. 2 is a block diagram of a hardware structure of the computer terminal for implementing the vulnerability detection method of the application program according to the embodiment of the present invention. As shown in fig. 2, the computer terminal 20 may include one or more (only one shown) processors 202 (the processors 202 may include, but are not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 204 for storing data, and a transmission device 206 for communication functions. It will be understood by those skilled in the art that the structure shown in fig. 2 is only an illustration and is not intended to limit the structure of the electronic device. For example, the computer terminal 20 may also include more or fewer components than shown in FIG. 2, or have a different configuration than shown in FIG. 2.

The memory 204 may be used to store software programs and modules of application software, such as program instructions/modules corresponding to the vulnerability detection method of the application program in the embodiment of the present invention, and the processor 202 executes various functional applications and data processing by running the software programs and modules stored in the memory 204, that is, implements the vulnerability detection method of the application program. Memory 204 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 204 may further include memory located remotely from the processor 202, which may be connected to the computer terminal 20 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission means 206 is used for receiving or transmitting data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal 20. In one example, the transmission device 206 includes a Network adapter (NIC) that can be connected to other Network devices through a base station to communicate with the internet. In one example, the transmission device 206 can be a Radio Frequency (RF) module, which is used for communicating with the internet in a wireless manner.

Under the above operating environment, the present application provides a vulnerability detection method for an application program as shown in fig. 3. Fig. 3 is a flowchart of a vulnerability detection method of an application according to an embodiment of the present invention. As shown in fig. 3, the method includes:

step S302, converting the installation file of the application program to be detected into a code file;

for this processing step, it may be implemented by a solution in the related art, for example, for an installation Package file of an Android application, an installation Package (Android Package, abbreviated as APK) file of the application may be converted into a smali code by APKTool; the APKTool is an APK compiling tool provided by Google (GOOGLE), can decompile and decompile an APK, simultaneously has the functions of installing a frame-res framework required by a decompiling system APK, cleaning decompiled files and the like, and the smal is an assembler of files in a dex format used by a Java virtual machine (Dalvik) in an android system. Through the step S302, the installation package file is converted into the code file, and a basis is provided for subsequent static analysis.

The code file is not limited to the assembly file, and may be represented as an underlying code file (i.e., an executable code file) such as a source code file. In practical application, the source code file is not easy to obtain, and can be preferentially converted into an assembly code file and the like.

In step S304, description information of a specified function is acquired, where the specified function is a function for reflecting a specified behavior.

Optionally, in the process of executing step S304, a step of searching for the specified function may be included, that is, a function for reflecting a specified behavior may be searched from the code file; of course, the search step may not be performed in a specific vulnerability detection process.

The specified behavior here may be expressed as a type of function performed by the function, i.e., a function type. For the processing step, for different types of vulnerability detection, functions for reflecting different behaviors may be used, for example, when detecting a dos vulnerability, API functions in an assembly file converted by an application installation package may be detected.

Optionally, there are various ways to obtain the description information of the specified function, for example, the description information of the function may be obtained from an open source document on a network side, and specifically, the description information may be crawled from the open source document in a web crawler manner. For understanding, the following description will be given by taking the example of detecting a dos vulnerability using an API function in an android application:

APIs that may return NULL values (NULL) are found in the Google Android API document. Since the API documents of google android are public and uniform in format, describing specifications, APIs that may return NULL can be found by crawling these documents and analyzing the contents thereof.

For example: the required API is determined using the return value description information in the following procedure:

public Bundle getBundleExtra(String name)

Retrieve extended data from the intent.

Parameters

name The name of the des ired item.

Returns

the value of an item that previous ly added wi th putExtra()or null if no Bundle value was found.

See Also

putextra(String，Bundle)

the above is a program in a section of the Google API document in which the parameters, functions, and return values of the function getbounteextra are described. Since the API document format of Google is relatively standard and normative, all the APIs that may return null are specified in the return value description (see the dash part in the program code above), so that the APIs that may return null can be found out in a simple text search manner for subsequent verification of whether there is a DOS vulnerability.

After determining the used open source document, optionally, determining the API function that may return null may be performed by: 1. grabbing an Android API document through a crawler; 2. the return values of each API are analyzed to find APIs that may return NULL.

Step S306, according to the description information, determining a first type of function matched with the specified description information in the code file, and detecting the vulnerability of the application program according to the first type of function.

Still taking the example of identifying a dos vulnerability in step S304 as an example, the specified description information in step S306 may be represented as a null return value, and the above-mentioned first-type function may be represented as an API function whose return value may be null, but is not limited thereto.

Optionally, in step S306, the detecting the vulnerability of the application program according to the first-class function may be implemented by, but is not limited to: constructing a first control flow graph CFG (first CFG for short) of a branch where the first type of function is located, and counting second type of functions with specified characteristic values in all the first type of functions; searching the branch where the second type of function is located in the first CFG, judging whether the branch is subjected to exception handling or not, and if so, determining that the application program does not have a bug; and if the judgment result is negative, determining that the application program has a bug. Alternatively, the exception handling may take the form of, but is not limited to: and setting a jump instruction or a call instruction for jumping to other instructions when the current instruction is abnormal.

It should be noted that the specified feature value may be represented by the same feature value of the same class of function, for example, a return value of the function, and the second class of function may be determined by searching for a feature value whose return value may be empty, but is not limited to this representation.

In an alternative embodiment, the first CFG is generated by: and converting an Android application installation package (APK) into Smali codes, and generating CFG of the application program through static code analysis. The CFG is a directed graph using an application code as a node, and the direction of an edge represents a calling direction, that is, an execution direction of a program. As shown in fig. 4, the method comprises the following steps:

s402, resolving a smali code in the APK through the apktool;

step S404, generating the CFG based on the function call relation in the Smali and the branch logic of the code. Specifically, this step can be realized by the following procedure:

1. the smali code is broken into many blocks (chunk). A chunk is the largest unit of code that is executed sequentially. That is, when a branch jump (loop is also a kind of conditional branch jump) is encountered in the code, a function call or the like can change the instruction of the program execution flow, the current chunk is ended, and the next chunk is started. Each chunk has a unique id, which is also their entry point, which is an offset from the start address of the function. Possible subsequent chunk ids of the current chunk when executed can be calculated for jump instructions or function call instructions by analyzing the operands of the instructions.

2. And connecting the chunks together through the values of the self id and the subsequent chunk id, so as to construct the CFG.

It should be noted that, for convenience of understanding, the following CFG branches are described in natural language and are not represented by codes, and in actual application, each step may be represented by codes for implementing the following functions. As shown in fig. 5:

1. acquiring an incoming intent, checking whether the intent contains parameters, if so, turning to the step 2, otherwise, turning to the step 4;

2. acquiring parameters from the intent, and performing forced conversion or self-definition;

3. calling a method of the class;

4. the routine is ended.

In an alternative embodiment, when finding the branch where the second type of function is located in the first CFG, the following procedure may be implemented, but is not limited to this: filtering the branches in the first CFG according to a preset rule to obtain a second CFG; and searching the branch of the second type function in the second CFG. The preset rule may be flexibly set according to an actual situation, for example, the branch in the first CFG may be filtered in the following manner: and deleting the designated node and the nodes which can be only communicated by the designated node in the first CFG, wherein the function corresponding to the designated node is a function with only out degree and no in degree. An application based on the android system is taken as an example for explanation.

The branches are filtered, also known as CFG pruning. All the application programs on the Android system have specific function entries, and nodes with only out-degree and no in-degree in the CFG need to be found out. If the function of this node is not a known program entry, all points that can only be connected by this node are removed. This ensures that the remaining nodes in the CFG are all available for external programs (e.g., attacker's programs) to call. The method can be realized by the following steps:

1. summarizing application entry functions of Android systems

2. Finding out the points in CFG with out degree and no in degree

3. Judging whether the point is an entry function

4. Traversing all sub-nodes of the current node, and deleting all points which can only be communicated by the node

In an alternative embodiment, determining whether the branch of the CFG is exception-handled may be accomplished by: traversing all branches in the CFG; finding a branch containing a possible return NULL; it is determined whether this branch is exception-handled.

It can be seen from the foregoing embodiment that the vulnerability detection method for an application program provided in the embodiment of the present invention may be used to detect a DOS vulnerability, and at this time, the function used to reflect the specified behavior in the embodiment of the present invention may be an API function.

It should be noted that the technical solution provided in the embodiment of the present invention may be run in different mobile terminal operating systems, that is, may be used to detect vulnerabilities of application programs based on different operating systems, where the operating systems include but are not limited to: android (Android) operating system, iOS operating system, Symbian, Windows Phone operating system, and BlackBerry OS operating system, among others.

In this embodiment, a mode of converting an installation file of an application into a code file, searching a function for reflecting an appointed behavior from the code file, and detecting a vulnerability of the application according to a first type of function matched with the description information and the appointed description information is adopted, so that the purpose of vulnerability detection through a static analysis mode is achieved.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present invention is not limited by the order of acts, as some steps may occur in other orders or concurrently in accordance with the invention. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required by the invention.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present invention.

Example 2

In this embodiment, a DOS vulnerability of an application program based on an android operating system is taken as an example for description, but it should be noted that the scheme in this embodiment is not limited to application detection applied to the android operating system, nor to the DOS vulnerability. The main design idea of this embodiment is to filter out specific APIs through an official document (i.e. an open source document) and use this as a basis for detecting DOS vulnerabilities, that is, for an open source operating system, specific APIs of interest are found according to behaviors of system APIs described in the open source document, and based on these APIs, some other methods are combined to implement specific functions (e.g. DOS vulnerability detection in this embodiment). The method mainly comprises the following steps: 1. generating a CFG (control Flow graph) based on the static code; 2. filtering out API branches which can be called by the outside through static analysis pruning; 3. identifying APIs potentially causing the DOS vulnerability by combining the Google Android API document; 4. and judging whether the branch is subjected to exception handling or not. Specifically, as shown in fig. 6, the vulnerability detection method for an application program provided in the embodiment of the present invention includes the following processing steps:

step S602, converting apk into a smali code by using apktool;

step S604, constructing CFG by analyzing the smali code. The method mainly comprises the steps of converting an Android Application Program (APK) into a Smali code, and generating the CFG of the application program through static code analysis. The CFG is a directed graph with application code as nodes, and the direction of an edge represents the direction of call, i.e., the direction of execution of a program. The specific implementation process is as follows: 1. the smali code is broken into many chunks. A chunk is the largest unit of code that is executed sequentially. That is, when a branch jump (loop is also a kind of conditional branch jump) is encountered in the code, a function call or the like can change the instruction of the program execution flow, the current chunk is ended, and the next chunk is started. Each chunk has a unique id, which is also the entry point, which is an offset from the start address of the function. Possible subsequent chunk ids of the current chunk when executed can be calculated for jump instructions or function call instructions by analyzing the operands of the instructions. 2. And connecting the chunks together through the values of the self id and the subsequent chunk id, so as to construct the CFG.

Step S606, extract all branches where the entry function is located, and form a new CFG. And all the application programs on the Android system have specific function entries, and nodes with only out-degree and no in-degree in the CFG are found out. If the function of this node is not a known program entry, all points that can only be connected by this node are removed. This ensures that the remaining nodes in the CFG are all available for external programs (e.g., attacker's programs) to call.

Step S608, the Android API document of Google is crawled through an HTTP request. This section mainly finds the APIs from the google android API document that may return NULL. Since the API documents of Google Android are public, uniform in format and describing specifications, APIs that may return NULL can be found by crawling the documents and analyzing the contents thereof, for example, API functions that return NULL can be determined by return value description information in the documents.

Step S610, the document is stored in a local database (which may be simply stored in the form of a file). This step may also be implemented in the form of a cache, i.e. storing the document in the cache, and setting the document's time-to-live, etc.

Step S612, finding out an API that may return NULL by character string search.

In step S614, a target API list (target API list) is found, that is, an API list that may cause DOS vulnerabilities is constructed by using the APIs.

In step S616, branch filtering (branch filter) is performed, i.e. a branch containing a dangerous API is found in the CFG.

Step S618, perform try/catch parser processing, i.e. determine whether the branch is processed abnormally.

The embodiment of the invention discovers the entry point with the vulnerability by combining the Google API document in a static mode. Due to the static analysis, traversal to all application program branches can be guaranteed, the static analysis has higher efficiency compared with a fuzzy mode, and the detected bugs can be accurately positioned. The operation of each step of the embodiment of the invention is determined, and relative to the specific running condition of the Fuzz-dependent program, the invention can ensure that all points which can possibly generate DOS loopholes are found.

Example 3

According to an embodiment of the present invention, there is also provided a vulnerability detection apparatus for an application program implementing the method, which may be operated in the mobile terminal, the computer terminal or the similar computing apparatus described in embodiment 1, but is not limited to the function or structure of the computing apparatus described in embodiment 1. As shown in fig. 7, the apparatus includes:

and the conversion module 70 is used for converting the installation file of the application program to be detected into a code file. For the functions realized by the module, the functions can be realized by a solution in the related art, for example, for an installation Package file of an Android application, the installation Package (Android Package, abbreviated as APK) file of the application can be converted into a smali code by APKTool, but the implementation is not limited to this implementation.

An obtaining module 72, connected to the converting module 70, is used for obtaining the description information of the specified function. The specified behavior here may be expressed as a type of function performed by the function, i.e., a function type. For the processing step, for different types of vulnerability detection, functions for reflecting different behaviors may be used, for example, when detecting a dos vulnerability, API functions in an assembly file converted by an application installation package may be detected. Optionally, the obtaining module 72 may obtain a plurality of kinds of description information of the specified function, for example, the description information of the function may be obtained from an open-source document on a network side, and specifically, the description information may be crawled from the open-source document in a web crawler manner, and at this time, in order to facilitate crawling of the description information, a document whose description information compares a standard and a specification may be used.

And the detecting module 74 is connected to the obtaining module 72, and is configured to determine, according to the description information, a first type of function that matches the specified description information in the code file, and detect the vulnerability of the application program according to the first type of function.

Optionally, as shown in fig. 8, the detection module 74 may further include, but is not limited to:

a constructing unit 740, configured to construct a first control flow graph CFG of a branch where the first type of function is located;

taking an application based on the android operating system as an example for explanation, in an optional embodiment, the building process of the first CFG is as follows: and converting an Android application installation package (APK) into Smali codes, and generating CFG of the application program through static code analysis. The CFG is a directed graph using an application code as a node, and the direction of an edge represents a calling direction, that is, an execution direction of a program. The following processing steps can be embodied, but are not limited thereto: solving a smali code in the APK through the apktool; the CFG is generated based on the function call relationship in Smali and the branch logic of the code. Specifically, this step can be realized by the following procedure:

1. the smali code is broken into many blocks (chunk). A chunk is the largest unit of code that is executed sequentially. That is, when a branch jump (loop is also a kind of conditional branch jump) is encountered in the code, a function call or the like can change the instruction of the program execution flow, the current chunk is ended, and the next chunk is started. Each chunk has a unique id, which is also their entry point, which is an offset from the start address of the function. Possible subsequent chunk ids of the current chunk when executed can be calculated for jump instructions or function call instructions by analyzing the operands of the instructions. 2. And connecting the chunks together through the values of the self id and the subsequent chunk id, so as to construct the CFG.

A statistic unit 742 for counting the second class functions with the specified feature value in all the first class functions; alternatively, the specified feature value may represent the same feature value of the same function, such as a return value of the function, and the second function may be determined by looking up a feature value of which the return value may be empty, but is not limited to this representation.

A detecting unit 744, connected to the constructing unit 740 and the counting unit 742, for searching the branch where the second type of function is located in the first CFG, and determining whether the branch where the second type of function is located is subjected to exception handling, and if so, determining that the application program has no bug; and if the judgment result is negative, determining that the application program has a bug. Optionally, the exception handling may take the following form, but is not limited thereto: and setting a jump instruction or a call instruction for indicating that the current instruction is abnormal and jumping to other instructions.

For the branch where the second type function is located is searched for in the first CFG by the detection unit 744, in order to improve efficiency and accuracy of detection, the detection unit 744 is further configured to filter the branch in the first CFG according to a preset rule to obtain a second CFG; and searching the branch where the second type of function is located in the second CFG. The following description will be given taking an application program based on the android system as an example.

1. summarizing an application program entry function of an Android system;

2. finding out points which only have out-degree and no in-degree in the CFG;

3. judging whether the point is an entry function;

4. and traversing all the sub-nodes of the current node, and deleting all the points which can only be communicated by the node.

For example, the detecting unit 744 is further configured to delete the designated node and the node that can only be connected by the designated node in the first CFG, where the function corresponding to the designated node is a function with only out-degree and no in-degree. Therefore, pruning processing is carried out on the first CFG, and the retrieval efficiency and accuracy are improved.

In an optional embodiment, the obtaining module 72 is further configured to obtain description information of the specified function from an open source document on the network side.

The modules referred to in the present embodiment may be implemented by software or hardware, respectively, and for the latter, for example, the following may be implemented, but not limited to: the conversion module 70, the acquisition module 72 and the detection module 74 are all located in the same processor; alternatively, the conversion module 70, the acquisition module 72, and the detection module 74 are located in the first processor, the second processor, and the third processor, respectively; alternatively, the conversion module 70 and the acquisition module 72 are located in the same processor, and the detection module 74 is located in another processor; alternatively, the acquisition module 72 and the detection module 74 may be located in the same processor, while the conversion module 70 may be located in another processor, but is not limited to the above combination.

The vulnerability detection device of the application program provided by the embodiment of the invention can also achieve the goal of vulnerability detection in a static analysis mode, and meanwhile, as each step is determined, the detection result can be more comprehensive, thereby solving the technical problems of low efficiency, incomplete detection result and the like of a vulnerability detection scheme.

Example 4

The embodiment of the invention can provide a computer terminal which can be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may also be replaced with a terminal device such as a mobile terminal.

Optionally, in this embodiment, the computer terminal may be located in at least one network device of a plurality of network devices of a computer network.

In this embodiment, the computer terminal may execute the program code of the following steps in the vulnerability detection method of the application program: converting an installation file of an application program to be detected into a code file; acquiring description information of a specified function, wherein the specified function is a function for reflecting specified behaviors; and according to the description information, determining a first class function matched with the specified description information in the code file, and detecting the vulnerability of the application program according to the first class function.

Alternatively, fig. 9 is a block diagram of a computer terminal according to an embodiment of the present invention. As shown in fig. 9, the computer terminal a may include: one or more processors 91 (only one shown), a memory 93, and a transmission device 95.

The memory 93 may be configured to store software programs and modules, such as program instructions/modules corresponding to the security vulnerability detection method and apparatus in the embodiment of the present invention, and the processor 91 executes various functional applications and data processing by running the software programs and modules stored in the memory 93, that is, implements the above-mentioned method for detecting a system vulnerability attack. The memory 93 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 93 may further include memory located remotely from the processor 91, which may be connected to terminal a via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 95 is used for receiving or transmitting data via a network. Examples of the network may include a wired network and a wireless network. In one example, the transmission device 95 includes a network adapter (NIC) that can be connected to a router via a network cable and other network devices to communicate with the internet or a local area network. In one example, the transmission device 95 is a Radio Frequency (RF) module, which is used for communicating with the internet in a wireless manner.

Specifically, the memory 93 is used for storing preset action conditions, information of preset authorized users, and application programs.

The processor 91 may call the information and applications stored in the memory 93 through the transmission device to perform the following steps: converting an installation file of an application program to be detected into a code file; acquiring description information of a specified function, wherein the specified function is a function for reflecting specified behaviors; and according to the description information, determining a first class function matched with the specified description information in the code file, and detecting the vulnerability of the application program according to the first class function.

Optionally, the processor 91 may further execute program codes of the following steps: constructing a first control flow graph CFG of a branch where the first type of function is located, and counting second type of functions with specified characteristic values in all the first type of functions; searching the branch where the second type of function is located in the first CFG, judging whether the branch where the second type of function is located is subjected to exception handling or not, and if so, determining that the application program does not have a bug; and if the judgment result is negative, determining that the application program has a bug. Alternatively, the "exception handling" here may be represented as: and setting a jump instruction or a call instruction for indicating that the current instruction is abnormal and jumping to other instructions.

Optionally, the processor 91 may further execute program codes of the following steps: filtering the branches in the first CFG according to a preset rule to obtain a second CFG; and searching the branch of the second type function in the second CFG.

Optionally, the processor 91 may further execute program codes of the following steps: and deleting the designated node and the nodes which can be only communicated by the designated node in the first CFG, wherein the function corresponding to the designated node is a function with only out degree and no in degree.

Optionally, the processor 91 may further execute program codes of the following steps: the description information of the specified function is obtained from the open source document at the network side, and the description information can be crawled from the open source document in a web crawler mode, for example.

The embodiment of the invention provides a scheme for detecting the vulnerability of the application program by combining the static code with the description information of the function involved in the static code. The technical problems that the vulnerability detection scheme is low in efficiency and incomplete in detection result are solved.

It can be understood by those skilled in the art that the structure shown in fig. 9 is only an illustration, and the computer terminal may also be a terminal device such as a smart phone (e.g., an Android phone, an iOS phone, etc.), a tablet computer, a palmtop computer, a Mobile Internet Device (MID), a PAD, and the like. Fig. 9 is a diagram illustrating a structure of the electronic device. For example, the computer terminal a may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in fig. 9, or have a different configuration than shown in fig. 9.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by a program instructing hardware associated with the terminal device, where the program may be stored in a computer-readable storage medium, and the storage medium may include: flash disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.

Example 4

The embodiment of the invention also provides a storage medium. Optionally, in this embodiment, the storage medium may be configured to store a program code executed by the vulnerability detection method of the application program provided in the first embodiment.

Optionally, in this embodiment, the storage medium may be located in any one of computer terminals in a computer terminal group in a computer network, or in any one of mobile terminals in a mobile terminal group.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: converting an installation file of an application program to be detected into a code file; acquiring description information of a specified function, wherein the specified function is a function for reflecting specified behaviors; and according to the description information, determining a first class function matched with the specified description information in the code file, and detecting the vulnerability of the application program according to the first class function.

Optionally, the storage medium may further include program code for performing the following steps: constructing a first control flow graph CFG of a branch where the first type of function is located, and counting second type of functions with specified characteristic values in all the first type of functions; searching the branch where the second type of function is located in the first CFG, judging whether the branch where the second type of function is located is subjected to exception handling or not, and if so, determining that the application program does not have a bug; and if the judgment result is negative, determining that the application program has a bug. Alternatively, the "exception handling" here may be represented as: and setting a jump instruction or a call instruction for indicating that the current instruction is abnormal and jumping to other instructions.

Optionally, the storage medium may further include program code for performing the following steps: filtering the branches in the first CFG according to a preset rule to obtain a second CFG; and searching the branch of the second type function in the second CFG.

Optionally, the storage medium may further include program code for performing the following steps: and deleting the designated node and the nodes which can be only communicated by the designated node in the first CFG, wherein the function corresponding to the designated node is a function with only out degree and no in degree.

Optionally, the storage medium may further include program code for performing the following steps: the description information of the specified function is obtained from the open source document at the network side, and the description information can be crawled from the open source document in a web crawler mode, for example.

It should be noted here that any one of the computer terminal groups may establish a communication relationship with the web server and the scanner, and the scanner may scan the value commands of the web application executed by the php on the computer terminal.

The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.

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

In the embodiments provided in the present application, it should be understood that the disclosed physical device can be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, 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, units or modules, and may be in an electrical 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.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

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, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.

Claims

1. A vulnerability detection method of an application program is characterized by comprising the following steps:

converting an installation file of an application program to be detected into a code file;

acquiring description information of a specified function, wherein the specified function is a function for reflecting specified behaviors;

according to the description information, determining a first class of function matched with the specified description information in the code file, and filtering out a second class of function which can be called by the outside from the first class of function;

judging whether the branch of the second type of function is subjected to exception handling or not;

if the judgment result is negative, determining that the application program has a bug;

wherein, the filtering out the second type of function which can be called by the outside from the first type of function comprises:

constructing a first control flow graph CFG of a branch where the first type of function is located, and counting second type of functions with specified characteristic values in all the first type of functions;

and searching the branch where the second class of function is located in the first CFG.

2. The method of claim 1, wherein the exception handling comprises:

and setting a jump instruction or a call instruction for indicating that the current instruction is abnormal and jumping to other instructions.

3. The method of claim 1, wherein finding the branch in the first CFG where the second type of function is located comprises:

filtering branches in the first CFG according to a preset rule to obtain a second CFG;

and searching the second CFG for the branch where the second type of function is located.

4. The method of claim 3, wherein filtering the branches in the first CFG according to a preset rule comprises:

and deleting the designated node and the nodes which can be only communicated by the designated node in the first CFG, wherein the function corresponding to the designated node is a function with only out degree and no in degree.

5. The method of claim 1, wherein the specifying the feature value comprises: a return value of the first type function.

6. The method of claim 1, wherein obtaining description information for the specified function comprises:

and acquiring the description information of the specified function from an open source document at the network side.

7. The method according to claim 6, wherein obtaining the description information of the specified function from the open source document on the network side comprises:

and acquiring the description information from the open source document in a web crawler mode.

8. The method according to any of claims 1 to 7, wherein the function reflecting the specified behavior is an API function and/or the vulnerability is a denial of service (DOS) vulnerability.

9. An apparatus for vulnerability detection of an application program, comprising:

the conversion module is used for converting the installation file of the application program to be detected into a code file;

the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring the description information of a specified function, and the specified function is a function for reflecting specified behaviors;

the detection module is used for determining a first type of function matched with the specified description information in the code file according to the description information and filtering a second type of function which can be called by the outside from the first type of function; judging whether the branch of the second type of function is subjected to exception handling or not; if the judgment result is negative, determining that the application program has a bug;

wherein, the detection module includes:

the construction unit is used for constructing a first control flow graph CFG of a branch where the first type of function is located;

the statistical unit is used for counting the second class functions with specified characteristic values in all the first class functions;

and the detection unit is used for searching the branch where the second class of function is located in the first CFG.

10. The apparatus of claim 9, wherein the exception handling comprises: and setting a jump instruction or a call instruction for indicating that the current instruction is abnormal and jumping to other instructions.

11. The apparatus according to claim 9, wherein the detecting unit is further configured to filter branches in the first CFG according to a preset rule to obtain a second CFG; and searching the second CFG for the branch where the second type of function is located.

12. The apparatus according to claim 11, wherein the detecting unit is configured to delete a designated node and nodes that can only be connected by the designated node in the first CFG, and the function corresponding to the designated node is a function with only out-degree and no in-degree.

13. The apparatus according to claim 9, wherein the obtaining module is further configured to obtain description information of the specified function from an open source document on the network side.