Skip to content

Latest commit

 

History

History
61 lines (36 loc) · 3.17 KB

VULN-051861.md

File metadata and controls

61 lines (36 loc) · 3.17 KB

Overview

Windows Defender Application Control is designed to protect PCs against malware and other untrusted software. It prevents malicious code from running by ensuring that only approved code, that you know, can be run. WDAC allows you to control what scripts (.ps1, .vbs, and .js) may invoke on a system. WDAC is designed to prevent local administrators from tampering or bypassing its configuration.

In newer versions of Windows the scripting hosts (powershell, cscript, wscript, etc) have been "enlightened" to follow wdac and applocker rules on the system. This allows the OS and programs to invoke required/allowed scripts while preventing users from executing arbitrary scripts that don't match the WDAC policy. In essence, WDAC allows cscript.exe to run and then code within cscript.exe enforces the WDAC rule.

The Microsoft-recommended WDAC policy, even when digitally signed and with the included block rules does not protect against previous versions of cscript/wscript from being loaded onto the system and run as they are properly digitally signed microsoft binaries whose signature is trusted by the default WDAC policy.

Impact

This allows a local administrator on a system with the official and recommended policy to bypass WDAC by simply loading an old version of cscript or wscript and its corresponding digital signature catalog file onto the system. Loading a version of cscript/wscript from before "enlightenment" means that you cscript and wscript are allowed to run in their full capacity regardless of the WDAC policy. Because the file is authorized by the default policy you can then invoke any vbscript file and have full access to namespaces, etc.

Notes

cscript and wscript are not digitally signed, instead a catalog file with their signature is placed in CatRoot. As a result, you must be able to install signature catalogs to take advantage of this.

Steps to reproduce

Copying an unenlightened script host to the system can be authorized by placing its corresponding cat file in C:\Windows\System32\CatRoot

For cscript:

Download and extract the latest Windows 8.1 ISO available from Microsoft

Identify the corresponding catalog for the script host

Copy the corresponding cscript/wscript executable to the WDAC-enabled client

Copy the catalog file to the WDAC-enabled client under C:\Windows\System32\CatRoot

Create a sample script (test.js):

var r = new ActiveXObject("WScript.shell");

Expected Behavior:

C:\Users\Test User\Desktop>cscript.exe test.js
C:\Users\Test User\Desktop\test.js(3, 1) Microsoft JScript runtime error: Automation server can't create object

Actual behavior:

C:\Users\Test User\Desktop>cscript81.exe test.js
<No output (Bypassed WDAC)>

Mitigation

Use the new recommended WDAC rules which have minimum version requirements to exclude unenlightened versions of cscript, wscript, and jscript.

Timeline

July 21st - Reported

August 2nd - Microsoft begins investigation

August 4th - Microsoft communicates they will be paying a bug bounty for this report. They are considering the report as Severity: Important with Security Impact: Security Feature Bypass 

September 14th - Microsoft updates recommended block rules with the mitigation