A method and system for detecting application vulnerabilities

Abstract

A method and system for detecting application vulnerabilities. The embodiments of the present invention adopt a combination of static detection and dynamic detection when detecting application vulnerabilities. In static detection, the application code is statically scanned to determine whether there is application vulnerability information based on configuration; in dynamic detection, potential attack information is extracted from the application code according to the set rules, and the obtained potential attack information is fuzzy tested using a dynamic detection method to make the application code abnormal. A feature vector is extracted from the abnormal state of the application, input into a trained vulnerability rule model, and output whether the potential attack information contains vulnerability information. It can be seen that the embodiments of the present invention efficiently and accurately detect application vulnerabilities.

Description

Technical Field

[0001] The present invention relates to computer technology, and in particular to a method and system for detecting application vulnerabilities. Background Art

[0002] By the end of 2017, the market share of mobile terminals using the Android operating system was 85.9%, and the total number of various types of applications developed based on the Android operating system is also growing rapidly. Most Android application developers often do not have sufficient awareness of security programming, and there is a lack of comprehensive application security scanning tools on the market, which makes the security risks of applications particularly serious. Among them, application vulnerabilities developed based on the Android operating system can be divided into several types of vulnerabilities according to their hazards: Dos attacks, code execution, memory corruption, privacy theft, privilege escalation, and bypass. Application vulnerabilities are a key factor affecting application security, so how to effectively identify application vulnerabilities before attacks is crucial to the interests and security of users who use applications and companies involved in applications.

[0003] Currently, static detection is used to detect application vulnerabilities. Specifically, there are two methods:

[0004] The first method is to set up a decompiled Android system installation package (Apk), run the set decompiled Apk in the application, obtain the decompiled intermediate code, and determine whether the application has vulnerabilities based on the decompiled intermediate code;

[0005] The second method uses the taint analysis method. Set a decompiled Apk, run the set decompiled Apk in the application, get the decompiled intermediate code, generate the application control flow graph based on the decompiled intermediate code, and detect whether there is a path between the points that may cause problems and the conditions that cause them based on the generated application control flow graph, so as to determine whether there are vulnerabilities in the application when it is executed.

[0006] However, no matter which method is used, there are disadvantages: the first method does not accurately judge application vulnerabilities. This method only analyzes a section of the application code, lacks verification of the application vulnerability detection results, and requires developers who detect application vulnerabilities to manually judge the application vulnerabilities in the decompiled intermediate code, which is cumbersome and time-consuming. The second method requires a large amount of memory. Since each independent code segment of the application needs to be decompiled and structured nodes and generated conditions are obtained, and a control flow graph needs to be used to link these nodes, when the application code size is relatively large, the entire amount of data for verifying application vulnerabilities will grow exponentially, requiring a considerable amount of memory.

[0007] Furthermore, regardless of whether the first or second method is used, the conditions for determining the occurrence of application vulnerabilities are not sufficient. The occurrence of application vulnerabilities depends not only on the code, but also on other methods. The above method only analyzes the application code as a basis for judgment, and lacks effective judgment on other ways in which application vulnerabilities are generated.

[0008] Therefore, how to efficiently and accurately detect application vulnerabilities has become a technical problem that needs to be solved urgently. Summary of the invention

[0009] In view of this, an embodiment of the present invention provides an application vulnerability detection method, which can detect application vulnerabilities efficiently and accurately.

[0010] The embodiment of the present invention also provides an application vulnerability detection system, which can detect application vulnerabilities efficiently and accurately.

[0011] According to the above object, the present invention is achieved in that:

[0012] A method for detecting application vulnerabilities, comprising: static detection and dynamic detection of application code, wherein:

[0013] Static detection: statically scan the application code to obtain configuration-based application vulnerability information;

[0014] Dynamic detection: Extract potential attack information from the application code according to the set rules;

[0015] Perform fuzz testing on the obtained potential attack information to make the application code abnormal;

[0016] A feature vector is extracted under the abnormal state of the application, inputted into a trained vulnerability rule model, and outputted whether the potential attack information contains vulnerability information.

[0017] The potential attack information includes: attack surface, attack vector and heuristic value, wherein:

[0018] The attack surface is a method for predicting a possible risk when executing a certain section of application code, the attack vector is a parameter of the attack surface, and the heuristic value is a constant used before the application code execution process where the attack surface is located;

[0019] The acquisition process of the attack vector and the heuristic value is as follows:

[0020] Use hooks to obtain values ​​in the actual running environment of the application code;

[0021] Or the attack surface is injected into the application code, causing the application code to have a vulnerability and generate a mutation value.

[0022] The rules are parsed from a set rule file, which is a method flow composed of one or more groups of intermediate codes obtained after decompilation in the application code, including: the name, description information and repair method of the application vulnerability.

[0023] The rule file also includes: one or more corresponding functions for extracting various condition information that may cause application vulnerabilities from the application code.

[0024] The process of performing fuzz testing on the obtained potential attack information to cause the application code to generate an exception is as follows:

[0025] When the application code is executed to the obtained attack surface, the attack vector is mutated by using the heuristic value corresponding to the attack surface, and then the attack surface is attacked, so that the application code generates an exception and the exception information is captured.

[0026] The attack on the attack surface, causing the application code to generate an exception and capturing the exception information, includes:

[0027] Monitor application code unresponsiveness (ANR) by injecting code into the main thread of the application code; detect native exceptions in the dynamic library of the application code by monitoring system signals; detect crashes in application code execution by injecting code into the exception handler ExceptionHandler; parse path files in the application; and / or extract environmental data of the application code.

[0028] The process of extracting the feature vector under the abnormal state of the application is:

[0029] Construct a vector from all the exception types. If an exception in the vector occurs when attacking the attack surface, the corresponding value is set to 1, otherwise it is set to 0, to obtain an exception vector.

[0030] The CPU occupancy, memory occupancy and exception vector when the exception occurs are used as feature vectors.

[0031] The trained vulnerability rule model is obtained by using the feature vectors when known application vulnerabilities occur and the feature vectors collected when the corresponding application code is running normally as a training set, and inputting them into a set machine learning algorithm for training.

[0032] A detection system for application vulnerabilities, comprising: a static detection unit and a dynamic detection unit, wherein the dynamic detection unit comprises an extraction module, a preprocessing module and a heuristic vulnerability identification module;

[0033] A static detection unit, used to perform static scanning on application code to obtain configuration-based application vulnerability information;

[0034] The extraction module is used to set rules to extract potential attack information from the application code;

[0035] A preprocessing module is used to perform fuzz testing on the obtained potential attack information to make the application code abnormal;

[0036] The heuristic vulnerability identification module is used to extract feature vectors under abnormal conditions of the application, input the feature vectors into the trained vulnerability rule model, and output whether the potential attack information contains vulnerability information.

[0037] A device for detecting application vulnerabilities, comprising:

[0038] Memory; and

[0039] A processor coupled to the memory, the processor being configured to execute any of the above-mentioned application vulnerability detection methods based on instructions stored in the memory.

[0040] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements any of the above-mentioned application vulnerability detection methods.

[0041] It can be seen from the above scheme that the embodiment of the present invention adopts a combination of static detection and dynamic detection when detecting application vulnerabilities. In static detection, it determines whether there is application vulnerability information based on the configuration by statically scanning the application code; in dynamic detection, it extracts potential attack information from the application code according to the set rules, uses dynamic detection to perform fuzzy testing on the obtained potential attack information so that the application code generates an exception, extracts feature vectors in the abnormal state of the application, inputs them into the trained vulnerability rule model, and outputs whether the potential attack information has vulnerability information. Since the embodiment of the present invention uses both static and dynamic detection for application vulnerabilities, the detection of application vulnerabilities will not miss any detection and has high accuracy; since the embodiment of the present invention first extracts potential attack information from the application code, and then determines whether there is an application vulnerability from the potential attack information, rather than constructing a complete method flow chart for the entire application code, it is more time-saving, labor-saving, resource-saving, and efficient. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 A flow chart of a vulnerability detection method for an application provided by an embodiment of the present invention;

[0043] Figure 2 A schematic diagram of the types of exceptions involved in performing fuzzy testing on the potential attack information obtained to cause an exception in the application code provided by an embodiment of the present invention;

[0044] Figure 3A schematic diagram of the structure of a vulnerability detection system for an application provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0045] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments.

[0046] In order to efficiently and accurately detect application vulnerabilities, the embodiments of the present invention adopt a combination of static detection and dynamic detection when detecting application vulnerabilities. During static detection, a static scan is performed on the application code to determine whether there is application vulnerability information based on configuration; during dynamic detection, potential attack information is extracted from the application code according to set rules, and a dynamic detection method is used to perform fuzzy testing on the obtained potential attack information to cause anomalies in the application code. A feature vector is extracted in the abnormal state of the application and input into a trained vulnerability rule model, and outputs whether the potential attack information has vulnerability information.

[0047] It can be seen that the embodiment of the present invention adopts both static and dynamic detection for application vulnerabilities, so there will be no missed detection in the detection of application vulnerabilities, and the accuracy is high; because the embodiment of the present invention first extracts potential attack information from the application code, and then determines whether there is an application vulnerability from the potential attack information, rather than constructing a complete method flow chart for the entire application code, it is more time-saving, labor-saving, resource-saving and efficient.

[0048] Figure 1 The following is a flow chart of the application vulnerability detection method provided by the embodiment of the present invention, wherein the specific steps are as follows:

[0049] Step 101: Perform static scanning on the application code to obtain configuration-based application vulnerability information;

[0050] Step 102: extract potential attack information from the application code according to the set rules;

[0051] Step 103: Use a dynamic detection method to perform a fuzzy test on the obtained potential attack information to cause an exception in the application code;

[0052] Step 104: extract a feature vector under the abnormal state of the application, input it into the trained vulnerability rule model, and output whether the potential attack information has vulnerability information.

[0053] In this method, when static scanning is performed on the application code in step 101, existing scanning can be used to detect and obtain configuration-based application vulnerability information.

[0054] In this method, the potential attack information includes: attack surface, attack vector and heuristic value, which can be extracted according to the set rules, wherein the attack surface is a method for predicting the possible risk of executing a certain section of application code, the attack vector is a parameter of the attack surface, and the heuristic value is a constant used before the application code execution process where the attack surface is located. Here, there are two ways to obtain the attack vector and heuristic value, one is to use the hook method to directly obtain the value in the real running environment of the application code, and the other is the mutation value generated by the injection of the attack surface causing a vulnerability in the application code.

[0055] In this method, the rule is parsed from a rule file, which is a method flow composed of one or more groups of intermediate codes obtained after decompilation in the application code, and is a necessary condition for the existence of application vulnerability detection. The rule file includes: the name, description information and repair method of the application vulnerability, which is used to score the vulnerability risk of the entire application and automatically output a scanning report. Furthermore, the rule file also includes corresponding functions for extracting various other conditional information that may cause application vulnerabilities from the application code. Specifically, some functions are predefined to extract other conditional information of the application code, such as the application code programming interface level function (api_level()), the custom permission function (with_permission) and the interface verification function (shal()). For the generation of application vulnerabilities that depends on the other conditional information of one or more extracted application codes, the defined corresponding functions are used for extraction. These functions support logical relationships such as and, or, greater than or / and less than. After the defined function is injected into the application code, a Boolean data type value (boolean) will be returned in the subsequent fuzzy testing process. According to the returned boolean, it can be determined whether the other conditional information extracted from the application code will generate corresponding application vulnerabilities.

[0056] Let's take a specific example of a rule file.

[0057] Suppose we want to detect a high-risk application decompression download (ZiperDown) vulnerability. The principle of this application vulnerability is that when the string ".. / " appears in the Zip compressed package file downloaded by the application, the attacker can use multiple ".. / " to change the storage location of a file in the Zip package during decompression, overwriting the original file of the application. If the file overwritten by the application is a shared (so, shared object) file, an Android system virtual machine running file (dex) file, or a proposed executable file odex file, it may cause a denial of service vulnerability in the application at the least, affecting the availability of the application, or it may cause an arbitrary code execution vulnerability in the terminal to which the application belongs, endangering the terminal security and information security of the user. In this case, the rule file to be set is specifically:

[0058]

[0059]

[0060] In the above rule file, the explanations of each field name include:

[0061] description indicates the description of the application vulnerability, name indicates the name of the application vulnerability, group indicates the group where the application vulnerability is located, risk_score indicates the risk score of the application vulnerability, repair indicates the application vulnerability repair suggestion, method_flow indicates the method flow, call indicates a single method, var indicates a parameter, appear indicates whether it appears in the method flow, and environment indicates the environmental conditions that trigger the application vulnerability; with_permission indicates the permission-granting function, which is used to detect whether the application has declared the permission, and dynamic_verify indicates the corresponding dynamic verification of the content identified by the identifier.

[0062] Parse the above rule file and get the set rule process as follows:

[0063] 1) Parse the application code according to each item in the description in the rule file for subsequent output of the analysis report.

[0064] 2) Parse the method flow from top to bottom. In a group of methods defined in the method flow (method_flow), variables with associations are marked with the same tag, which are called related variables. This group of methods is connected into a directed method flow. Before the entire method flow, all constants about related variables are extracted and saved as heuristic values.

[0065] 3) The string in environment is an expression, which is parsed by the open source scanning engine (Yara) compiler and supports rich operators such as and, or, and number (#), which can arbitrarily configure the environment where the application vulnerability is generated;

[0066] 4) dynamic_verify: It stores one or more identifiers. For the ZipperDown application vulnerability, the application code will dynamically monitor the changes of the .ZIP file in the Android operating system according to the ".zip" identifier, and perform subsequent fuzz testing on the attack surface based on the attack vector and heuristic value provided in step 2).

[0067] In this method, the process of using a dynamic detection method to perform fuzzy testing on the obtained potential attack information to cause an exception in the application code in step 103 is as follows:

[0068] When the user interface (UI) is used to traverse the application code and execute to a certain attack surface, the attack vector is mutated using the heuristic value of the corresponding attack surface, and then the attack surface is attacked. When an exception occurs in the application code execution, the exception information is captured by the set exception monitor;

[0069] During the specific fuzz testing, capturing the exception information of the application execution means that there are real and exploitable vulnerabilities. Multiple dimensions are used to judge the exception information of the application code execution: monitoring the application code unresponsiveness (ANR) by injecting code into the main thread of the application code; detecting the application code dynamic library (native) exception by monitoring the system signal; or / and detecting the crash of the application code execution by injecting code into the exception handler (ExceptionHandler).

[0070] For the application code that uses ExceptionHandler to inject the captured code into the executed code, the types of exceptions captured include: mathematical operation exception (ArithmeticException), null pointer exception (NullPointerException), no access permission (IllegalAccessException), file end exception (E0Fexception), read length exception (BufferUnderflowException Buffer), array out of bounds exception (IndexOut0fBoundsException), decompression exception (ZipException) and communication exception (SSLExceptionSSL).

[0071] The native exceptions of the application code are detected by monitoring the system signals. Specifically, the signal monitoring function method is injected into the JNI_OnLoad method in the application code. The types of native exceptions of the application code obtained include: illegal memory reference (SIGSEGV), mathematical operation error (SIGFPE), illegal command (SIGILL), abnormal system call (SIGYS) and CPU timeout (SIGXCPU).

[0072] The process of causing the application code to generate an exception and capturing the exception information also includes: parsing the path (traces) file in the application, and obtaining the application exception types involving the application so call: the so file related to the Android system runtime on which the application is based (libandroid_runtime.so) and the so file related to memory management (libdvm.so).

[0073] The application code is caused to generate an exception and the exception information is captured, and the exception types generated for the environment data for executing the application code are: CPU occupancy percentage and memory occupancy percentage.

[0074] like Figure 2 As shown, Figure 2 A schematic diagram of the types of exceptions involved in the fuzzy test of the potential attack information obtained to make the application code generate exceptions provided by the embodiment of the present invention. During the fuzzy test, the traces file test of the application, the native exception test to obtain the tombstone file, the Java-based application code test and the memory CPU occupancy test are performed, so as to construct a feature vector, input it into the trained application vulnerability rule model for processing, and output information on whether there is an application vulnerability.

[0075] The process of extracting the feature vector under the abnormal state of the application and inputting it into the trained vulnerability rule model is as follows:

[0076] Through the analysis of a large amount of exception information, it can be found that the types of exceptions generated when the application code is abnormal are limited, so the embodiment of the present invention constructs a vector for all the exception types. If an exception in the vector occurs when attacking the attack surface, the corresponding value is set to 1, otherwise it is set to 0, so that the exception vector is obtained, and then the CPU occupancy, memory occupancy and exception vector when the exception occurs are used as feature vectors as feature vectors, which are input into the trained vulnerability rule model to output whether there is a vulnerability in the attack surface.

[0077] Here, the trained vulnerability rule model uses the feature vectors when known application vulnerabilities occur and the feature vectors collected when the corresponding application code runs normally as the training set, and inputs them into the set machine learning algorithm such as the gradient descent tree (GBDT) for learning. The output obtained can distinguish whether an application vulnerability has occurred and the specific meaning of the application vulnerability.

[0078] Here, the trained vulnerability rule model can be updated in real time.

[0079] Figure 3 A schematic diagram of the structure of a vulnerability detection system for an application provided by an embodiment of the present invention, as shown in the figure, includes: a static detection unit and a dynamic detection unit, wherein the dynamic detection unit includes an extraction module, a preprocessing module and a heuristic vulnerability identification module;

[0080] A static detection unit, used to perform static scanning on application code to obtain configuration-based application vulnerability information;

[0081] The extraction module is used to set rules to extract potential attack information from the application code;

[0082] A preprocessing module is used to perform fuzz testing on the obtained potential attack information to make the application code abnormal;

[0083] The heuristic vulnerability identification module is used to extract feature vectors under abnormal conditions of the application, input the feature vectors into the trained vulnerability rule model, and output whether the potential attack information contains vulnerability information.

[0084] The method and system provided by the embodiment of the present invention can quickly respond to application vulnerabilities according to the rule file, without the need to manually handle application vulnerabilities. The method and system provided by the embodiment of the present invention reduce the memory requirements for scanning application vulnerabilities. The method and system provided by the embodiment of the present invention only need to monitor the code execution process in the current attack in the application code, without the need to construct a complete control flow graph for all application codes, thereby reducing memory usage and improving the accuracy of application vulnerability scanning. The attack surface is automatically attacked purposefully through a method combining static risk and dynamic verification, saving the labor cost of application vulnerability discovery.

[0085] A device for detecting application vulnerabilities, comprising: a memory; and

[0086] A processor coupled to the memory, the processor being configured to execute any of the above-mentioned application vulnerability detection methods based on instructions stored in the memory.

[0087] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements any of the above-mentioned application vulnerability detection methods.

[0088] The above preferred embodiments are used to further explain the purpose, technical solutions and advantages of the present invention in detail. It should be understood that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for detecting application vulnerabilities, characterized in that: include: Static and dynamic detection of application code, including: Static detection: statically scan the application code to obtain configuration-based application vulnerability information; Dynamic detection: Extract potential attack information from the application code according to the set rules; the potential attack information includes: attack surface, attack vector and heuristic value, wherein the attack surface is the part of the application code that is predicted to have a risk when executing, the attack vector is the parameter of the attack surface, and the heuristic value is the constant used before the application code execution process where the attack surface is located; Perform fuzz testing on the obtained potential attack information to make the application code abnormal; A feature vector is extracted in the abnormal state of the application, input into the trained vulnerability rule model, and output whether the potential attack information has vulnerability information; the CPU occupancy, memory occupancy and exception vector when the exception occurs are used as the feature vector.

2. The detection method according to claim 1, characterized in that The rules are parsed from a set rule file, which is a method flow composed of one or more groups of intermediate codes obtained after decompilation in the application code, including: the name, description information and repair method of the application vulnerability.

3. The detection method according to claim 2, characterized in that The rule file also includes: one or more corresponding functions for extracting various condition information that may cause application vulnerabilities from the application code.

4. The detection method according to claim 1, characterized in that The process of performing fuzz testing on the obtained potential attack information to cause the application code to generate an exception is as follows: When the application code is executed to the obtained attack surface, the attack vector is mutated by using the heuristic value corresponding to the attack surface, and then the attack surface is attacked, so that the application code generates an exception and the exception information is captured.

5. The method according to claim 4, characterized in that The attack on the attack surface, causing the application code to generate an exception and capturing the exception information, includes: Monitor application code unresponsiveness (ANR) by injecting code into the main thread of the application code; detect native exceptions in the dynamic library of the application code by monitoring system signals; detect crashes in application code execution by injecting code into the exception handler ExceptionHandler; parse path files in the application; and / or extract environmental data of the application code.

6. The method according to claim 1, characterized in that The process of extracting the feature vector under the abnormal state of the application is: Construct a vector from all the exception types. If an exception in the vector occurs when attacking the attack surface, the corresponding value is set to 1, otherwise it is set to 0, to obtain an exception vector. The CPU occupancy, memory occupancy and exception vector when the exception occurs are used as feature vectors.

7. The method according to claim 1, characterized in that The trained vulnerability rule model is obtained by using the feature vectors when known application vulnerabilities occur and the feature vectors collected when the corresponding application code is running normally as a training set, and inputting them into a set machine learning algorithm for training.

8. A system for detecting application vulnerabilities, characterized in that: include: A static detection unit and a dynamic detection unit, wherein the dynamic detection unit includes an extraction module, a preprocessing module and a heuristic vulnerability identification module; A static detection unit, used to perform static scanning on application code to obtain configuration-based application vulnerability information; An extraction module, configured to extract potential attack information from the application code according to the set rules; the potential attack information includes: attack surface, attack vector and heuristic value, wherein the attack surface is the part of the application code that is predicted to have a risk when executed, the attack vector is a parameter of the attack surface, and the heuristic value is a constant used before the application code execution process where the attack surface is located; A preprocessing module is used to perform fuzz testing on the obtained potential attack information to make the application code abnormal; The heuristic vulnerability identification module is used to extract feature vectors under the abnormal state of the application, input them into the trained vulnerability rule model, and output whether the potential attack information contains vulnerability information; the CPU occupancy, memory occupancy and exception vector when the exception occurs are used as the feature vector.

9. A device for detecting application vulnerabilities, characterized in that: include: Memory; as well as A processor coupled to the memory, wherein the processor is configured to execute the method for detecting application vulnerabilities according to any one of claims 1 to 7 based on instructions stored in the memory.

Images