A journey into the discovery of two privilege escalation vulnerabilities in the Lenovo update functionality.
The information in this blog post is related to the the following vulnerabilities detected by Compass Security:
- CVE-2022-4568 in Lenovo System Update prior to 5.08.01
- CVE-2022-4569 in ThinkPad Hybrid USB-C with USB-A Dock Firmware Update Tool prior to V1.0.35_v2
The presented vulnerabilities were disclosed immediately after discovery and Lenovo has remediated both vulnerabilities as of the writing of this blog post.
A Wild CMD Window Appears
Have you ever been working and suddenly an unexpected CMD window shows up, grabs your keyboard focus and disappears again?
It was this unpleasant experience that started the journey. An unexpected and quickly disappearing CMD window always leaves a bland aftertaste – especially working in IT Security. This is why we decided to push off work for a few minutes and started a quick investigation into the origins of the window.
The investigation into the Security Event Log revealed the following interesting Event ID 4688 at the relevant time, showing the executed process:
|Executable Path||User Name|
We may therefore assume the observed CMD Window is related to an automatic Lenovo update installed for the ThinkPad Hybrid USB-C Dock.
Furthermore, the elevated CMD Window runs an executable in the path
C:\DRIVERS\ThinkPad_Hybrid_USB-C_With_USB-A_Dock_MFG_Driver_V18.104.22.168 under a user
Let’s look at the user first.
A user account is created during a Lenovo System Update as a way for restricted users to install updates with elevated permissions.
UACSdk.exe creates the user with the prefix
lenovo_tmp_ and a partially randomized username consisting of four lowercase and four uppercase characters. The account is created as a regular user at first via NetUserAdd and later on added into the Administrators group.
Vulnerabilities were found in the user creation in the past and the according blog article by IOActive describes the behavior of the Lenovo Update well.
Can we obtain the credentials to the user?
The password of the user is generated before user creation. Mainly the deprecated function CryptGenRandom is used for generating 76 random bytes.
After this, the randomly generated bytes are split, shifted, and mangled together and then converted to UTF-8 Unicode. In the end, a total of 19 characters are selected for the password and a null terminator is included.
The short analysis of the password generation did not result in a viable option to obtain the password.
However, it remains to say that the password generation method also involves behavior, which was not fully understood. For example, the creation of a hash of the random bytes and the immediate destruction of the result (potentially checking for errors?).
Usually, the user is deleted after the installation of the updates is finished. There is also a cleanup routine to delete all users with names containing
lenovo_tmp potentially dealing with the issue of not always fully deleted users.
Interestingly, some companies may have introduced a monitoring exceptions for account creation with names, such as
lenovo_tmp, which may come in handy when running an attack.
Furthermore, the path from where the executable is started is unusual as well.
C:\DRIVERS path of the executable caught our eye because on a usual Windows installation, the user has permissions to append subdirectories to the drive root and naturally has modify permissions on these directories.
A quick check off the file permissions or more precisely discretionary access control lists (DACLs) with icacls shows that all authenticated users have modify permissions on the directory in question as well:
PS> icacls C:\DRIVERS\ThinkPad_Hybrid_USB-C_With_USB-A_Dock_MFG_Driver_V22.214.171.124 ... NT AUTHORITY\Authenticated Users:(I)(M) NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
Therefore, it should be possible to replace the Lenovo executable
dpinst.exe with another executable and trigger an update to reach code execution under the elevated
Well, yes but no: There is a digital signature check of the executable involved (which on a side note may have been prone to a bait and switch attack), but an easier exploitation is possible:
The Event Logs show, that in the same modifiable directory, there is a batch file
DriverInstallerScript.bat run under the same elevated permissions during the update.
|Executable Path||User Name|
This batch script tries to determine the current OS Version and ultimately runs the before observed
dpinst.exe. As there is no file signature, it should be possible to simply modify the batch script and run the update to execute commands.
Naturally, the ThinkPad Hybrid Dock is required for this exploitation. However, if it is present, a few lines of code allow to exploit CVE-2022-4569: The following example shows how to insert a new administrator through the batch file and start of the Lenovo Update Service as well as run the command for an update:
PS> echo "net user /add InsertedUser S3kur.Password.Here.123" >> "C:\DRIVERS\ThinkPad_Hybrid_USB-C_With_USB-A_Dock_MFG_Driver_V126.96.36.199\DriverInstallerScript.bat" PS> echo "net localgroup Administrators InsertedUser /add" >> "C:\DRIVERS\ThinkPad_Hybrid_USB-C_With_USB-A_Dock_MFG_Driver_V188.8.131.52\DriverInstallerScript.bat" PS C:\Program Files (x86)\Lenovo\System Update> .\ConfigService.exe start PS C:\Program Files (x86)\Lenovo\System Update> .\TvsuCommandLauncher.exe 5
As behavior like adding a new user is usually monitored, the triggered alert nicely displays the chain of events:
It is up to the reader to think of a stealthier strategy for exploitation or a username with monitoring exclusions.
More DACL Issues
During the analysis of the executables involved in the Lenovo Update, several executables were quickly glanced over. One notable executable is named
Tvsukernel.exe, which is typically run under the administrative
lenovo_tmp user by the “System Update” Service.
Tvsukernel.Startup.Main shows the following cleanup routine:
Directory.Delete call shows the directory
C:\TvsuSession is recursively deleted. This means all files and subdirectories within the directory are deleted as well:
Similarly to above, this directory can be created and modified by any authenticated user as well. But how can we exploit this recursive folder deletion?
From File Deletion to Elevated Code Execution
In 2021, Abdelhamid Naceri has demonstrated a technique, on how deletion of user writable folder contents by an elevated account may lead to code execution under the elevated accounts privileges. An excellent description of the technique is found on the blog of Zero Day Initiative.
Although having been used in a multitude of exploits recently, this technique is still not common knowledge. Therefore, we will go over the building blocks.
First, how would we get code execution from an arbitrary file deletion?
The Windows Installer Service
The Windows Installer Service is responsible for performing installations of applications. During every installation, the service creates records of all changes performed. These records allow a rollback in case of an error during installation and therefore allow reverting to a previous system state cleanly. The records are stored in a folder named
Control of these records (by overwriting them) results in the control of the filesystem state after an installation rollback is performed. Therefore, if attackers can delete the
C:\Config.Msi directory during an installation with elevated privileges, they can then write their own records to be executed when triggering an installation rollback. A typical attack record would drop a file such as an executable or DLL to disk, which is then executed under a privileged account at some point.
Now, how does this help us?
With the found vulnerability we can delete the directory
C:\TvsuSession with administrative privileges but how can it replace
Bending Directory Content Deletion
Ideally, we would now want to create a symbolic link from
C:\Config.Msi in order to bend the deletion of files from the Lenovo directory to the other. However, unprivileged Windows users can’t create symbolic links.
This is where a technique pioneered by James Forshaw comes in: NTFS Junctions in combination with Object Manager symbolic links as described in the following blog article by Almond Offensive Security.
NTFS junctions are a filesystem feature like Unix mount points for directories. It allows unprivileged users to create a link from one directory to another directory only. However, upon deletion of the junction pointing at directory, the original directory is not deleted. As we want to link the files within the directory, such a Junction will only go halfway.
Windows Object Manager
The Windows Object Manager manages objects such as files, devices and registry keys. It can be accessed for example using WinObj by Mark Russinovich. The part interesting to us is, that unprivileged users can create symbolic links in Object Manager directories such as
\RPC Control. Such a symbolic link can point to any path on the filesystem including files.
When chaining NTFS junctions together with Object Manager symbolic links, unprivileged users can create sort of a pseudo symbolic link. We could use such a pseudo symbolic link from
C:\Config.Msi to forward a deletion of the content.
An example tool to create these pseudo symbolic links is provided in the symbolic link-testing-tools Developed by James Forshaw:
PS> .\CreateSymlink.exe C:\TvsuSession\file.txt C:\Config.Msi\file.txt Opened Link \RPC Control\file.txt -> \??\C:\Config.Msi\file.txt: 00000098 Press ENTER to exit and delete the symlink
As we are now able to delete the records of the Windows Installer, we may in theory be able to conduct an attack but we would have trouble getting the timing of the deletion right. This is where the opportunistic lock (oplock) comes in. This lock can be placed on a file and whenever another process tries to accesses the locked file, a callback routine is triggered to inform us about the access. Furthermore, the file access of the other process is delayed until the callback returns. Therefore, the oplock can for example be used to coordinate actions and gain time in race condition scenarios.
Tying Techniques Together
With this, the building blocks for the exploitation of the vulnerability in
Tvsukernel.exe are set. The exact technique exploiting the Lenovo System Update DACL issue is described in more detail on the blog of the Zero Day Initiative under From Folder Contents Delete to SYSTEM EoP.
These are the exact steps performed:
- Start an installation using the Windows Installer Service, which is set up to fail at a later stage.
- Create the following folder structure:
- Create a file within:
- Set an oplock on the file
- Run Lenovo System Update and wait for
Tvsukernel.exeto start the deletion of
file1.txt. This will trigger the oplock.
- In the oplock callback:
file1.txtelsewhere, so that
C:\TvsuSession\folder1is empty and could be deleted (directly deleting
file1.txtwould require the release the oplock).
C:\TvsuSession\folder1as a junction to the
\RPC Controlfolder of the object namespace.
- Create a symbolic link at
\RPC Control\trick.txtpointing to
C:\Config.Msi::$INDEX_ALLOCATION(deletion of the
$INDEX_ALLOCATIONdirectory stream is similar to the deletion of the directory).
- When the callback completes, the oplock is released and the vulnerable process continues execution. The deletion of
file1.txtbecomes a deletion of
C:\Config.Msiwith your own instructions.
- Fail the installation started previously and wait for the installer to apply the rollback from your own instructions.
The creation of an Object Manager symbolic link in general is a highly suspicious endeavor especially when linked to
C:\Config.Msi::$INDEX_ALLOCATION and such actions may therefore be detected:
We have not further investigated into an exploitation variant for the Lenovo System Update vulnerability without the Object Manager symbolic link and are therefore unaware of a stealthier variant.
You may ask: Do we have to perform all these steps manually?
Answer is: No.
The Zero Day Initiative has provided another GitHub repository with a framework where such an attack is readily implemented. The specific implementation places the file
C:\Program Files\Common Files\microsoft shared\ink\HID.DLL on disk. The placed DLL hijacks the execution of the On-Screen Keyboard and allows to get a SYSTEM command prompt upon start of the Keyboard.
Using the provided implementation, the following steps allow the exploitation of CVE-2022-4568:
Prerequisites: The directory
C:\Config.Msi must not exist. If it does exist, the same vulnerability may be used to delete the directory before starting the process.
- Set up for the privilege escalation upon deletion of the
- Set up the pseudo-symlink (NTFS Junction and Object Manager symlink):
.\FolderContentsDeleteToFolderDelete.exe /target C:\Config.Msi /initial C:\TvsuSession
- Run Lenovo System Update:
.\ConfigService.exe start && .\TvsuCommandLauncher.exe 8
- Open the On-Screen Keyboard
Keep in mind, the On-Screen Keyboard DLL Hijack is well known and certainly monitored for. Such actions should usually be detected:
For a more stealthy privilege escalation, another technique should be used.
Whenever a privileged process performs operations on a user modifiable part of the filesystem, there is a potential for privilege escalation. Even if the operations performed are as small as a file deletion, the consequences may be significant.