Static Analysis Automation for Hunting Vulnerable Kernel Drivers

https://blogs.vmware.com/security/2023/10/hunting-vulnerable-kernel-drivers.html
https://github.com/TakahiroHaruyama/VDR

Microsoft Windows allows loading kernel drivers with signatures whose certificates are expired or revoked. This policy facilitates threat actors to defeat AV/EDR sensors or install bootkits using known vulnerable drivers. Since the Windows 11 2022 update, the vulnerable drivers are blocked by default using HVCI. However, this banned-list approach is only effective if the vulnerable driver is known in advance.

Previous research utilized symbolic execution for automating the discovery of vulnerable drivers. Symbolic execution sometimes fails by causing path explosions or false negatives. Additionally, previous research focused primarily on WDM drivers. WDF drivers, whose code and data structures are different by versions and compiler settings, have been unexplored sufficiently.

In this presentation, I will explain how to identify vulnerable WDM/WDF drivers that contain firmware access (physical memory read/write). Detecting the drivers is almost the only way for OS-level security software to catch bootkit installation behavior that modifies SPI flash memory. Moreover, the drivers handling such low-level I/O often contain other vulnerabilities like kernel virtual memory access.

I automated the hunting process using an IDAPython script with two functions based on the Hex-Rays Decompiler SDK: triage and analysis. The triage function identifies IOCTL handlers then finds execution paths to the target APIs/instructions. The analysis function fixes union fields in IOCTL-related structures and sets argument names/types of the WDF APIs. Then it propagates function argument names/types in subroutines recursively to quickly decide if the I/O can be controlled.

As a result of the research, I found 34 unique vulnerable drivers accepting firmware access. Six allow kernel memory access. As of the time of writing in October 2023, the filenames of the vulnerable drivers have not been made public. All give full control of the devices to non-admin users. I will demonstrate firmware erasing and elevation of OS privilege by exploiting the drivers.

Transcript

1. STATIC ANALYSIS AUTOMATION FOR HUNTING VULNERABLE KERNEL DRIVERS Takahiro Haruyama VMware Carbon Black Threat Analysis Unit
2. OVERVIEW • Background • Previous Research • My Approach • Implementation • Hunting Vulnerable Drivers • Result • Exploit Development • Wrap-up 2/22/2024 Vulnerable Driver Demo 3
3. BACKGROUND
4. BACKGROUND • Vulnerable drivers are abused by threat actors • EoP by non-privileged attackers • BYOVD techniques by privileged attackers • e.g., defeat AV/EDR sensors or install bootkits • HVCI-enabled Windows 11 blocks some known vulnerable drivers • Loldrivers.io covers more vulnerable drivers • How many unknown vulnerable drivers? 2/22/2024 Vulnerable Driver Demo 5
5. PREVIOUS RESEARCH • Symbolic execution for automating the discovery of vulnerable drivers • ScrewedDrivers, POPKORN, etc. • It sometimes fails by path explosions, false negatives and other unknown errors • We need to validate the result before reporting • The output buffer contains the result value in read primitives? • The constraint of the input buffer is sometimes too chaotic • Previous research focused primarily on WDM drivers • It’s unlikely to work for WDF drivers due to the complexity 2/22/2024 Vulnerable Driver Demo 6
6. MY APPROACH • I automated the hunting process of the vulnerable WDM/WDF drivers using an IDAPython script • Based on Hex-Rays Decompiler SDK • I focused on drivers that contain firmware access (physical memory read/write) • Detecting the drivers is effective to catch bootkit installation modifying firmware • Firmware is resident in the SPI flash memory on a motherboard • Kernel drivers can read/write the firmware through port I/O and memory-mapped I/O • But it’s difficult to utilize these I/O activities for the detection • Once bootkit is installed, it can also defeat firmware scanners 2/22/2024 Vulnerable Driver Demo 7
7. MY APPROACH (CONT.) • The drivers handling such low-level I/O often contain other vulnerabilities • Virtual memory access in kernel space (aka data-only attack) • EoP or defeating AV/EDR • Model-specific register (MSR) access • Patching system call entry addresses or disabling KASLR if the process integrity level is low • Control register (CR) access • Disabling SMEP/SMAP • Registry access, KeBugCheckEx, etc. 2/22/2024 Vulnerable Driver Demo 8
8. IMPLEMENTATION
9. IMPLEMENTATION SUMMARY • Two functions: triage and analysis • The triage function robustly detects potentially vulnerable drivers from large sets of samples 2/22/2024 Vulnerable Driver Demo 10
10. IMPLEMENTATION SUMMARY • Two functions: triage and analysis • The analysis function substantially assists the tedious manual validation 2/22/2024 Vulnerable Driver Demo 11
11. TRIAGE • Identify IOCTL handlers then finds execution paths to the target APIs/instructions • The IOCTL handler identification method depends on the driver type • WDM: Detect an assignment to the MajorFunction array member of the DRIVER_OBJECT structure then apply the function type • WDF: Requre a multiple-step procedure 2/22/2024 Vulnerable Driver Demo 12 user space kernel space APIs DeviceIoControl MmMapIoSpace/MmMapIoSpaceEx (memory mapped I/O) Instructions - IN/OUT (port I/O)
12. WDF IOCTL HANDLER IDENTIFICATION 1. Detect a call instruction of WdfVersionBind API • Import a header file with WDF type information • I utilize the 3rd-party definition (kmdf_re) • WDF APIs are basically called through WDFFUNCTIONS • Pointed by the structure member of the third API argument (WDF_BIND_INFO.FuncTable) 2. Track the cross-references to WdfIoQueueCreate API in the function table • Find a function address to be assigned to the structure member of the second API argument • WDF_IO_QUEUE_CONFIG.EvtIoDeviceControl 2/22/2024 Vulnerable Driver Demo 13
13. THE DEVIL IS IN THE DETAILS (WDFFUNCTIONS) 2/22/2024 Vulnerable Driver Demo 14 PWDFFUNCTIONS = Version 1.15.0 and later _WDFFUNCTIONS = Version 1.13.0 and below
14. THE DEVIL IS IN THE DETAILS (API CALL VARIATION) 2/22/2024 Vulnerable Driver Demo 15 Direct call Calculating the offset from the table
15. THE DEVIL IS IN THE DETAILS (API WRAPPER) • Debug-built or old WDF drivers create function wrappers when calling WDF APIs 2/22/2024 Vulnerable Driver Demo 16
16. ANALYSIS • Fix/Set variable names/types • WDM: Fix union fields in IOCTL-related structures • IO_STACK_LOCATION.Parameters and IRP.AssociatedIrp • WDF: Set argument names/types of APIs handling user data I/O • Propagate function argument names/types in subroutines recursively to quickly decide if the I/O can be controlled 2/22/2024 Vulnerable Driver Demo 17
17. WDF APIS HANDLING USER DATA I/O • WdfRequestRetrieveInputBuffer • WdfRequestRetrieveOutputBuffer • WdfRequestRetrieveInputWdmMdl • WdfRequestRetrieveOutputWdmMdl • WdfRequestRetrieveInputMemory • WdfRequestRetrieveOutputMemory • WdfRequestGetParameters 2/22/2024 Vulnerable Driver Demo 18
18. DEMO • WDM analysis • WDF analysis 2/22/2024 Vulnerable Driver Demo 19
19. LIMITATION • Renaming local variables uncommonly fails • The function argument's item type is cot_call when traversing the ctree • Renaming information looks to be lost as the local variable name is changed • Renaming fails multiple times even if a new name is unique in the function • Etc.. • Any issue is likely caused by internal changes of the decompiler ctrees in IDA 2/22/2024 Vulnerable Driver Demo 20
20. HUNTING VULNERABLE DRIVERS
21. COLLECTION AND TRIAGE • Collected about 18K x64 Windows driver samples by VirusTotal retrohunts using a simple YARA rule • De-duplicated the samples based on imphash then executed the IDAPython script • Potentially-vulnerable 300 WDM and 50 WDF • Excluded drivers with the following conditions • Already-known ones • CVE List, MS driver block rules, loldrivers.io, popkorn-artifact etc. • Ones whose signature caused verification errors • Old versions of the same ones validated by bindiff wrapper • Ones setting their device's access control
22. DEVICE ACCESS CONTROL SETTINGS 2/22/2024 Vulnerable Driver Demo 23 [WDTInstall.AddReg] HKR,,DeviceCharacteristics,0x10001,0x0100 ; Use same security checks on relative opens HKR,,Security,,"D:P(A;;GA;;;BA)(A;;GA;;;SY)" ; Allow generic-all access to Built-in administrators and Local system APIs in source code APIs in source code AddReg directive in configuration (.inf)
23. VERIFICATION ANALYSIS • Thanks to the script‘s analysis function, the validation was basically easy • But I had to take care of some unique issues 2/22/2024 Vulnerable Driver Demo 24 Unique privilege check
24. VERIFICATION ANALYSIS (CONT.) 2/22/2024 Vulnerable Driver Demo 25 Unique IOCTL buffer decoding/encoding
25. RESULT • 34 unique vulnerable drivers (237 file hashes) allowing firmware access • 30 WDM, 4 WDF • Intel, AMD, Phoenix Tech, GE, IBM, Avast, DELL, NVIDIA, Realtek, Samsung, OMRON, etc. • All drivers give full control of the devices to non-admin users • I could load most drivers on HVCI-enabled Win11 except five • Other arbitrary R/W vulnerabilities • Kernel VA (6), MSR (12), CR (3), registry key/value (2) • I reported vendors whose drivers had valid signatures • Only two vendors fixed then assigned the CVEs • CVE-2023-35841 and CVE-2023-20598 2/22/2024 Vulnerable Driver Demo 26
26. EXPLOIT DEVELOPMENT
27. FIRMWARE ERASING • Six firmware erasing PoCs erase the first 4KB data of firmware in the SPI flash memory • Get the SPI Base Address Register (SPIBAR) value through arbitrary port I/O • Access SPI registers using the SPIBAR through arbitrary memory mapped I/O 2/22/2024 Vulnerable Driver Demo 28
28. SPI REGISTER ACCESS DETAILS • The same logic as the CHIPSEC SPI erase command except using vulnerable drivers 1. Clear FDONE/FCERR/AEL bits in the Hardware Sequencing Flash Status (HSFS) register for initialization 2. Set an address value (0) to the Flash Address (FADDR) register 3. Set FCYCLE and FGO bits in HSFS to start the SPI erase command 4. Check FDONE & SCIP bits in HSFS to make sure that the command execution is finished 2/22/2024 Vulnerable Driver Demo 29
29. MEMORY MAPPED I/O PATTERNS 2/22/2024 Vulnerable Driver Demo 30 Multiple IOCTL requests are needed for SPI register R/W Users can get a user- mode pointer for R/W by A single request
30. SPI FLASH PROTECTION SETTINGS • Modern hardware platforms have SPI flash protection settings • e.g., BIOS Lock Enable (BLE) and SMM BIOS Write Protection (SMM_BWP) in the BIOS Control Register (BCR) • The settings were not effective for the erase command 2/22/2024 Vulnerable Driver Demo 31
31. DEMO • Firmware erasing • Win10 on Apollo Lake SoC • Intel WDF driver exploit 2/22/2024 Vulnerable Driver Demo 32
32. RECOVERING 2/22/2024 Vulnerable Driver Demo 33
33. ELEVATION OF OS PRIVILEGE (EOP) • Three EoP PoCs are classic token stealing exploits • Read a token value of the System process in the kernel _EPROCESS structure and write the value into the field of the Python exploit process 2/22/2024 Vulnerable Driver Demo 34
34. KERNEL MEMORY ACCESS PATTERNS • Two drivers allow the arbitrary virtual memory access directly • Another driver demands two IOCTL requests per kernel memory access 1. Translate a virtual address to a physical one by MmGetPhysicalAddress 2. R/W data at the physical address through arbitrary memory mapped I/O 2/22/2024 Vulnerable Driver Demo 35
35. DEMO • EoP • HVCI-enabled Windows 11 • AMD WDM driver exploit 2/22/2024 Vulnerable Driver Demo 36
36. WRAP-UP
37. WRAP-UP • By implementing the static analysis automation script, I discovered 34 unique vulnerable drivers (237 hashes) • WDM drivers are still widely used • But we can also discover and exploit vulnerable WDF drivers in the same way • I found not only old vulnerable drivers but also new ones with valid signatures • We need more comprehensive approaches than the current banned-list method • E.g., a simple prevention of loading drivers signed by revoked certificates will block about one-third of the vulnerable drivers
38. WRAP-UP (CONT.) • The vendor's fixes for vulnerable drivers are to just set the device access control rejecting non- admins • This can prevent EoP but leaves the BYOVD techniques unresolved! • I expect that threat actors will continue to utilize the techniques by just exploiting the fixed drivers 2/22/2024 Vulnerable Driver Demo 39
39. CUSTOMER PROTECTION • The IOCs of the vulnerable drivers are available in the “Living Off The Land Drivers” watchlist • Created from the community website LOLDrivers • The sent IOCs contain not only the vulnerable drivers but also “not vulnerable” ones with right device access control • e.g., the fixed version of TdkLib64.sys • The number of the total added hashes will be 272 2/22/2024 Vulnerable Driver Demo 40