Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis

Abstract

The invention provides a Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis, and belongs to the technical field of computer security. According to the method, the kernel object of the to-be-analyzed driver is directly obtained through the kernel debugging engine, the dispatch function address of the driver is analyzed from the kernel object, the workload of a symbolic execution engine is greatly reduced, the analysis time is greatly shortened, and meanwhile it can be ensured that the dispatch function address of the driver is accurately obtained; a static analysis technology is utilized, all sensitive APIs and privileged instructions in a drive are found before symbolic execution, all possible paths starting from a dispatch function to the sensitive APIs or the privileged instructions are analyzed, the state is updated strictly according to the paths in the subsequent symbolic execution process, the symbolic execution range is greatly reduced, and the analysis time is greatly shortened; various sensitive APIs and privileged instructions are comprehensively considered, and the coverage of vulnerability mining is improved; the method has the characteristics of light weight and high automation, and is suitable for large-scale batch automatic analysis.

Description

Technical Field

[0001] The present invention relates to the field of computer security technology, and in particular to a method for mining Windows driver vulnerabilities based on symbolic execution and dynamic and static analysis. Background Art

[0002] In the Windows system, drivers operate at the Ring 0 layer and have full control over devices. Therefore, any vulnerabilities in the drivers may lead to serious system security problems. Since Windows Vista, Windows has introduced the Driver Signature Enforcement (DSE) policy, which requires drivers to be digitally signed before they can be loaded. Microsoft will conduct quality certification tests on driver programs, and only drivers that pass the tests can obtain the signature of the Windows Hardware Quality Labs. However, passing the quality test and obtaining the signature does not guarantee that the driver is absolutely secure. Currently, the vast majority of Windows drivers are developed by third-party manufacturers, and these manufacturers often do not strictly follow the driver program security guidelines proposed by Microsoft during the development process. Therefore, these drivers are very likely to have security vulnerabilities. Different types of vulnerabilities may lead to a series of consequences of different severities, including data corruption, system crashes, privilege escalation, and even full control of the device. In recent years, an attack method called BYOVD (Bring Your Own Vulnerable Driver) has emerged to address the above problems. Attackers load vulnerable drivers that have passed legal signature authentication into the target system and complete various attack operations at the Ring 0 layer by exploiting the vulnerabilities in the drivers, such as stealing sensitive data and blinding EDR. Currently, many malware use the BYOVD technology, posing a serious threat to the security of the Windows system. In addition to malware, many game cheating software also uses BYOVD to bypass the game's anti-cheat system, presenting a huge challenge to game security manufacturers.

[0003] Microsoft provides developers with the Static Driver Verifier and the Driver Verifier. The Static Driver Verifier is a vulnerability mining tool at the source code level. Since the vast majority of Windows drivers are closed-source, such tools are mainly applicable to developers for security self-checks when they have the source code. The Driver Verifier mines driver vulnerabilities through stress testing. This method requires a complete operating system environment and consumes a large amount of computing resources during operation. It is prone to system environment damage and requires reconfiguring the system, so it is difficult to achieve rapid analysis, large-scale analysis, and high automation. Dominik Maier open-sourced a driver vulnerability mining tool BSOD (https: / / github.com / 0xf4b1 / bsod-kernel-fuzzing) based on virtualization and fuzzing technology in the paper. However, such tools need to manually configure the system environment before use and need to be adapted to each driver to be tested, which requires a lot of manpower and has high requirements for computing resources during the mining process, and is not suitable for large-scale automated vulnerability mining. Rajat Gupta proposed a driver vulnerability mining tool based on symbolic execution. Such tools are prone to the problem of path explosion during the analysis process. In actual scenarios, this tool is only applicable to analyzing some small drivers, does not have wide generality, and this type of tool only supports mining WDM (Windows Driver Model) drivers and does not support mining the latest KMDF (Kernel Mode Driver Framework) drivers, resulting in poor generality of the tool and restricting the application scenarios and effects of the tool. Summary of the Invention

[0004] To solve the problems existing in the prior art, the present invention proposes a method for mining Windows driver vulnerabilities based on symbolic execution and dynamic and static analysis. This method is a lightweight, efficient, and highly versatile automated driver vulnerability mining tool at the binary level. It uses kernel debugging technology and static analysis technology to obtain driver dispatch functions and function call paths that may cause vulnerabilities respectively, and finally determines the function call path that will actually cause vulnerabilities through symbolic execution; fully combines the advantages of kernel dynamic analysis technology, static analysis technology, and symbolic execution technology, and solves the problems of large resource consumption, low efficiency, low automation, and poor generality of existing driver vulnerability mining tools.

[0005] The technical solution of the present invention is as follows:

[0006] A method for Windows driver vulnerability mining based on symbolic execution and dynamic and static analysis, which dynamically obtains the offset address of the driver dispatch function through kernel debugging technology; then uses a static analysis tool to analyze the driver file, obtains the sensitive APIs called in the driver and the privileged instructions executed, and checks whether there is a path from the dispatch function to the sensitive APIs or privileged instructions; finally, uses a symbolic execution engine to analyze whether these paths will lead to vulnerabilities.

[0007] The above-mentioned method for Windows driver vulnerability mining based on symbolic execution and dynamic and static analysis specifically includes the following steps:

[0008] (1) Obtain the driver file to be analyzed and load it into the virtual machine;

[0009] (2) Use the kernel debugger Windbg to dynamically obtain the offset address of the dispatch function of the driver to be analyzed from the virtual machine kernel;

[0010] Open the kernel debugging switch of the virtual machine and configure the network kernel debugging channel. Use Windbg to enumerate all driver kernel objects in the virtual machine system, find the driver kernel object corresponding to the driver to be analyzed in the enumeration result, and use the object parsing function of Windbg to obtain the dispatch function and its offset address of the driver to be analyzed;

[0011] (3) Use the static analysis tool IDAPro to calculate the function call path from the dispatch function to the sensitive APIs or privileged instructions;

[0012] (3a) Use the static analysis tool IDAPro to parse the import table of the driver, check whether there are sensitive APIs in the import table, and record the address addr1 of the sensitive APIs;

[0013] (3b) Use IDAPro to parse the code segment of the driver, check whether there are sensitive privileged instructions in the code segment, and record the address addr2 of the sensitive privileged instructions;

[0014] (3c) Starting from the driver dispatch function obtained in step (2), use IDAPro to solve the function call path from the dispatch function to the address addr1 and the address addr2;

[0015] (4) Use the symbolic execution engine angr to execute along the function call path calculated in step (3) to determine whether the path will lead to vulnerabilities;

[0016] (4a) First, register some commonly used Windows kernel data structures of the driver in angr;

[0017] (4b) Modify the default state update strategy of angr to sequentially specify the target address of the next state along the path calculated in step (3).

[0018] (4c) Set the dispatch function of the driver as the starting point of angr execution, create symbolic function parameters DeviceObject and Irp, where Irp represents any input from the user-mode program. When angr executes to the end of the path, call the corresponding detection logic to determine whether this path leads to a vulnerability. If the end of the path corresponds to a sensitive API, check whether the parameters of the sensitive API can be controlled by the symbolic Irp of the user-mode program through angr.SimState.symbolic. If it corresponds to a privileged instruction, use the same method to check whether the source and destination operands of the privileged instruction can be controlled by the symbolic Irp of the user-mode program. If so, this path will cause a vulnerability, and report the discovery of the vulnerability.

[0019] Furthermore, for the above Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis, in step (2), the object parsing function of Windbg is used to obtain the dispatch function of the driver to be analyzed. Specifically, use the dt command to parse the driver kernel object DRIVER_OBJECT. There is a member named MajorFunction in the driver kernel object, which is an array of function pointers. The element corresponding to subscript 14 is the dispatch function of the driver.

[0020] Furthermore, for the above Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis, the sensitive APIs include:

[0021] MmMapIoSpace, ZwMapViweOfSection, ZwOpenProcess, ObOpenObjectByPointer, ZwCreateFile, KeStackAttachProcess, memcpy.

[0022] Furthermore, for the above Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis, the sensitive privileged instructions include: wrmsr, rdmsr, in, out.

[0023] Furthermore, for the above Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis, the operation in step (3) is implemented with the aid of IDA Python. IDA Python exports a large number of core function interfaces of IDA Pro. Among them, the idaapi.get_imagebase method is used to obtain the base address of the PE file; the ida_nalt.get_import_module_qty method is used to obtain the import table of the PE file and search for sensitive APIs; the idc.find_binary method is used to search for a specified binary sequence in the PE file and search for privileged instructions in the PE file in combination with the machine code of privileged instructions; the idautils.CodeRefsTo method is used to obtain the cross-reference list of a certain function, and this method is recursively called to construct the function call path from the dispatch function to the sensitive API or privileged instruction.

[0024] Furthermore, for the above Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis, the commonly used Windows kernel data structures registered in angr in step (4) include:

[0025] UNICODE_STRING, GUID, LIST_ENTRY, KIRQL, _IRP, _DEVICE_OBJECT, _DRIVER_OBJECT, _IO_STACK_LOCATION, _KAPC.

[0026] The technical effects of the present invention are as follows:

[0027] First, the prior art uses a symbolic execution engine to execute the complete driver initialization process to obtain the dispatch function of the driver. However, Windows driver programs are often very complex and tightly coupled with the operating system kernel, making it difficult for symbolic execution to successfully execute the driver initialization process. This method not only takes a long time and consumes a lot of resources but also cannot ensure accurately solving the dispatch function address. The present invention integrates the Windows kernel debugging interface, directly obtains the kernel object of the driver to be analyzed through the kernel debugging engine, and parses the dispatch function address of the driver from it, greatly reducing the workload of the symbolic execution engine, greatly shortening the analysis time, and at the same time being able to ensure accurately obtaining the driver dispatch function address;

[0028] Second, when the prior art discovers vulnerabilities, it generally starts from the dispatch function and uses the symbolic execution engine to update the state according to the breadth-first search or depth-first search strategy. There is a great deal of blindness in the discovery process, and it is impossible to conduct targeted exploration for sensitive APIs and privileged instructions. The present invention applies static analysis technology to find all sensitive APIs and privileged instructions in the driver before symbolic execution, analyzes all possible paths from the dispatch function to the sensitive APIs or privileged instructions, and strictly updates the state according to the above paths during the subsequent symbolic execution process, greatly reducing the scope of symbolic execution and significantly shortening the analysis time;

[0029] Third, when the prior art discovers vulnerabilities, it can only conduct vulnerability discovery for a few sensitive APIs or privileged instructions. The present invention comprehensively considers various sensitive APIs and privileged instructions, improving the coverage of vulnerability discovery;

[0030] Fourth, the present invention only uses a virtual machine and a static analysis engine in steps (2) and (3), and the analysis itself is completely carried out using the symbolic execution engine. This ensures the lightweight and highly automated nature of the tool, making it suitable for large-scale batch automated analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 is a flowchart of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0032] The present invention will be further clearly and completely described below with reference to the accompanying drawings and specific embodiments.

[0033] Figure 1 is a flowchart of the present invention; the following will be specifically described with reference to the flowchart.

[0034] Step 1: Obtain the driver file to be analyzed and load it into the virtual machine;

[0035] Use web crawler technology to obtain a large number of drivers on the Internet, extract the driver files (.sys files), and then create a virtual machine and load the drivers into the virtual machine. Among them, a web crawler is written using the Python request library for the driver download web pages of each manufacturer. After the crawling is completed, the.sys files are extracted from the installation packages and loaded into the virtual machine; the virtual machine is created using VMware Workstation, and the operating system is Windows 10 Professional Edition.

[0036] Step 2: Dynamically obtain the offset address of the dispatch function of the driver to be analyzed from the virtual machine kernel using the kernel debugger Windbg;

[0037] Configure the virtual machine and the host computer to be in the same subnet, turn on the kernel debugging switch of the virtual machine and configure the network kernel debugging channel, and enter the following command in the CMD of the virtual machine:

[0038] bcdedit / debug on

[0039] bcdedit / dbgsettings net hostip:10.XX.72.XXX port:50001 key:1.2.3.4

[0040] After restarting the virtual machine, you can use Windbg to debug the virtual machine kernel. After loading the driver, enter the command in Windbg:

[0041] !object\driver

[0042] You can enumerate all driver kernel objects in the virtual machine. Find the driver kernel object corresponding to the driver to be analyzed in the enumeration result. Then use the dt command to parse the driver kernel object (DRIVER_OBJECT). There is a member named MajorFunction in the driver kernel object. This member is an array of function pointers. The element corresponding to subscript 14 is the dispatch function of the driver; read the offset address of the driver dispatch function as the input for step three. When performing large-scale batch analysis, you can write a script to batch load the driver, and at the same time use the python library pybag to call the Windbg debugging engine to automatically execute Windbg debugging commands and obtain the debugger output.

[0043] Step three, use the static analysis tool IDAPro to calculate the function call path from the dispatch function to sensitive APIs or privileged instructions;

[0044] (3a) Use the static analysis tool IDAPro to parse the import table in the driver program's PE file, check whether there are sensitive APIs in the import table, and record the address addr1 of the sensitive API. The sensitive APIs include:

[0045] MmMapIoSpace, ZwMapViweOfSection, ZwOpenProcess, ObOpenObjectByPointer, ZwCreateFile, KeStackAttachProcess, memcpy;

[0046] (3b) Use IDAPro to parse the code segment in the driver program's PE file, check whether there are sensitive privileged instructions in the code segment, and record the address addr2 of the sensitive privileged instruction; The privileged instructions include:

[0047] wrmsr, rdmsr, in, out.

[0048] (3c) Starting from the driver dispatch function obtained in step (2), search in the driver PE file to see if there is a function call path from the driver dispatch function to sensitive APIs or privileged instructions, and use the found path as the input for step four.

[0049] The operations in step three are implemented using IDAPython. IDAPython exports a large number of core function interfaces of IDAPro. Among them, the idaapi.get_imagebase method is used to obtain the base address of the PE file; the ida_nalt.get_import_module_qty method is used to obtain the import table of the PE file and search for sensitive APIs; the idc.find_binary method is used to search for a specified binary sequence in the PE file. Combining with the machine code of privileged instructions, privileged instructions can be searched in the PE file; the idautils.CodeRefsTo method is used to obtain the cross-reference list of a certain function. Recursively calling this method can build a function call path from the dispatch function to sensitive APIs or privileged instructions. When performing large-scale batch analysis, scripts can be written to automate the above operations.

[0050] Step four: Use the symbolic execution engine angr to verify whether the function call path found in step three will really lead to vulnerabilities;

[0051] Before using angr to explore, some commonly used Windows kernel data structures in the driver need to be registered in angr, mainly including UNICODE_STRING, GUID, LIST_ENTRY, KIRQL, _IRP, _DEVICE_OBJECT, _DRIVER_OBJECT, _IO_STACK_LOCATION, _KAPC, etc.; in order to make angr strictly follow the path update strategy found in step three, the default state update strategy of angr needs to be modified. In the angr.explore method, specify the target address of the next state in sequence according to the path order to avoid the state update getting out of control. After the above work is completed properly, call the angr.call_state method to set the execution starting point to the driver dispatch function. The prototype of this function is as follows:

[0052] NTSTATUS DriverDispatch(

[0053] [in, out]_DEVICE_OBJECT* DeviceObject,

[0054] [in, out]_IRP* Irp

[0055] ){...}

[0056] Subsequently, claripy.BVS is called to create symbolic function parameters DeviceObject and Irp, where Irp represents any input from the user-mode program.

[0057] When angr reaches the end of a path, the corresponding detection logic is called to determine whether that path actually leads to a vulnerability. If the end of the path corresponds to a sensitive API, angr.SimState.symbolic is used to check whether the parameters of the sensitive API can be controlled by the symbolic Irp. If it corresponds to a privileged instruction, the same method is used to check whether the source and destination operands of the privileged instruction can be controlled by the symbolic Irp. If so, it means that this path will indeed cause a vulnerability, and at this time, a vulnerability discovery can be reported.

[0058] The following shows the vulnerability results obtained by the present invention and further describes the effects of the present invention. Currently, after performing vulnerability mining on 928 different drivers crawled from the Internet, the present invention has discovered 10 high-risk vulnerabilities, 2 critical vulnerabilities. In addition, a vulnerability in a Dell product has been discovered and a bounty of $3,000 has been obtained. The specific vulnerability results are shown in Table 1:

[0059] Table 1

[0060]

[0061]

[0062] The Dell vulnerability was submitted through BugCrowd, and the specific information is shown in Table 2.

[0063] Table 2

[0064] Vendor Level Reward Points Dell P2 $3000 20

[0065] The vulnerabilities discovered using the present invention are all at a level above high-risk. Exploiting the above vulnerabilities will lead to local privilege escalation and even arbitrary kernel code execution, verifying the effectiveness and practicality of the present invention.

[0066] Finally, it should be noted that the purpose of publishing the embodiments is to help further understand the present invention. However, those skilled in the art can understand that various substitutions and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the content disclosed in the embodiments, and the scope of protection claimed by the present invention is defined by the scope of the claims.

Claims

1. A Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis, characterized in that: The offset address of the driver dispatch function is dynamically obtained through kernel debugging technology; then the driver file is analyzed using static analysis tools to obtain the sensitive APIs called and privileged instructions executed in the driver, and check whether there is a path from the dispatch function to the sensitive API or privileged instructions; finally, the symbolic execution engine is used to analyze whether these paths will lead to vulnerabilities.

2. The Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis as claimed in claim 1, characterized in that: The specific steps include: (1) Obtain the driver file to be analyzed and load it into the virtual machine; (2) Using the kernel debugger Windbg to dynamically obtain the dispatch function offset address of the driver to be analyzed from the virtual machine kernel; Turn on the kernel debugging switch of the virtual machine and configure the network kernel debugging channel. Use Windbg to enumerate all driver kernel objects in the virtual machine system. Find the driver kernel object corresponding to the driver to be analyzed in the enumeration results. Use the object parsing function of Windbg to obtain the dispatch function and its offset address of the driver to be analyzed. (3) Use the static analysis tool IDAPro to calculate the function call path from the dispatch function to the sensitive API or privileged instruction; (3a) Use the static analysis tool IDAPro to parse the driver's import table, check whether there is a sensitive API in the import table, and record the address addr1 of the sensitive API; (3b) Use IDAPro to parse the driver code segment, check whether there are sensitive privileged instructions in the code segment, and record the address addr2 of the sensitive privileged instruction; (3c) Starting from the driver dispatch function obtained in step (2), use IDAPro to solve the function call path from the dispatch function to address addr1 and address addr2; (4) Use the symbolic execution engine angr to execute along the function call path calculated in step (3) to determine whether the path will lead to a vulnerability; (4a) First, register some Windows kernel data structures commonly used by drivers in angr; (4b) Modify angr's default state update strategy so that it specifies the target address of the next state in sequence along the path calculated in step (3); (4c) Set the driver's dispatch function as the execution start point of angr, create symbolic function parameters DeviceObject and Irp, where Irp represents any input from the user-mode program. When angr executes to the end of the path, call the corresponding detection logic to determine whether the path causes a vulnerability. If the end of the path corresponds to a sensitive API, use angr.SimState.symbolic to check whether the parameters of the sensitive API can be controlled by any input Irp of the symbolic user-mode program. If it corresponds to a privileged instruction, use the same method to check whether the source operand and destination operand of the privileged instruction can be controlled by any input Irp of the symbolic user-mode program. If so, the path will cause a vulnerability and report the discovery of the vulnerability.

3. The Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis as claimed in claim 2, characterized in that: In the step (2), the object parsing function of Windbg is used to obtain the dispatch function of the driver to be analyzed. Specifically, the dt command is used to parse the driver kernel object DRIVER_OBJECT. The driver kernel object has a member named MajorFunction, which is a function pointer array, in which the element corresponding to subscript 14 is the dispatch function of the driver.

4. The Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis as claimed in claim 2, characterized in that: The sensitive APIs include: MmMapIoSpace, ZwMapViweOfSection, ZwOpenProcess, ObOpenObjectByPointer, ZwCreateFile, KeStackAttachProcess, memcpy.

5. The Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis as claimed in claim 2, characterized in that: The sensitive privileged instructions include: wrmsr, rdmsr, in, out.

6. The Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis as claimed in claim 2, characterized in that: The operation of step (3) is implemented with the help of IDAPython. IDAPython exports a large number of core functional interfaces of IDAPro, among which the idaapi.get_imagebase method is used to obtain the base address of the PE file; the ida_nalt.get_import_module_qty method is used to obtain the import table of the PE file and find the sensitive API; the idc.find_binary method is used to search for the binary sequence specified in the PE file, and search for the privileged instruction in the PE file with the machine code of the privileged instruction; the idautils.CodeRefsTo method is used to obtain the cross-reference list of a function, and the method is recursively called to construct the function call path from the dispatch function to the sensitive API or privileged instruction.

7. The Windows driver vulnerability mining method based on symbolic execution and dynamic and static analysis as claimed in claim 2, characterized in that: The Windows kernel data structures commonly used by the driver registered in angr in step (4) include: UNICODE_STRING, GUID, LIST_ENTRY, KIRQL, _IRP, _DEVICE_OBJECT, _DRIVER_OBJECT, _IO_STACK_LOCATION, _KAPC.

Images