STATIC ANALYSIS AUTOMATION FOR HUNTING VULNERABLE KERNEL DRIVERS Takahiro Haruyama VMware Carbon Black Threat Analysis Unit

OVERVIEW • Background • Previous Research • My Approach • Implementation • Hunting Vulnerable Drivers • Result • Exploit Development • Wrap-up 2/22/2024 Vulnerable Driver Demo 3

BACKGROUND

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

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

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

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

IMPLEMENTATION

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

IMPLEMENTATION SUMMARY • Two functions: triage and analysis • The analysis function substantially assists the tedious manual validation 2/22/2024 Vulnerable Driver Demo 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)

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

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

THE DEVIL IS IN THE DETAILS (API CALL VARIATION) 2/22/2024 Vulnerable Driver Demo 15 Direct call Calculating the offset from the table

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

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

WDF APIS HANDLING USER DATA I/O • WdfRequestRetrieveInputBuffer • WdfRequestRetrieveOutputBuffer • WdfRequestRetrieveInputWdmMdl • WdfRequestRetrieveOutputWdmMdl • WdfRequestRetrieveInputMemory • WdfRequestRetrieveOutputMemory • WdfRequestGetParameters 2/22/2024 Vulnerable Driver Demo 18

DEMO • WDM analysis • WDF analysis 2/22/2024 Vulnerable Driver Demo 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

HUNTING VULNERABLE DRIVERS

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

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)

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

VERIFICATION ANALYSIS (CONT.) 2/22/2024 Vulnerable Driver Demo 25 Unique IOCTL buffer decoding/encoding

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

EXPLOIT DEVELOPMENT

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

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

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

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

DEMO • Firmware erasing • Win10 on Apollo Lake SoC • Intel WDF driver exploit 2/22/2024 Vulnerable Driver Demo 32

RECOVERING 2/22/2024 Vulnerable Driver Demo 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

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

DEMO • EoP • HVCI-enabled Windows 11 • AMD WDM driver exploit 2/22/2024 Vulnerable Driver Demo 36

WRAP-UP

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

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

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