CVE-2023–21752 — Windows Privilege Escalation via Backup Services

vsociety
10 min readApr 27, 2024

by@yosef0x1

Screenshots from the blog posts

Summary

deep dive into CVE-2023–21752 which was EOP in Windows backup services, patch diffing the binaries, and catch the root case

Description

  • CVE: CVE-2023–21752
  • Title: Privilege Escalation Windows through Buckup Service
  • Platform / Vendor: Windows OS / Microsoft Product
  • Summary: The vulnerability in the Windows Backup service that allows an attacker to delete files and gain higher privileges on the system is NT AUTHORITY\SYSTEM and rigistred as #CVE-2023-21752
  • Components affected_: Windows Buckup service for (11, 10, 7) Windows versions
  • Exploit type: Privilege Escalation

Process Monitor: is a tool from Windows Sysinternals, part of the Microsoft TechNet website. The tool monitors and displays in real-time all file systems Windows used to trace the process in runtime

Ghidra: Ghidra is a free and open-source reverse engineering tool developed by the National Security Agency of the United States used to reverse and decompile the code to get a better understanding

Bindiff: is a comparison tool for binary files, that assists vulnerability researchers and engineers to quickly find differences and similarities in disassembled code to patch diffing the binaries and catch the changed parts

WinObj: is a program that uses the native Windows API (provided by NTDLL.DLL) to access and display information on the NT Object Manager's namespace

Visual Studio basic: to build && debugging the exploit

Background Story

This CVE was the first local Windows kernel exploit in 2023, When it comes to the analysis it’s used to abuse Windows backup services to delete any file on the system with Windows installer to force it to install malicious msi files the exploit wasn't stable and easy because the threads sometimes the process can't handle it in the needed time The technique was so interesting and developed by James forshow in this repo It's used many times to achieve EOP through applications created files with the system privilege

Reproducing the Vulnerability

the exploit needs to be built first using Visual Studio basic

And install Visual Studio Build Tools

After extracting the Exploit script open the Visual Studio basic project file SDRsvcEop.sln

open the Build Tab and Click on the Build Solution or Ctril+Shift+B and then research for the SDRsvcEop.exe file in the \x64\Release

note it’s not stable (because of threads I will explain it later in the analysis) so I wrote a simple Power loop to run the exploit v2 which privileges the user escalation to System Authority

as shown below:

the description wasn’t clear enough to give me the entry point to start analyzing the CVE so I spent time searching for the the responsible vulnerable binary file that’s used in the exploit code but the exploit was giving a hint the Path \\127.0.0.1\c$\Users\yosef\AppData\Local\Temp\f11cb767-0d6f-4315-be96-378e1178738d

so be adding a filter in procmon for the file creation with the file path that created in the exploitation process

was the filtred result as the following

After opening the first result of File creation

and by searching in the module section the sdrsvc.dll and sdengin2.dll The only files that are related to Windows Buckup servies

sdrsvc.dll

sdengin2.dll

I now have found the probably vulnerable DLL's files and to start the analysis I need to make sure these were the vulnerable files and where to start the entry point and more information about the patch, I want windows_binary_index to download these files But to specify the patch it needs to have the kb knowledge update number which stands for knowledge based on the MSRC (Microsoft Security Response Center) of this CVE and it was KB5022282

So while searching for KB5022282 Update I noticed that

[1] The patched sdrsvc.dll file

[2] The unpatched version of sdrsvc.dll file

and take and takes these files to do the patch diffing

Patch diffing

Patch diffing is used to determine how the patch did what’s removed and what’s added to these files I’m using Ghidra with Bindiff

Download the Ghidra bin export from here

Open Ghidra and go to File > Install extensions to add the ghidra_BinExport

Add extension

chose the downloaded zip file

And install

uploaded the files into the active projects

and let Ghidra analyze these files, and export them after analyzing by going to File > Export program.

and Export the file as Binary BinExport

Now open Bindiff New workspace

Diffs > New Diff

upload the exported files to BinDiff

  • Primary which is the unpatched file
  • Secondary which is the patched file

the result was like this there are no unmatched functions it’s means it’s the same code didn’t change in this security patch

and by looking at the Similarity there is not even one function under 1.00 this means this file has the same functions and didn’t change before and after the security patch

so I want to sdengin2.dll file and loading the exported data from Ghidra for each file

There was Interesting stuff here in the sub_180008FEC the lowest similarity rate 0.90

showing it in the graph and was as the following (the red color means the removed parts)

Zooming on into the red color parts in the primary (unpatched file) and found GetTempFileNameW which is responsible for temp file generation so I want Ghidra to decompile this function

After searching for the program text I found FUN_180008FEC code was as the following in the patched version and unpatched as we can see the vulnerable code replaced to checkpathiswriteable which confirms the purpose of the removed part

Root cause

TOCTOU

uVar1 = 0x13d;
if (param_1 != (LPCWSTR)0x0) {
local_27c = 0x13d;
uVar1 = 0x13e;
if (param_3 != (undefined4 *)0x0) {
local_280 = 0;
local_27c = 0x13e;
if (param_2 == 7) {
pcVar8 = (char *)0x0;
pWVar6 = L"SDT";
UVar2 = GetTempFileNameW(param_1,L"SDT",0,TempFileName);
if (UVar2 != 0) {
local_280 = SxDeleteFile(TempFileName);
param_1 = pWVar6;
uVar1 = 0x148;
if ((int)local_280 < 0) goto LAB_1800092b5;
local_27c = 0x148;
goto LAB_180009294;
}

After decompiling the assembly code for this function found that the root cause was race condition through TOCTOU(time-of-check, time-of-use) when it generated a temp file by GetTempFileNameW and then deleted this temp file (TempFileName) using SxDeleteFile to determine if this path was writeable and had the user's permission on this path, The abuse came in the time between generation and delegation to give the attack the choice to link the generated temp file to another file in the system and because the services have the highest Privilege in the system it's with all permission the linked file get deleted. there is a technique that is so interesting to convert Arbitrary File Deletion to Privilege escalation via Windows installer services through rollback. Let's explain the techniques in more detail below

Both exploits uses two types of Sys link which is Junction (NTFS junctions) and Symbolic link (Object Manager symbolic links) and luck the files using opluck

junction: An NTFS feature allows directories to be set as mount points, similar to mounting, which involves redirecting a directory to another file.

Symbolic link: is an Object Manager symbolic link in Windows that connects one object to another. Non-admin users can't create filesystem symlinks and the

C: disk is a symbolic link to a hardware disk in the devices. as shown below

Opluck: are locks placed on files to receive notifications when other processes attempt to access the same file. These locks can also involve the setup of callbacks to perform specific actions when triggered

Those two links are used together because we can’t link the junction to the file under C: directory but with symbolic links and \RCP control\ Directory which is Writeable for all users we can do this operation successfully

The v1 Exploit

can be found in the following link

1- The exploit takes an argument first as the target file to delete and then Creates a Path with GetTmpDir() and take the file handle

with a loop to make sure it’s created and then create a thread with FindFile and call Trigger() which passes the created path to the backup services and triggers the services to create the temp file that FindFile monitoring to find

FindFile

2 — Find file motoring the path directory If any change happens and using CreateFile() to try to open it to make sure that the file was created then it's set up an oplock with a callback cb

cb

3 — The call back was moving the file to ensure it’s locked and linking it to \RPC control\ to make it able to link objects inside the C: driver and then link the file under RPC control to the target file to let the back services delete

4- and then clean up by deleting the links

the v2 Exploit

which can be found in the following link

The second version of the exploit wasn’t really focused on Buckup services it used the Windows installer to achieve the EOP So it's enough to explain the threads in this one It's combined with just the new technique as v1 It uses threads at the same time to monitor and make everything done at the perfect time and that is the reason why the exploit is not stable because the thread may fail in the time

The main thread

First, it’s Create Config.msi and create a temp to pass to the backup services

then create the second thread to monitor the FindFile function which searches for any change that happens to temp directly for the create from the backup services Create a Fail thread in case the threads fail to raise an error message then set Opluck at the config.msi with a callback that will cb1 which do the install

FindFile

Loop to check if any file is already created in the temp directory. If a file is created, the loop will break after establishing an Oplock on this file. In case any process requests from a thread or process to execute the callback, cb will be executed. If backup services attempt to delete the file, the callback cb will be triggered. After execution, it will be released."

Triage

triggers backup services which try to delete the temp file

Install

which is created by cb1 The first thing it will run the Windows installer using msi file which contains two parts, The first part contains a sleep function, and the other causes an error to rollback

Mitigation

Upgrade your Windows OS to the latest version

Final Thoughts

During the CVE, after reversing the dll's files and get the root cause while trying to simplify the long steps and techniques as much as I could, this CVE wasn't easy at all. It had a lot of concepts that I was hearing about for the first time, and the steps were not even simple. Many articles were filed to explain it well, especially Opluck the callback. but I gained some interesting stuff, including the symbolic links, which are considered to be good weapons for gaining EOP through file manipulation for all Security Researchers and Red Tamers.

Resources

https://www.zerodayinitiative.com/blog/2022/3/16/abusing-arbitrary-file-deletes-to-escalate-privilege-and-other-great-tricks

https://offsec.almond.consulting/intro-to-file-operation-abuse-on-Windows.html

https://www.cyberark.com/resources/threat-research-blog/follow-the-link-exploiting-symbolic-links-with-ease

https://www.youtube.com/watch?v=tGOGj1lsSwo&t=1134s&ab_channel=AllHackingCons

--

--

vsociety

vsociety is a community centered around vulnerability research