Add in Exploit for CVE-2021-36955 - Microsoft Windows Common Log File System Driver Elevation of Privilege Vulnerability Exploit

[gwillcox-r7]

Summary

A bug exists in the Common Log File System Driver aka clfs.sys which allows for elevation of privilege to the SYSTEM user.

Basic example

PoC at https://github.com/JiaJinRong12138/CVE-2021-36955-EXP

Motivation

Core Impact has added a PoC to their tools and there is a public PoC we can port over into Metasploit. Additionally this vulnerability is known to have been exploited in the wild.

[gardnerapp]

I've read through the PoC you've provided and don't have a full understanding of how this exploit works, granted my C skills aren't that sharp (pun very much intended). Couldn't find any blog post or articles explain the flaw in the software either.

I am new to exploit development but not to Ruby, would developing this module merely be translating his C code over to Ruby? In the mean time I will be reading up on the Windows CLSD !

[gwillcox-r7]

Hi @gardnerapp most likely this would involve wrapping the original C code into a reflective DLL using the steps listed at https://github.com/rapid7/metasploit-framework/tree/c44fb61c9a8a9be54b99a36f2c09f162fc64d261/external/source/rdll_template. This would be a step done after verifying that the PoC works though.

Unfortunately I'm not sure which system this exploit was targeting, which is a bit concerning 😅. You might be able to determine it by looking at undefined structure definitions using tools such as https://www.geoffchappell.com/ or https://www.vergiliusproject.com/ to see if the structures specifically match some version of the Windows Kernel.

Kernel exploits aren't generally the easiest place to start as a new exploit developer however if your interested I can try assist on this one. There are some general concepts I see in the exploit that are familiar to me having worked on kernel exploits before so I'd be happy to answer some general questions. Anything more specific may require me taking some time to dive into the code a bit more though but feel free to ask about them.

[gardnerapp]

Within the POC you provided there is an enum type defined for the_SYSTEM_INFORMATION_CLASS at head.h:41. After looking through the Vergilius project I've found that this enum is defined in the following versions of the Windows Kernel:

On x64:

Windows 10 2016 2104 21H1 (May 2021 Update) 
Windows 10 2016 2110 21H2 (November 2021 Update) 
Windows 11 Insider Preview (June 2021) 
Windows 11 21H2 (RTM) 
Windows 11 22H2 (2022 Update)

On x86:
Windows 10 2016 2104 21H1 (May 2021 Update) 
Windows 10 2110 21H2 (November 2021 update)

Some of the fields within this struct vary within each version of the kernel and I am in the process of trying to figure out which fields are and are not present in each version of the Kernel. This will hopefully shed some light as to which version of the Kernel this specific exploit is targeting.

Obviously this exploit is meant to target Windows systems with the _SYSTEM_INFORMATION_CLASS enum defined. According to the NIST bulletin on this CVE Windows versions < 8, as stated before earlier versions of Windows do not have _SYSTEM_INFORMATION_CLASS defined and we'll likely need to re-write the exploit for a POC on these systems.

A few questions we need to answer:

1. Does the POC work on x86 and x64 systems?
2. Which Version of the Kernel(s) does it work on ?
   and 3) What would a POC for earlier Windows systems look like?

I appreciate your help sir, unfortunately I am running on an OSX system with an ARM chip. Which means it is damn near impossible to properly run a VM and test the POC. What is the best way to test the POC? Should I just spin up remote systems on the cloud with the different Kernel versions? Also I do not work with Visual Studio on my OSX, is there another way I can configure the reflective DLL without VSC ?

[gwillcox-r7]

Within the POC you provided there is an enum type defined for the_SYSTEM_INFORMATION_CLASS at head.h:41. After looking through the Vergilius project I've found that this enum is defined in the following versions of the Windows Kernel:

On x64:

Windows 10 2016 2104 21H1 (May 2021 Update) 
Windows 10 2016 2110 21H2 (November 2021 Update) 
Windows 11 Insider Preview (June 2021) 
Windows 11 21H2 (RTM) 
Windows 11 22H2 (2022 Update)

On x86:
Windows 10 2016 2104 21H1 (May 2021 Update) 
Windows 10 2110 21H2 (November 2021 update)

Some of the fields within this struct vary within each version of the kernel and I am in the process of trying to figure out which fields are and are not present in each version of the Kernel. This will hopefully shed some light as to which version of the Kernel this specific exploit is targeting.

Obviously this exploit is meant to target Windows systems with the _SYSTEM_INFORMATION_CLASS enum defined. According to the NIST bulletin on this CVE Windows versions < 8, as stated before earlier versions of Windows do not have _SYSTEM_INFORMATION_CLASS defined and we'll likely need to re-write the exploit for a POC on these systems.

A few questions we need to answer:

1. Does the POC work on x86 and x64 systems?
2. Which Version of the Kernel(s) does it work on ?
   and 3) What would a POC for earlier Windows systems look like?

I appreciate your help sir, unfortunately I am running on an OSX system with an ARM chip. Which means it is damn near impossible to properly run a VM and test the POC. What is the best way to test the POC? Should I just spin up remote systems on the cloud with the different Kernel versions? Also I do not work with Visual Studio on my OSX, is there another way I can configure the reflective DLL without VSC ?

Unfortunately OSX with ARM is going to be hard. Particularly for kernel research its best to have a host system that is the same as the target that you are trying to debug. You might be able to get away with doing a serial port or on newer Windows a network kernel debugging between two VMs, but if your unable to run VMs on Apple ARM then I'd consider getting another machine for research. I think there is some better virtualization available but even at our company we try to avoid Apple ARM due to the virtualization issues causing too much hassle.

There is no good way to do the reflective DLL without VS unfortunately, as it was designed to be built using Visual Studio.

[gardnerapp]

this report details the systems effected by the CVE-202-36955.