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:
The presented vulnerabilities were disclosed immediately after discovery and Lenovo has remediated both vulnerabilities as of the writing of this blog post.
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.
As one of our Forensic Readiness practices, we audit Process Creation including the Command Line resulting in an Event Log entry for every started process.
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 |
---|---|
C:\DRIVERS\ThinkPad_Hybrid_USB-C_With_USB-A_Dock_MFG_Driver_V1.0.0.15\Drivers\Win10\x64\dpinst.exe dpinst.exe | lenovo_tmp_jrhlXESX |
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_V1.0.0.15
under a user lenovo_tmp_jrhlXESX
?
Let’s look at the user first.
lenovo_tmp
UserA 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.
The 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_V1.0.0.15
...
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 lenovo_tmp
user.
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 |
---|---|
c:\DRIVERS\ThinkPad_Hybrid_USB-C_With_USB-A_Dock_MFG_Driver_V1.0.0.15\DriverInstallerScript.bat /silent | lenovo_tmp_jrhlXESX |
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_V1.0.0.15\DriverInstallerScript.bat"
PS> echo "net localgroup Administrators InsertedUser /add" >> "C:\DRIVERS\ThinkPad_Hybrid_USB-C_With_USB-A_Dock_MFG_Driver_V1.0.0.15\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.
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:
The 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?
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 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 C:\Config.Msi
.
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 C:\Config.Msi
?
Ideally, we would now want to create a symbolic link from C:\TvsuSession
to 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.
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:\TvsuSession
to 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.
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:
C:\TvsuSession\folder1
.C:\TvsuSession\folder1\file1.txt
.C:\TvsuSession\folder1\file1.txt
.Tvsukernel.exe
to start the deletion of file1.txt
. This will trigger the oplock.file1.txt
elsewhere, so that C:\TvsuSession\folder1
is empty and could be deleted (directly deleting file1.txt
would require the release the oplock).C:\TvsuSession\folder1
as a junction to the \RPC Control
folder of the object namespace.\RPC Control\trick.txt
pointing to C:\Config.Msi::$INDEX_ALLOCATION
(deletion of the $INDEX_ALLOCATION
directory stream is similar to the deletion of the directory).file1.txt
becomes a deletion of C:\Config.Msi.
C:\Config.Msi
with 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.
Config.Msi
folder..\FolderOrFileDeleteToSystem.exe
.\FolderContentsDeleteToFolderDelete.exe /target C:\Config.Msi /initial C:\TvsuSession
.\ConfigService.exe start && .\TvsuCommandLauncher.exe 8
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.
CVE-2022-4568
CVE-2022-4569