CVE-2023–21752 — Windows Privilege Escalation via Backup Services
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://offsec.almond.consulting/intro-to-file-operation-abuse-on-Windows.html
https://www.youtube.com/watch?v=tGOGj1lsSwo&t=1134s&ab_channel=AllHackingCons