UPDATED (7/13/2023) We've built a PowerShell Worklet to remediate a workaround for CVE-2023-36884 until a patch is available. You’ll find the CVE summary (and Worklet) right under the CVE Summary Table.
July’s Patch Tuesday release from Microsoft marks a decidedly heavy month for IT admins with 129 vulnerabilities to patch, including 5 (yes, you read that right) zero-days and 9 critical vulnerabilities.
Admins will want to make quick moves on this month’s zero-days, which include a security feature bypass vulnerability in Microsoft Outlook (CVE-2023-35311) that is sure to be popular among bad actors.
In addition to the Outlook vulnerability, there are four other zero-days to prioritize this month:
CVE-2023-36884 Office and Windows HTML Remote Code Execution Vulnerability
CVE-2023-36874 Windows Error Reporting Service Elevation of Privilege Vulnerability
CVE-2023-32049 Windows SmartScreen Security Feature Bypass Vulnerability
CVE-2023-32046 Windows MSHTML Platform Elevation of Privilege Vulnerability
Also of note for those who are running Windows Routing and Remote Access Service (RRAS) on their servers are three critical remote code execution (RCE) vulnerabilities each scoring a CVSS 9.8.
Keep reading for added detail on some of the patches you’ll want to focus on this month.
Microsoft Patch Tuesday Vulnerabilities: A Brief History
UPDATE: CVE-2023-36884
Office and Windows HTML Remote Code Execution Vulnerability [IMPORTANT]
CVE-2023-36884 is an actively exploited zero-day vulnerability that currently does not have a patch. The vulnerability is being reported in various Windows and Office products. Attackers are taking advantage of the vulnerability by enticing users to open malicious Office file attachments or links, which when opened allow the attacker to perform remote code execution.
Automox has created a script for customers to remediate as a workaround until a patch is available. Note, this script was last updated on July 13, 2023, and can break functionality with Microsoft Office applications. Before deploying, please thoroughly review the Microsoft documentation referenced here.
EVALUATION CODE
# EVALUATION
Write-Verbose 'Testing registry path!'
# evaluate registry key existence
if ( !( Test-Path -Path $keyPath -PathType Container ) )
{
# append to our remediation config
$remediationConfig.KeyPath = $keyPath
Write-Verbose 'Registry path does not exist, appending to AXConfig!'
}
Write-Verbose 'Evaluating registry properties!'
# evaluate registry properties
foreach ( $prop in $props )
{
# tack on path
$prop.Path = $keyPath
Write-Verbose "Evaluating property "$( $prop.Name )" at path "$( $prop.Path )"!"
# evaluate property existence
$itemPropertyValue = Get-ItemProperty @prop -ErrorAction Ignore | Select-Object -ExpandProperty $prop.Name
if ( $itemPropertyValue -ne 1 )
{
Write-Verbose "Property "$( $prop.Name )" value is not inline with our expected configuration!"
# create the RegistryProperties Hashtable key if needed
if ( !$remediationConfig.RegistryProperties )
{
$remediationConfig.RegistryProperties = @()
}
# tack on value
$prop.Value = 1
# tack on property type
$prop.PropertyType = 'DWord'
# append to our remediation config
$remediationConfig.RegistryProperties += $prop
Write-Verbose "Appending "$( $prop.Name )" to AXConfig!"
}
}
Write-Verbose 'Registry property evaluation complete!'
Write-Verbose 'Proceeding to AXConfig exit evaluation!'
# determine if we have work to do
if ( $remediationConfig.Keys.Count -gt 0 )
{
# set the axconfig
Set-AXConfig -Name $configName -Configuration $remediationConfig
Write-Output 'The device is not inline with our desired configuration, remediation required!'
exit 1
}
else
{
Write-Output 'The device is inline with our desired configuration, exiting!'
exit 0
}
REMEDIATION CODE
# REMEDIATION
Write-Verbose 'Retrieving AXConfig!'
# retrieve the AXConfig
$remediationConfig = Get-AXConfig -Name $configName
Write-Verbose "AXConfig "$configName" retrieval $( ( 'succeeded', 'failed' )[ $null -eq $remediationConfig ] )!"
# confirm we got a config back
if ( !$remediationConfig )
{
Write-Error "Unable to retrieve an AXConfig with name $configName!"
Write-Error 'Please ensure this Worklet is scheduled to run in a policy and at least one scan has occurred!'
exit 1
}
# check if we need to create the registry key
if ( $remediationConfig.KeyPath )
{
Write-Verbose "Evaluating registry key path existence: "$( $remediationConfig.KeyPath )"!"
# forcefully create the key
New-Item -Path $remediationConfig.KeyPath -ItemType Directory -Force | Out-Null
Write-Verbose 'Registry key created successfully!'
}
# check if we need to set registry properties
if ( $remediationConfig.RegistryProperties )
{
Write-Verbose 'Proceeding to registry property evaluation!'
# iterate the properties to be created/set
foreach ( $prop in $remediationConfig.RegistryProperties )
{
Write-Verbose "Evaluating existence of registry property "$( $prop.Name )" at path "$( $prop.Path )"!"
# forcefully create the property
New-ItemProperty -Path $prop.Path -Name $prop.Name -Value $prop.Value -PropertyType $prop.PropertyType -Force | Out-Null
Write-Verbose "Registry property "$( $prop.Name )" created successfully!"
}
}
Write-Verbose 'Registry evaluation completed successfully, proceeding to exit condition evaluation!'
# check for errors & exit appropriately
if ( $Error.Count -eq 0 )
{
Write-Output 'The device is now inline with our desired configuration, exiting!'
exit 0
}
else
{
Write-Error 'The remediation failed!'
Write-Error '=============== BEGIN ERROR LOG ==============='
Write-Error $Error
Write-Error '=============== END ERROR LOG ==============='
exit 1
}
Customers can access this Worklet directly in the console here.
# EVALUATION
Write-Verbose 'Testing registry path!'
# evaluate registry key existence
if ( !( Test-Path -Path $keyPath -PathType Container ) )
{
# append to our remediation config
$remediationConfig.KeyPath = $keyPath
Write-Verbose 'Registry path does not exist, appending to AXConfig!'
}
Write-Verbose 'Evaluating registry properties!'
# evaluate registry properties
foreach ( $prop in $props )
{
# tack on path
$prop.Path = $keyPath
Write-Verbose "Evaluating property "$( $prop.Name )
" at path "$( $prop.Path )
"!"
# evaluate property existence
$itemPropertyValue = Get-ItemProperty @prop -ErrorAction Ignore | Select-Object -ExpandProperty $prop.Name
if ( $itemPropertyValue -ne 1 )
{
Write-Verbose "Property "$( $prop.Name )
" value is not inline with our expected configuration!"
# create the RegistryProperties Hashtable key if needed
if ( !$remediationConfig.RegistryProperties )
{
$remediationConfig.RegistryProperties = @()
}
# tack on value
$prop.Value = 1
# tack on property type
$prop.PropertyType = 'DWord'
# append to our remediation config
$remediationConfig.RegistryProperties += $prop
Write-Verbose "Appending "$( $prop.Name )
" to AXConfig!"
}
}
Write-Verbose 'Registry property evaluation complete!'
Write-Verbose 'Proceeding to AXConfig exit evaluation!'
# determine if we have work to do
if ( $remediationConfig.Keys.Count -gt 0 )
{
# set the axconfig
Set-AXConfig -Name $configName -Configuration $remediationConfig
Write-Output 'The device is not inline with our desired configuration, remediation required!'
exit 1
}
else
{
Write-Output 'The device is inline with our desired configuration, exiting!'
exit 0
}
REMEDIATION CODE
# REMEDIATION
Write-Verbose 'Retrieving AXConfig!'
# retrieve the AXConfig
$remediationConfig = Get-AXConfig -Name $configName
Write-Verbose "AXConfig "$configName
" retrieval $( ( 'succeeded', 'failed' )[ $null -eq $remediationConfig ] )!"
# confirm we got a config back
if ( !$remediationConfig )
{
Write-Error "Unable to retrieve an AXConfig with name $configName!"
Write-Error 'Please ensure this Worklet is scheduled to run in a policy and at least one scan has occurred!'
exit 1
}
# check if we need to create the registry key
if ( $remediationConfig.KeyPath )
{
Write-Verbose "Evaluating registry key path existence: "$( $remediationConfig.KeyPath )
"!"
# forcefully create the key
New-Item -Path $remediationConfig.KeyPath -ItemType Directory -Force | Out-Null
Write-Verbose 'Registry key created successfully!'
}
# check if we need to set registry properties
if ( $remediationConfig.RegistryProperties )
{
Write-Verbose 'Proceeding to registry property evaluation!'
# iterate the properties to be created/set
foreach ( $prop in $remediationConfig.RegistryProperties )
{
Write-Verbose "Evaluating existence of registry property "$( $prop.Name )
" at path "$( $prop.Path )
"!"
# forcefully create the property
New-ItemProperty -Path $prop.Path -Name $prop.Name -Value $prop.Value -PropertyType $prop.PropertyType -Force | Out-Null
Write-Verbose "Registry property "$( $prop.Name )
" created successfully!"
}
}
Write-Verbose 'Registry evaluation completed successfully, proceeding to exit condition evaluation!'
# check for errors & exit appropriately
if ( $Error.Count -eq 0 )
{
Write-Output 'The device is now inline with our desired configuration, exiting!'
exit 0
}
else
{
Write-Error 'The remediation failed!'
Write-Error '=============== BEGIN ERROR LOG ==============='
Write-Error $Error
Write-Error '=============== END ERROR LOG ==============='
exit 1
}
It’s important to note that if your organization uses Microsoft Defender for Office, your users are protected from attachments that attempt to exploit this vulnerability.
CVE-2023-35311
Microsoft Outlook Security Feature Bypass Vulnerability [IMPORTANT]
CVE-2023-35311 is an actively exploited zero-day vulnerability in Microsoft’s Outlook application. This vulnerability scores a CVSS 8.8 and opens the door to an attacker bypassing the Microsoft Outlook Security Notice prompt, leading to unauthorized access and/or the execution of malicious actions. In this attack scenario, the user would have to click on a unique URL to be compromised.
Because Outlook is a popular email client, the potential impact for organizations if this vulnerability is left unpatched could be severe. This vulnerability is perfect fuel for phishing and will be especially popular with criminal actors to potentially enable a ransomware or fraud event. We recommend patching within 24 hours to mitigate. – Jason Kikta, CISO/CIO
CVE-2023-35365, CVE-2023-35366, and CVE-2023-35367
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerabilities [CRITICAL]
These three CVEs all score a CVSS 9.8 and affect the Windows Routing and Remote Access Service (RRAS). In a remote code execution attack, a bad actor could target Windows servers with RRAS running.
Windows RRAS is a built-in networking component in Microsoft Windows Server operating systems that provides routing and remote access capabilities. RRAS enables computers running Windows Server to function as routers, virtual private network (VPN) servers, and dial-up servers. RRAS is not installed by default on Windows servers.
A successful attacker could modify network configurations, steal data, move to other more critical/important systems, or create additional accounts for persistent access to the device.
We recommend patching all three RRAS RCE vulnerabilities within 24 hours if you are running RRAS on your Windows servers.– Tom Bowyer, Product Security
CVE-2023-36874
Windows Error Reporting Service Elevation of Privilege Vulnerability [IMPORTANT]
CVE-2023-36874 is a zero-day elevation of privilege vulnerability affecting Windows Error Reporting (WER) service. The CVE scores a CVSS 7.8 and gives a successful attacker the means to obtain administrator privileges.
The WER service is a feature in Microsoft Windows operating systems that automatically collects and sends error reports to Microsoft when certain software crashes or encounters other types of errors. In this instance, an attacker would need to gain local machine access and the local user account would need permissions to create folders and performance traces for a successful attack.
This zero-day vulnerability is being actively exploited, so if WER is used by your organization we recommend patching within 24 hours. – Tom Bowyer, Product Security
CVE-2023-32046
Windows MSHTML Platform Elevation of Privilege Vulnerability [IMPORTANT]
CVE-2023-32046 is another zero-day elevation of privilege vulnerability that affects Windows Microsoft HTML (MSHTML) platform. The vulnerability is ranked ‘important’ and scores a CVSS 7.8. Successful exploitation allows an attacker to gain local user permissions in the affected application.
The Windows MSHTML platform, also known as Trident, is a browser rendering engine developed by Microsoft. It is used by various Microsoft products, including Internet Explorer and Microsoft Edge (versions up to and including EdgeHTML). Attackers could exploit this privilege escalation vulnerability via email, instant message, or web-based application by enticing a user to open a specially crafted file.
This vulnerability is likely lower impact, but because it’s a zero-day being actively exploited, it’s safest to patch within 24 hours. – Jason Kikta, CISO/CIO
CVE-2023-32049
Windows SmartScreen Security Feature Bypass Vulnerability [IMPORTANT]
CVE-2023-32049 is another actively exploited zero-day vulnerability with a CVSS 8.8 affecting Windows SmartScreen. A successful attack would allow a bad actor to bypass the Open File - Security Warning prompt in the Windows SmartScreen built-in security feature. Patch within 24 hours to avoid exploitation. – Tom Bowyer, Product Security
Tired of the Patch Tuesday fire drill? Automate it in 30 seconds with Automox and sleep well knowing you’re covered next month.
![](https://play.vidyard.com/n6DKdJFBNukET7Ud9bjgF7.jpg)
Start your free trial now.
Get started with Automox in no time.
By submitting this form you agree to our Master Services Agreement and Privacy Policy