top of page

Old But New

An unquoted Environment Variable path in a Scheduled Task that runs as system

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.

shell-usoscan Schedule Task

Figure 1: shell-usoscan Schedule Task

%programfiles% is unquoted C:\Program Files

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.

 

Additional Detail

Applies to:

Windows 10

Reference: https://shell_usoscan_versions_windows

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:

Misconfigured ACL that allows non-Administrator users to write to C:\

Report Lineage:

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

Link:

https://blogs.msdn.microsoft.com/aaron_margosis/2014/11/14/it-rather-involved-being-on-the-other-side-of-this-airtight-hatchway-unquoted-service-paths/

The reference sent by Microsoft refers to vendors having misconfigured services. This is a Microsoft owned Scheduled Task.

About the Author

Matt is a Red Team Security Engineer at SIXGEN, Inc. conducting red team operations in support of the Department of Defense. Matt has eight years of experience in the information security field and is a veteran of the United States Marine Corps specializing in signals intelligence. Current certifications include OSCP, GREM, and CISSP.

About SIXGEN

Our team members include veterans from the world’s premier military and cybersecurity organizations. Our expert cyber operators conduct operations from mitigating threats to protecting critical infrastructure and enhancing situational awareness through rapid data solutions. Our core capabilities include: Penetration Testing, Social Engineering, Cyber Hunt, Incident Response, Red Teaming, Software Engineering, and Risk Management. Our experienced cadre of cyber professionals and our ability to understand how an adversary operates. From counterterrorism, cybersecurity to intelligence activities, we have a proven track-record to identify, dissect, and resolve complex security problems involving multi-national, interagency and commercial organizations. We provide full-spectrum cyber solutions, encompassing active, passive, and defensive techniques. As a company, we believe that cybersecurity is vital to the operational efficacy of all business, and critically important to all persons.

RECENT POSTS
ARCHIVE
FOLLOW US
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square
bottom of page