Windows 10 PLUGScheduler Elevation of Privilege
24/05/2024 - Téléchargement
Product
Windows
Severity
High
Fixed Version(s)
KB5037768
Affected Version(s)
Windows 10 21H2 and 22H2
CVE Number
CVE-2024-26238
Authors
Description
Presentation
RUXIM (Reusable UX Integration Manager) is a component used by Windows Update on Windows 10. PLUGScheduler is a scheduled task, part of RUXIM, located in \Microsoft\Windows\WindowsUpdate\RUXIM
and that runs as SYSTEM.
Issue(s)
The PLUGScheduler.exe
binary performs file operations such as deletion and renaming as SYSTEM, in a directory where standard users have partial control. This leads to arbitrary file write as SYSTEM.
Timeline
Date | Description |
---|---|
2024.01.22 | Advisory sent to MSRC |
2024.02.01 | Vulnerability confirmed by MSRC |
2024.05.14 | Vulnerability assigned CVE-2024-26238 and patched in KB5037768 |
2024.05.24 | Public release |
Technical details
Description
When triggered, the PLUGScheduler scheduled task runs the C:\Program Files\RUXIM\PLUGScheduler.exe
executable as SYSTEM. The latter creates the C:\ProgramData\PLUG\Logs
folder if it does not exist. Afterward, it deletes the RUXIMLog.050.etl
file and proceeds to rename all the files with the RUXIMLog.XXX.etl
format. More specifically, the RUXIMLog.049.etl
file is first renamed to RUXIMLog.050.etl
, then RUXIMLog.048.etl
to RUXIMLog.049.etl
, and so on until RUXIMLog.001.etl
is renamed to RUXIMLog.002.etl
. Eventually, it starts an event tracing session into the RUXIMLog.001.etl
file.
The C:\ProgramData\PLUG\Logs
folder is configured with permissive ACLs for standard users. In particular, built-in users can:
- Create files inside
Logs
. - Create folders inside
Logs
. - Write attributes of the
Logs
folder.
The ability to write attributes of the Logs
folder allows a standard user to add a junction point so that Logs
redirects to the \RPC Control
object directory. Afterward, two Object Manager symbolic links can be created:
\RPC Control\RUXIMLog.049.etl
->C:\path\to\attacker\controlled\file
\RPC Control\RUXIMLog.050.etl
->C:\eop.txt
The next time PLUGScheduler.exe
is executed, the RUXIMLog.049.etl
file will be renamed to RUXIMLog.050.etl
. Because of the previously set up links, the attacker-controlled file will be moved to C:\eop.txt
, achieving arbitrary file write as SYSTEM.
However, for a junction point to be added to the Logs
directory, the latter must be empty. The issue is that the files inside Logs
cannot be deleted by standard users (only SYSTEM and Administrators have the necessary privileges). Before renaming a file, PLUGScheduler.exe
uses the GetFileAttributesW
function to check if the path corresponds to a file. If this is not the case, it does nothing and continues to the next file. Therefore, if RUXIMLog.001.etl
is a directory, it will not be renamed to RUXIMLog.002.etl
. Let us consider the following content of the Logs
directory:
Logs
|__ RUXIMLog.001.etl (directory)
|__ RUXIMLog.002.etl (file)
|__ RUXIMLog.003.etl (file)
After an execution of PLUGScheduler, the directory will look like:
Logs
|__ RUXIMLog.001.etl (directory)
|__ RUXIMLog.003.etl (file)
|__ RUXIMLog.004.etl (file)
After 47 executions of the task, the directory will look like:
Logs
|__ RUXIMLog.001.etl (directory)
|__ RUXIMLog.049.etl (file)
|__ RUXIMLog.050.etl (file)
On the next execution of the task, the RUXIMLog.050.etl
file will be deleted and the RUXIMLog.049.etl
file will be renamed to RUXIMLog.050.etl
. It is thus possible, through this behavior, to run the task enough times so that all the files included in the C:\ProgramData\PLUG\Logs
directory are removed.
The last remaining issue is creating the RUXIMLog.001.etl
directory, since the RUXIMLog.001.etl
file cannot be deleted by standard users. There is a small time window between the moment the RUXIMLog.001.etl
file is deleted and the moment it is re-created as the event tracing file. It is therefore possible to create the directory between these two actions. The race condition can be won easily in a few attempts by creating a scheduled task as the current user, that is triggered on each logon. The scheduled task will attempt to create the RUXIMLog.001.etl
directory in an infinite loop until it succeeds. It was discovered that, in order to reliably win the race, the program needs to be compiled as a graphical Windows application instead of a console application (probably because a cmd
window is displayed for a console application).
The PLUGScheduler scheduled task is triggered at each logon and also once a day at a fixed time. The standard user can therefore trigger it by logging off and logging in again. The exploitation strategy is thus the following:
- Set up a scheduled task as the current user, with a trigger at each logon. This task will attempt to create the
RUXIMLog.001.etl
directory inC:\ProgramData\PLUG\Logs
. Log off and log on until the race condition is won and the directory is created (usually a few attempts are needed). - When the directory is created, log off and log on until there is only one entry in
C:\ProgramData\PLUG\Logs
: theRUXIMLog.001.etl
directory. - Remove the
RUXIMLog.001.etl
directory. - Set up the
C:\ProgramData\PLUG\Logs
->\RPC Control
junction point. - Set up the Object Manager symbolic link
\RPC Control\RUXIMLog.049.etl
->C:\path\to\attacker\controlled\file
. - Set up the Object Manager symbolic link
\RPC Control\RUXIMLog.050.etl
->C:\eop.txt
. - Log off and log on: the attacker controlled file was moved to
C:\eop.txt
.
Impact
This vulnerability is an arbitrary file write. It can be used to execute code as SYSTEM by writing a DLL file in C:\Windows\System32\SprintCSP.dll
and triggering the SvcRebootToFlashingMode
method of the StorSvc
service (as detailed in https://github.com/blackarrowsec/redteam-research/tree/master/LPE%20via…). Note that this is only an example as to how the file write vulnerability can be leveraged to achieve elevation of privilege, and there are many other ways to do so.
Recommendation
Define a stricter ACL for the C:\ProgramData\PLUG
directory and its child objects. Only privileged users must be able to write inside.