Mitigating CVE-2020-0674 With Powershell and SCCM

Happy New Year fellow SysAdmins and what a welcome it has been for us all. Zero day, after exploit, after vulnerability.

I’m sure you are no doubt patching your Microsoft systems, your Oracle, Citrix, Mozilla…oh boy. This seems to go on and on right? It is the year 2020 and this is the new norm. Red teams are poking holes in things and helping protecting enterprises at a exponential rate.

One of the most recent is the memory leak in the Javascript rendering engine for Internet Explorer, jscript.dll.

All the juicy details can be found at Microsoft’s advisory, ADV200001 at https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200001.

Powershell script

#

With that said, let’s get straight to the good stuff, that is, applying the mitigations with our friends Powershell and SCCM.

Firstly, open up your code editor of choice and plonk the following into a .ps1 file:

This script will take ownership of both the x86 and x64 bit versions of the jscript.dll as well as add the DENY access control for the group everyone.

Next, roll it up as a program into SCCM and deploy to the masses.

But once the official Microsoft security patch arrives next month, how do we undo our mitigations to restore order?

I hear ya, I see ya and I’ve got your PowerShell code right here:

Make this your uninstall program to compliment the script above and you have one complete package.

Only thing left for you is to deploy it.

SCCM Compliance method

#

While deploying the Powershell based mitigations as a program is one method, another way would be via the Compliance offerings in SCCM.

Firstly, we’ll need what the jscript file ACLs will look like after we apply our mitigations. So go ahead and perform the above Powershell script on a test workstation and do the following:

$CurrentX86Acl = Get-Acl -Path $ENV:windir\system32\jscript.dll
$CurrentX64Acl = Get-Acl -Path $ENV:windir\syswow64\jscript.dll
$CurrentX86Acl.Sddl
$CurrentX64Acl.Sddl

This will output two large hashes of the ACLs currently applied to the (now mitigated) jscript.dll file. Keep these hashes handy as we will utilize them later as part of our test.

Next, jump on over into SCCM console, hit the Asset and Compliance tab and expand Overview > Compliance Settings > Configuration Items. Once there, select Create Configuration Item.

Go through the basics of CI name, supported platforms etc…until you get to the Settings step. Here, we are going to click the New button and create a new setting of the type Script, with a data type of String. Now click through to Add Script under the Discovery script heading and this is where we will weave our Powershell magic.

In the window for our Script contents, enter in the following:

$DesiredX86Acl = "YourX86SddlHashHere"
$DesiredX64Acl = "YourX64SddlHashHere"

$CurrentX86Acl = Get-Acl -Path $ENV:windir\system32\jscript.dll
$CurrentX86Acl = $CurrentX86Acl.Sddl

$CurrentX64Acl = Get-Acl -Path $ENV:windir\syswow64\jscript.dll
$CurrentX64Acl = $CurrentX64Acl.Sddl

If (($CurrentX86Acl -eq $DesiredX86Acl) -and ($CurrentX64Acl -eq $DesiredX64Acl)) { $Compliance = "Compliant"}
Else { $Compliance = "NonCompliant" }
Return $Compliance

Remember the ACL hashes I wanted you to keep handy? Grab the values now and replace YourSddlHashHere with their contents. With the correct ACL hashes, we now have a Powershell script that compares the desired state of the jscript file, with it’s current state and returns a value of either NonCompliant or Compliant. Simple right?

Now close of the script entry window by hitting OK.

We have a script that tests for compliancy, but what the real value will come from is in the remediation. Under the Remediation script heading, click Add Script. In the script contents window, enter in contents of the first script in this post, ensure the script language is set to Windows Powershell and click OK to save and close.

Return to the Create Configuration Item Wizard and hit Next to progress to the Compliance rules section, Click on the New button to create rule and under Selected setting, chose our previously created setting. Our rule type is going to be of the Value. Finally, we are set our rule to Equals and enter a value of Compliant.

Now we have a Configuration Item that checks if the mitigation has been applied and if not, apply said mitigations. All that is left to do is create a Configuration Baseline with the newly created Configuration Item as the evaluation conditions and deploy to your workstations.

Powershell and SCCM…powerful stuff. Go forth and mitigate those security risks!