Unquoted paths are abused frequently on engagements. Normally an attacker would see an unquoted service path, not an unquoted schedule task path. What makes this unique is that it is an environment variable that has a space in it that allows for an attacker to abuse it. The key is, if the path is unquoted then Windows sees the space character in the path as a delimiter and will then search for program.exe instead of knowing to go to C:\Program Files\. I was surprised that an up to date Windows 10 machine would still have a vulnerability like this.
The scheduled task shell-usoscan is present when Windows 10 reports issues updating to the most recent version and uses the environment variable %programfiles% with a path that is unquoted.
Figure 1: shell-usoscan Schedule Task
Figure 2: %programfiles% is unquoted C:\Program Files
If Access Control Lists (ACLs) for C:\ allow an attacker to write to the root of C:\ the unquoted path can be used for local Privilege Escalation to SYSTEM.
Because the path is unquoted and there is a space after ”Program” even though it is using the environment variable an attacker could drop a binary called Program.exe to C:\ and get execution as SYSTEM.
Versions: 1507, 1511, 1607, 1703, 1709, 1803, and 1809 and current
Persistent System Execution
Scheduled Task: shell-usoscan
Is scheduled by default as a daily task
Requirements for vulnerability:
Misconfigured ACL that allows non-Administrator users to write to C:\
08/26/2019: Submitted to MSRC
09/03/2019: Initial response from MSRC:
MSRC closed the case and asked how it was a MITM or social engineering attack
09/10/2019: Reached back out to ask MSRC because their response didn’t make sense; informed MSRC of my intent to publish findings.
09/10/2019: MSRC reopened the ticket
09/10/2019: MSRC final response:
Will be a next version fix
This is the link provided by Microsoft as a point of reference:
The reference sent by Microsoft refers to vendors having misconfigured services. This is a Microsoft owned Scheduled Task.