A vulnerability detection method, apparatus, electronic device, and storage medium

Abstract

This application discloses a vulnerability detection method, apparatus, electronic device, and computer-readable storage medium. The method includes: acquiring a target executable file to be detected and determining each stage of the vulnerability exploitation process of the target executable file; performing feature detection on each stage of the target executable file and counting the number of features detected at each stage; calculating a risk score for the target executable file based on the number of features detected at each stage; and determining the vulnerability detection result of the target executable file based on the risk score. The vulnerability detection method provided in this application achieves static vulnerability detection, is simple to implement, consumes few resources, and has good detection results.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a vulnerability detection method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] As the number of disclosed Windows kernel vulnerabilities and related exploitation methods increases year by year, many of these methods are previously unseen. For this reason, previous detection methods are ineffective in detecting these exploit samples. On the other hand, these Windows kernel vulnerability exploits are extremely dangerous, capable of gaining root system privileges, leading to the theft of valuable data from victims' computers and causing significant financial losses.

[0003] In related technologies, vulnerability detection methods mainly include the following steps: creating a CPU (central processing unit) instruction simulator based on Unicorn (a lightweight, cross-platform CPU simulation framework supporting multiple architectures); creating simulated operating systems corresponding to each vulnerability's operating platform; wherein each operating simulation system runs as a single process; performing privilege escalation vulnerability detection based on the CPU instruction simulator and each simulated operating system to obtain vulnerability detection results. This approach, using processes as container nodes and leveraging the CPU simulator and multiple operating simulation systems for vulnerability extraction and detection, improves the efficiency of privilege escalation vulnerability detection and enables cross-platform detection of privilege escalation vulnerabilities.

[0004] First, because Windows kernel exploit samples often check the version of the current runtime environment, the vulnerability won't trigger if the runtime environment doesn't match. This limits the detection capabilities of common dynamic and static detection engines. Second, due to the inherent limitations of the Unicorn static engine in modal execution, this simulation execution method cannot effectively detect samples with more covert techniques or those highly dependent on the execution environment.

[0005] Therefore, how to improve the effectiveness of vulnerability detection is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0006] The purpose of this application is to provide a vulnerability detection method, apparatus, electronic device, and computer-readable storage medium, which improve the vulnerability detection effect.

[0007] To achieve the above objectives, this application provides a vulnerability detection method, comprising:

[0008] Obtain the target executable file to be detected and determine the various stages of the vulnerability exploitation process of the target executable file;

[0009] Feature detection is performed on each stage of the target executable file, and the number of features detected in each stage is counted.

[0010] The risk score of the target executable file is calculated based on the number of features detected in each of the aforementioned stages;

[0011] The vulnerability detection result of the target executable file is determined based on the risk score.

[0012] The aforementioned stages include any one or a combination of any of the following: vulnerability triggering stage, heap feng shui stage, kernel information leakage stage, arbitrary address read / write primitive construction stage, control flow hijacking stage, and privilege escalation stage.

[0013] The process includes feature detection at each stage of the target executable file, and counting the number of features detected at each stage, including:

[0014] Determine the static rules corresponding to each stage, and perform feature detection on each stage of the target executable file based on the static rules corresponding to each stage, and count the number of features detected in each stage.

[0015] The static rules include at least the target string. The feature detection of each stage of the target executable file based on the static rules corresponding to each stage, and the counting of the number of features detected in each stage, includes:

[0016] The target executable file is matched with the target string based on the static rules corresponding to each stage;

[0017] Count the number of target strings matched by the static rules corresponding to each stage;

[0018] Accordingly, the risk score of the target executable file is calculated based on the number of features detected at each stage, including:

[0019] The risk score of the target executable file is calculated based on the number of target strings matched by the static rules corresponding to each stage.

[0020] The target string includes function strings and / or feature codes.

[0021] The step of calculating the risk score of the target executable file based on the number of features detected in each stage includes:

[0022] The weighting coefficients corresponding to each stage are determined, and the number of features detected in each stage is weighted and calculated based on the weighting coefficients corresponding to each stage to obtain the risk score of the target executable file.

[0023] The step of determining the vulnerability detection result of the target executable file based on the risk score includes:

[0024] If the risk score is less than or equal to the first preset value, the vulnerability level of the target executable file is determined to be low.

[0025] If the risk score is greater than the first preset value and less than or equal to the second preset value, then the vulnerability level of the target executable file is determined to be medium; wherein, the second preset value is greater than the first preset value;

[0026] If the risk score is greater than the second preset value, the vulnerability level of the target executable file is determined to be high.

[0027] To achieve the above objectives, this application provides a vulnerability detection device, comprising:

[0028] The acquisition module is used to acquire the target executable file to be detected and determine the various stages of the vulnerability exploitation process of the target executable file;

[0029] The detection module is used to perform feature detection on each stage of the target executable file and count the number of features detected in each stage.

[0030] The calculation module is used to calculate the risk score of the target executable file based on the number of features detected in each stage;

[0031] The determination module is used to determine the vulnerability detection result of the target executable file based on the risk score.

[0032] To achieve the above objectives, this application provides an electronic device, comprising:

[0033] Memory, used to store computer programs;

[0034] A processor for implementing the steps of the vulnerability detection method described above when executing the computer program.

[0035] To achieve the above objectives, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the vulnerability detection method described above.

[0036] As can be seen from the above scheme, the vulnerability detection method provided in this application includes: obtaining a target executable file to be detected and determining each stage of the target executable file in the vulnerability exploitation process; performing feature detection on each stage of the target executable file and counting the number of features detected in each stage; calculating the risk score of the target executable file based on the number of features detected in each stage; and determining the vulnerability detection result of the target executable file based on the risk score.

[0037] The vulnerability detection method provided in this application performs feature detection at each stage of the vulnerability exploitation process, counts the number of features detected at each stage, calculates the risk score of the target executable file based on this score, and determines the vulnerability detection result based on the risk score. The target executable file does not need to be actually executed or matched to an execution environment, achieving static vulnerability detection. This method is simple to implement, consumes few resources, and has good detection results. Therefore, the vulnerability detection method provided in this application improves the effectiveness of vulnerability detection. This application also discloses a vulnerability detection device, an electronic device, and a computer-readable storage medium, which can achieve the same technical effects.

[0038] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. The drawings are used to provide a further understanding of this disclosure and constitute a part of the specification. They are used together with the following detailed description to explain this disclosure, but do not constitute a limitation of this disclosure. In the drawings:

[0040] Figure 1 This is a flowchart illustrating a vulnerability detection method according to an exemplary embodiment;

[0041] Figure 2 This is a structural diagram of a vulnerability detection device according to an exemplary embodiment;

[0042] Figure 3 This is a structural diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

[0043] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Furthermore, in the embodiments of this application, "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0044] This application discloses a vulnerability detection method that improves the effectiveness of vulnerability detection.

[0045] See Figure 1 A flowchart illustrating a vulnerability detection method according to an exemplary embodiment, such as... Figure 1 As shown, it includes:

[0046] S101: Obtain the target executable file to be detected and determine the various stages of the vulnerability exploitation process of the target executable file;

[0047] In practice, the target executable file to be detected is obtained. This target executable file can be a Windows platform executable file, mainly including .exe, .dll, and .sys files. Windows refers to the kernel of the Windows operating system. The Windows operating system is a series of commercial operating systems developed by Microsoft, including but not limited to Windows XP, Windows 7, Windows 8, Windows 8.1, Windows 10, and Windows 11. The kernel refers to the low-level part of an operating system, equivalent to the central nervous system of the operating system. Internally, it implements basic functions such as file operations, memory operations, and graphics operations for upper layers to call.

[0048] It is understood that the target executable file in this embodiment can come from a private source dataset, such as a private interface within a company, or from a public dataset, such as a public data platform like VirusTotal. By using a common file format identification method, such as identifying the Windows PE (Portable Execute) file format, the target executable file of the required format can be obtained.

[0049] Furthermore, the various stages of the exploit process in the target executable file are identified. A vulnerability, strictly speaking, corresponds to the English word "vulnerability," referring to a flaw in a program or piece of code. Such flaws can cause the program or operating system to fail during normal execution, resulting in significant cybersecurity risks, such as data loss or attackers gaining root privileges. Exploitation, strictly speaking, corresponds to the English word "exploit," and is often used in conjunction with "vulnerability." It can also be called "vulnerability exploitation," referring to one or more methods of using a vulnerability. When an attacker discovers a vulnerability, they need to use general or specific techniques to transform it into a scenario that can actually cause harm, and within this scenario, deploy the payload to the target address to achieve execution.

[0050] The stages in this embodiment may include the vulnerability triggering stage, the heap fengshui stage, the kernel information disclosure stage, the arbitrary address read and write primitive construction stage, the control flow hijacking stage, and the privilege escalation stage. Arbitrary address read and write primitives (AAR / AAW) refer to a capability gained during vulnerability exploitation, allowing arbitrary reading and writing of a very large area of ​​memory. Heap fengshui refers to the layout of heap blocks in memory using heap allocation functions to facilitate subsequent vulnerability exploitation. The heap is a concept in operating system memory management, referring to a custom-sized segment of memory that can be freely allocated and released.

[0051] S102: Perform feature detection on each stage of the target executable file and count the number of features detected in each stage;

[0052] In this step, feature detection is performed on each stage of the target executable file, and the number of features detected at each stage is counted.

[0053] As a possible implementation, this step may include: determining the static rules corresponding to each stage, performing feature detection on each stage of the target executable file based on the static rules corresponding to each stage, and counting the number of features detected in each stage.

[0054] In this embodiment, the feature detection static engine is a static engine, meaning it can perform matching without requiring a dynamically executed file. This embodiment is not limited to a specific static engine implementation. For example, corresponding static rules can be written using Yara syntax, Python, or other languages; no specific limitations are imposed here. Feature detection is performed on each stage of the target executable file based on the corresponding static rules, and the number of features detected at each stage is counted.

[0055] As a feasible implementation, the static rules include at least a target string. The step of performing feature detection on each stage of the target executable file based on the static rules corresponding to each stage and counting the number of features detected in each stage includes: matching the target string of the target executable file based on the static rules corresponding to each stage; and counting the number of target strings matched by the static rules corresponding to each stage.

[0056] In practical implementation, static rules can be specifically string matching rules, that is, determining whether the target executable file contains the target string corresponding to each stage. If so, the target executable file is considered to have matched the target string corresponding to that stage. A score is awarded for the rule hit rate of each stage; one point is awarded for each matched feature rule corresponding to a stage that is hit, representing one feature detected in that stage. String matching here refers to case-insensitive matching and includes both wide and narrow string matching. Case refers to the uppercase and lowercase versions of the same letter, such as A and a. Narrow strings refer to ASCII or UTF-8 encoded strings, where each letter occupies one byte of width in memory. Wide strings refer to Unicode encoded strings, where each letter occupies two bytes of width in memory. These two types of strings are different representations of the same string in the file or memory. The target string here can include function strings, signatures, or other strings. A function string refers to the name of a function, while a signature refers to a contiguous block of bytes in the memory of an executable program or file. For example, the number 8, which is of data type DWORD, is represented as 08 00 00 00 in an executable file compiled under a 32-bit compiler. This is the signature, which can be used for matching in a static engine.

[0057] During the vulnerability triggering phase, detection is performed on Windows kernel modules with a high number of vulnerabilities, such as win32k.sys, win32kfull.sys, and win32kbase.sys. Specifically, the static engine mainly matches window-related functions, menu-related functions, and device context-related functions. Function strings include, but are not limited to, the following functions: CreateWindowExA, CreateWindowExW, RegisterClassExA, RegisterClassExW, DestroyWindow, CreateMenu, and CreatePopupMenu.

[0058] During the heap management phase, the static engine primarily detects common Windows kernel heap management techniques. Specifically, it mainly detects the allocation and deallocation operations of objects such as Palette, Accelerator Table, and Wnf. For Palette objects, function strings can include CreatePalette; for AcceleratorTable objects, function strings can include CreateAcceleratorTable; for Wnf objects, function strings can include NtCreateWnfStateName, NtUpdateWnfStateData, NtQueryWnfStateData, NtDeleteWnfStateData, etc.

[0059] During the kernel information disclosure phase, the static engine primarily targets common Windows kernel vulnerability information disclosure techniques. Specifically, the static engine performs function string or signature detection on the following detection points: For techniques that disclose information using the NtQuerySystemInformation function, the function string can include NtQuerySystemInformation. For techniques that disclose kernel information using the Win32k Shared Info User Handle Table, the target string can include gSharedInfo and user32. For techniques that disclose kernel information using DescriptorTables, the target string can include __sidt, _sgdt instructions, etc., and the function string can include GetThreadSelectorEntry. For techniques that disclose kernel information using HMValidateHandle, the target string can include IsMenu, HmValidateHandle, user32, etc. For techniques that disclose kernel information using GdiSharedHandleTable, the target string can include NtQueryInformationProcess, ntdll, gdi32, etc., and can also include the offset signature of PebBaseAddress in the PEB structure (this offset is 8 in 64-bit). For example, on the Yara platform, the static engine uses the following signature to match whether the corresponding offset value appears: {c7(40|41|42|43) ? ? 08 00 00 00}. This signature, interpreted in assembly language, means: mov dword ptr[r? x+? ? h],08h, partially covering the assembly instructions generated by the VS compiler when accessing data at offset 0x08. For methods of leaking kernel information using DesktopHeap, the target string can include gdi32, NtCurrentTeb, etc. For methods of leaking kernel information using BigPool, the target string can include function strings such as NtSetInformationThread and NtQuerySystemInformation, and can also include the number 42 00 00 00 corresponding to the SystemBigPoolInformation enumeration, which is hexadecimal 0x42.

[0060] During the construction phase of arbitrary address read / write primitives, the static engine primarily matches the following detection points: For methods that extend memory using the tagWND window for arbitrary address read / write, function strings can include SetWindowLong, SetWindowLongPtr, SetWindowLongPtr, NtUserSetClassLongPtr, and NtUserSetClassLongPtr, etc. For methods that extend memory using the tagCLS window class for arbitrary address read / write, function strings can include SetWindowText, SetWindowText, InternalGetWindowText, NtUserDefSetText, etc. For methods that extend memory using Menu-related APIs for arbitrary address read / write, function strings can include GetMenuItemRect, SetMenuItemInfo, GetMenuBarInfo, etc. For techniques that use modification of Previous Mode in conjunction with NtWriteVirtualMemory to achieve arbitrary address read / write, the target string can include NtReadVirtualMemory, NtWriteVirtualMemory, etc., and can also include the signature of the Previous Mode relative to the EThread offset. For example, on the Yara platform, the static engine will use the following signature to match whether the corresponding offset value appears: {c7(40|41|42|43)? ? 32 02 00 00}. This signature, interpreted in assembly language, means: movdword ptr[r? x+? ? h],232h, partially covering the assembly instructions generated by the VS compiler when accessing the 0x232 offset of a data. For techniques that use WNF to achieve arbitrary address read / write, the function string can include NtUpdateWnfStateData, NtQueryWnfStateData, etc. It should be noted that the detection logic in this part overlaps with the relevant logic of WNF in the heap balancing stage. WNF-related APIs can implement both heap balancing and arbitrary address read / write. For techniques that use Bitmaps to read and write arbitrary addresses, function strings can include GetBitmapBits, SetBitmapBits, CreateCompatibleBitmap, CreateBitmapIndirect, CreateDiscardableBitmap, CreateDIBitmap, etc. For techniques that use Palette objects to read and write arbitrary addresses, function strings can include GetPaletteEntries, SetPaletteEntries, etc.For methods that use NtUserGetAncestor to read arbitrary addresses, the function string can include NtUserGetAncestor, etc. For methods that use Pipe Attribute to read arbitrary addresses, the target string can include kernel32, CreatePipe, NtFsControlFile, etc., and can also include the signature 3C 0011 00.

[0061] During the control flow hijacking phase, the static engine primarily matches the following: For techniques that use RtlSetAllBits for control flow hijacking, the target string can include ntoskrnl, RtlSetAllBits, etc. For techniques that use remote thread injection for control flow hijacking, the function string can include OpenProcess, WriteProcessMemory, CreateRemoteThread, etc.

[0062] During the privilege escalation phase, the static engine primarily targets the following detection points for matching: For the behavior of traversing the EProcess process chain to search for key data structures, the static engine mainly matches the signatures of relevant members relative to the EProcess structure. For example, in the Windows 10 20H2 x64 operating system kernel, the UniqueProcessId variable has an offset of 0x440 relative to EProcess, ActiveProcessLinks has an offset of 0x448, and Token has an offset of 0x4B8; while in the Windows 10 1909 x64 operating system kernel, the UniqueProcessId variable has an offset of 0x2E8 relative to EProcess, ActiveProcessLinks has an offset of 0x2F0, and Token has an offset of 0x360. The static engine performs signature matching on each operating system's uniqueProcessId, ActiveProcessLinks, and Token offset combination. For example, it matches the signatures 40 04 00 00, 48 04 00 00, and B804 00 00 simultaneously.

[0063] S103: Calculate the risk score of the target executable file based on the number of features detected in each of the aforementioned stages;

[0064] In practice, the risk score of the target executable file is calculated based on the number of target strings matched by the static rules corresponding to each stage.

[0065] In a preferred embodiment, this step may include: determining the weighting coefficients corresponding to each stage, and performing a weighted calculation on the number of features detected in each stage based on the weighting coefficients corresponding to each stage to obtain the risk score of the target executable file. In a specific implementation, the number of features detected for vulnerability triggering, heap feng shui, kernel information leakage, arbitrary address read / write primitive construction, control flow hijacking, and privilege escalation are a, b, c, d, e, and f, respectively, and the corresponding weighting coefficients are P1, P2, P3, P4, P5, and P6, respectively. The risk score of the target executable file is a×P1+b×P2+c×P3+d×P4+e×P5+f×P6.

[0066] S104: Determine the vulnerability detection result of the target executable file based on the risk score.

[0067] In specific implementation, if the risk score is less than or equal to a first preset value, the vulnerability level of the target executable file is determined to be low; if the risk score is greater than the first preset value and less than or equal to a second preset value, the vulnerability level of the target executable file is determined to be medium; wherein, the second preset value is greater than the first preset value, and if the risk score is greater than the second preset value, the vulnerability level of the target executable file is determined to be high.

[0068] For example, if the risk score is 0, the vulnerability level of the target executable file is determined to be white (low level), meaning the file does not contain Windows kernel exploits. If the risk score is greater than 0 and less than or equal to S, the vulnerability level of the target executable file is determined to be gray (medium level), meaning the file is suspected of containing Windows kernel exploits. If the risk score is greater than S, the vulnerability level of the target executable file is determined to be black (high level), meaning the sample definitely contains Windows kernel exploits.

[0069] The vulnerability detection method provided in this application performs feature detection at each stage of the vulnerability exploitation process, counts the number of features detected at each stage, calculates the risk score of the target executable file based on this score, and determines the vulnerability detection result based on the risk score. The target executable file does not need to be actually executed or matched to an execution environment, thus achieving static vulnerability detection. This method is simple to implement, consumes few resources, and has good detection results. Therefore, the vulnerability detection method provided in this application improves the effectiveness of vulnerability detection.

[0070] The following describes a vulnerability detection device provided in an embodiment of this application. The vulnerability detection device described below and the vulnerability detection method described above can be referred to each other.

[0071] See Figure 2A structural diagram of a vulnerability detection device is shown according to an exemplary embodiment, such as... Figure 2 As shown, it includes:

[0072] The acquisition module 201 is used to acquire the target executable file to be detected and determine the various stages of the vulnerability exploitation process of the target executable file;

[0073] The detection module 202 is used to perform feature detection on each stage of the target executable file and count the number of features detected in each stage.

[0074] Calculation module 203 is used to calculate the risk score of the target executable file based on the number of features detected in each stage;

[0075] The determination module 204 is used to determine the vulnerability detection result of the target executable file based on the risk score.

[0076] The vulnerability detection device provided in this application performs feature detection at each stage of the vulnerability exploitation process, counts the number of features detected at each stage, calculates the risk score of the target executable file based on this score, and determines the vulnerability detection result based on the risk score. The target executable file does not need to be actually executed or matched to an execution environment, thus achieving static vulnerability detection. This method is simple to implement, consumes few resources, and provides good detection results. Therefore, the vulnerability detection device provided in this application improves the vulnerability detection effect.

[0077] Based on the above embodiments, as a preferred implementation, the stages include any one or a combination of any of the following: vulnerability triggering stage, heap feng shui stage, kernel information leakage stage, arbitrary address read / write primitive construction stage, control flow hijacking stage, and privilege escalation stage.

[0078] Based on the above embodiments, as a preferred implementation, the detection module 202 is specifically used to: determine the static rules corresponding to each stage, and perform feature detection on each stage of the target executable file based on the static rules corresponding to each stage, and count the number of features detected in each stage.

[0079] Based on the above embodiments, as a preferred embodiment, the detection module 202 is specifically used to: match the target string of the target executable file based on the static rules corresponding to each stage; and count the number of target strings matched by the static rules corresponding to each stage.

[0080] Accordingly, the calculation module 203 is specifically used to: calculate the risk score of the target executable file based on the number of target strings matched by the static rules corresponding to each stage.

[0081] Based on the above embodiments, as a preferred implementation, the target string includes a function string and / or a feature code.

[0082] Based on the above embodiments, as a preferred implementation, the calculation module 203 is specifically used to: determine the weighting coefficients corresponding to each stage, and perform weighted calculation on the number of features detected in each stage based on the weighting coefficients corresponding to each stage, to obtain the risk score of the target executable file.

[0083] Based on the above embodiments, as a preferred implementation, the determining module 204 is specifically used to: if the risk score is less than or equal to a first preset value, determine that the vulnerability level of the target executable file is low; if the risk score is greater than the first preset value and less than or equal to a second preset value, determine that the vulnerability level of the target executable file is medium; wherein, the second preset value is greater than the first preset value; if the risk score is greater than the second preset value, determine that the vulnerability level of the target executable file is high.

[0084] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0085] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 3 This is a structural diagram of an electronic device according to an exemplary embodiment, such as... Figure 3 As shown, the electronic device includes:

[0086] Communication interface 1 enables information exchange with other devices, such as network devices;

[0087] Processor 2 is connected to communication interface 1 to enable information exchange with other devices and, when running a computer program, executes the vulnerability detection methods provided by one or more of the above-mentioned technical solutions. The computer program is stored in memory 3.

[0088] Of course, in practical applications, the various components in an electronic device are coupled together through bus system 4. It can be understood that bus system 4 is used to achieve communication and connection between these components. In addition to the data bus, bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 3The general will label all buses as Bus System 4.

[0089] The memory 3 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0090] It is understood that memory 3 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 3 described in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0091] The methods disclosed in the embodiments of this application can be applied to processor 2, or implemented by processor 2. Processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 2 or by instructions in the form of software. The processor 2 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 2 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 3. Processor 2 reads the program in memory 3 and completes the steps of the aforementioned method in combination with its hardware.

[0092] When processor 2 executes the program, it implements the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0093] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 3 that stores a computer program, which can be executed by a processor 2 to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0094] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0095] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0096] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vulnerability detection method characterized by, The method comprises the following steps: obtaining a target executable file to be detected, and determining various stages of the target executable file in a vulnerability exploitation process; performing feature detection on each of the various stages of the target executable file, and counting the number of features detected in each of the various stages; calculating a risk score of the target executable file according to the number of features detected in each of the various stages; determining a vulnerability detection result of the target executable file based on the risk score; wherein the feature detection on each of the various stages of the target executable file and the counting of the number of features detected in each of the various stages comprise: determining a static rule corresponding to each of the various stages, and performing feature detection on each of the various stages of the target executable file based on the static rule corresponding to each of the various stages, and counting the number of features detected in each of the various stages.

2. The method of claim 1, wherein, The various stages include any one or a combination of the following: a vulnerability triggering stage, a heap Fengshui stage, a kernel information leakage stage, an arbitrary address read-write primitive construction stage, a control flow hijacking stage, and a privilege escalation stage.

3. The method of claim 1, wherein, The static rule at least includes a target string, and the feature detection on each of the various stages of the target executable file based on the static rule corresponding to each of the various stages and the counting of the number of features detected in each of the various stages comprise: matching the target string in the target executable file based on the static rule corresponding to each of the various stages; counting the number of target strings matched by the static rule corresponding to each of the various stages; correspondingly, the calculation of the risk score of the target executable file according to the number of features detected in each of the various stages comprises: calculating the risk score of the target executable file according to the number of target strings matched by the static rule corresponding to each of the various stages.

4. The method of claim 3, wherein, The target string includes a function string and / or a feature code.

5. The method of claim 1, wherein, The calculation of the risk score of the target executable file according to the number of features detected in each of the various stages comprises: determining a weighting coefficient corresponding to each of the various stages, and performing weighted calculation on the number of features detected in each of the various stages based on the weighting coefficient corresponding to each of the various stages to obtain the risk score of the target executable file.

6. The method of claim 1, wherein, The determination of the vulnerability detection result of the target executable file based on the risk score comprises: if the risk score is less than or equal to a first preset value, determining that the vulnerability level of the target executable file is a low level; if the risk score is greater than the first preset value and less than or equal to a second preset value, determining that the vulnerability level of the target executable file is a medium level; wherein the second preset value is greater than the first preset value; if the risk score is greater than the second preset value, determining that the vulnerability level of the target executable file is a high level.

7. A vulnerability detection apparatus characterized by comprising: The method comprises the following steps: an obtaining module, configured to obtain a target executable file to be detected, and determine various stages of the target executable file in a vulnerability exploitation process; a detection module, configured to perform feature detection on each of the various stages of the target executable file, and count the number of features detected in each of the various stages; a calculating module, configured to calculate a risk score of the target executable file according to the number of features detected in each of the stages; a determining module, configured to determine a vulnerability detection result of the target executable file based on the risk score; wherein the detecting module is specifically configured to determine a static rule corresponding to each of the stages, and perform feature detection on each of the stages of the target executable file based on the static rule corresponding to each of the stages, and count the number of features detected in each of the stages.

8. An electronic device, comprising: comprise: a memory, configured to store a computer program; a processor, configured to implement the steps of the vulnerability detection method according to any one of claims 1 to 6 when the computer program is executed.

9. A computer-readable storage medium, characterized in that, The computer program is stored on the computer readable storage medium and is executed by the processor to implement the steps of the vulnerability detection method according to any one of claims 1 to 6.

Images