System Update is an application for keeping drivers, firmwares and software packages up-to-date on Lenovo workstations or laptops. The application often comes preloaded on Lenovo systems.
Like in my previously disclosed vulnerabilities for Intel Driver & Support Assistant and Splashtop Streamer, the process of updating software and firmware can, if not implemented securely, leave a system vulnerable for privilege escalation.
CVE registered
CVE-2020-8342
Affected version
System Update 5.07.0097(latest version 04/07/2020)
Timeline
04/07/2020 – Lenovo Product Security Incident Response Team e-mailed with detailed description.
07/07/2020 - Lenovo Product Security Incident Response Team informs that they are investigating the issue.
10/07/2020 - Lenovo Product Security Incident Response Team confirms the vulnerability, given internal vulnerability number LEN-41150.
20/08/2020 - Lenovo Product Security Incident Response Team releases version 5.07.0106 of System Update which patches the vulnerability. Lenovo will disclose the vulnerability publicly September 8 2020.
Walkthrough
The System Update applications run as a low privilege executable(user interface) and a service executable running as “NT Authority/SYSTEM”. Multiple high privilege executables will be spawned by the service executable upon update. Some of these executables are native for Windows and performs temporary permission changes which allow all users to read/write to the two directories: “C:\ProgramData\Lenovo\SystemUpdate\logs” and “C:\ProgramData\Lenovo\SystemUpdate\sessionSE”. These permissions only exists for few seconds before they are reverted again.
During an update the “SUService.exe” service executable spawns “uncsetting.exe” in the user context of “NT Authority/SYSTEM”. This application checks if the directory “swwork” exists at “C:\swwork”. This directory does not exist by default.
Reverse engineering the application in Ghidra shows that the “directory check” will execute a new function “FUN_00401f00”(Ghidra autogenerated name) if the directory exists.
The function “FUN_00401f00” executes the Lenovo application “ConfigScheduledTask.exe” with the argument “createlogintask”.
Reverse engineering the application “ConfigScheduledTask.exe” showed that it accepted a range of different arguments. The argument “createlogintask” would call the function “CreateLoginOnlyScheduleTask”.
Looking at “CreateLoginOnlyScheduleTask” showed, that it would first call the function “UpdateLoginXml”. This function would copy(and overwrite if it existed) “C:\Program Files (x86)\Lenovo\System Update\TVSUUpdateTask_Login.xml” to “C:\ProgramData\Lenovo\SystemUpdate\sessionSE\TVSUUpdateTask_Login.xml”.
After performing the file copy, the application executes the native Windows schedule application “schtasks.exe” with arguments that would create a new schedule task from the schedule task XML-file “TVSUUpdateTask_Login.xml” from “C:\ProgramData\Lenovo\SystemUpdate\sessionSE”(at this time read-only file permissions).
This application logic provided us with a path to perform privilege escalation using the following steps:
Create the directory “swwork” in “C:\”
Execute System Update
System Update shortly performs permission changes to “C:\ProgramData\Lenovo\SystemUpdate\sessionSE” allowing all users to READ/WRITE to the directory and all subdirectories and files.
During this brief permission change, we overwrite “TVSUUpdateTask_Login.xml” with a malicious schedule task XML.
After overwriting the file, a file handle to “TVSUUpdateTask_Login.xml” is called, allowing other processes to only read the file. This successfully denies “ConfigScheduledTask.exe” the ability to copy and overwrite the real XML file to “C:\ProgramData\Lenovo\SystemUpdate\sessionSE”.
Copy/overwrite fails, but “ConfigScheduledTask.exe” continues and loads the malicious schedule task XML-file.
The malicious schedule task executes our payload as “NT Authority/SYSTEM” giving us a successfully escalation of privilege.
Proof-of-concept
A proof-of-concept application below automates the different steps and forces System Update to load “payload.xml” into scheduled tasks.
