KExecDD Proof-of-Concept Explores Windows Driver Exploits
/ 5 min read
Quick take - In early 2024, a proof-of-concept named KExecDD was published on GitHub, demonstrating a method to exploit the Windows KsecDD driver to execute arbitrary kernel code through a specific IOCTL, while also exploring the implications of Server Silos and LSA Protection in relation to the exploit’s feasibility and limitations.
Fast Facts
- In early 2024, a proof-of-concept (PoC) called KExecDD was released on GitHub, utilizing the KsecDD Windows driver to execute arbitrary kernel code via a specific IOCTL.
- The Local Security Authority Server Service (LSASS) primarily accesses this IOCTL, but researchers found a method to bypass its single-session limitation by injecting code into LSASS.
- Server Silos, akin to containers, can be created in Hyper-V backed or Process Isolation modes, with experiments showing that LSA Protection behavior inside a container mirrors that of the host OS.
- The researchers successfully built a container with LSA Protection disabled, allowing them to reuse the KExecDD PoC without rebooting the host, although enabling LSA Protection with UEFI lock rendered the exploit unfeasible.
- They identified a memory read gadget to read kernel memory, extending their PoC’s capabilities, but encountered a crash after multiple executions, proposing solutions to address the issue.
KExecDD PoC Exploits Windows Driver Vulnerability
In early 2024, a proof-of-concept (PoC) named KExecDD was published on GitHub by user @floesen_. This PoC leverages the built-in Windows driver KsecDD, which implements the Kernel Security Support Provider Interface (KSSPI).
LSASS and IOCTL Access
The driver allows the Local Security Authority Server Service (LSASS) to execute arbitrary kernel code through a specific IOCTL (Input Output Control). This IOCTL permits a userland client to call an arbitrary kernel address, granting control over the first two arguments. Access to this IOCTL is primarily restricted to LSASS, which is the first process to connect to the KsecDD driver during the Windows boot sequence. Subsequent connection attempts are thwarted by a limitation that allows only one session per Server Silo context. Researchers have identified a method to bypass this limitation by injecting code into LSASS and reusing the device handle already opened by the process. However, if LSASS runs as a Protected Process Light (PPL), this injection method is not feasible.
Exploring Server Silos
The article further explores the concept of Server Silos, which function similarly to containers on other platforms. Server Silos can be created in two modes: Hyper-V backed and Process Isolation. Containers operating in Process Isolation share the kernel with the host operating system, making them particularly relevant for the discussed exploits. Docker Desktop commonly creates Linux containers in virtual machines but can be configured to create Windows containers in Process Isolation mode.
The researchers conducted experiments running LSASS unprotected inside a Docker container where LSA (Local Security Authority) Protection is enabled on the host. LSA Protection can be configured through a registry key with three possible states: disabled, enabled with UEFI lock, and enabled without UEFI lock. The behavior of LSA Protection inside a container mirrors that of the host OS. The authors successfully built a container with LSA Protection set to disabled, allowing them to reuse the KExecDD PoC without needing to reboot the host system. If LSA Protection is enabled with UEFI lock, the exploit remains unfeasible.
Custom Server Silo and Exploitation Challenges
Additionally, the authors investigated the possibility of creating their own Server Silo to connect to the KsecDD driver independently of LSASS. They utilized proof-of-concept code provided by Quarkslab to create a custom Server Silo and successfully executed an arbitrary process within it. When they attempted to connect to the KsecDD driver from within the created Server Silo, they found varying results: the connection succeeded on Windows 11, but the connection attempt on Windows 10 resulted in a hang due to an infinite timeout on an event that was not being signaled. By modifying their approach to signal the event prior to connecting to the KsecDD driver, they achieved successful connections on both Windows versions.
The initial PoC employed a memory write gadget to disable Driver Signature Enforcement (DSE), which could potentially lead to a Blue Screen of Death (BSoD) if not managed correctly. The researchers aimed to find a memory read gadget to reliably read kernel memory addresses and succeeded in identifying a gadget that allowed reading 8 bytes of kernel memory from arbitrary addresses. This advancement enabled them to extend their PoC to read and write arbitrary memory in kernel space, unlocking various exploitation possibilities. However, they encountered a recurring system crash after the fifth execution of their PoC, traced to an invalid memory access linked to a lookaside list in the driver with a depth limit of four.
To address this issue, the authors proposed two potential solutions: resetting the internal counter of the list or overriding the list’s depth attribute. They concluded that while they could successfully create a Server Silo and connect to KsecDD, the exploit could only be executed four times before resulting in a crash. The authors suggested that further exploration of the IOCTLs exposed by the driver might yield a solution to this crash limitation. A proof-of-concept for their findings is available on GitHub for further scrutiny and research.
Original Source: Read the Full Article Here
