CVE-2021-1675: Incomplete Patch and Leaked RCE Exploit

Published: 2021-06-30
Last Updated: 2021-07-02 11:57:15 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

[preliminary. please let us know if we missed something or made any mistakes]

Latest update from Microsoft (July 1st 2021): Microsoft assigned a new CVE to the issue: CVE-2021-34527. It also provides some mitigation techniques. See https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527

 

As part of Microsoft's June patch Tuesday, Microsoft released a patch for CVE-2021-1675. At the time, the vulnerability was considered a privilege escalation vulnerability. Microsoft considered exploitation "less likely" [1].

On June 21st, Microsoft modified the description of the vulnerability upgrading it to a remote code execution vulnerability. Earlier this week, an RCE exploit was posted to GitHub. While the exploit code was quickly removed, it had already been forked multiple times and can still easily be found on GitHub.

Further, it appears that the patch released by Microsoft on June 6th was incomplete. This exploit will work on fully patched systems, according to multiple reports. But remote exploitation requires normal user credentials [2].

A successful attack will leave the attacker with SYSTEM privileges.

What should you do:

  • Patch systems that need to run the printer spool service.
  • Disable the printer spool service where possible. You only need it on systems that share printers. You do not need it on clients that only print to shared printers.  (see user comment below)
  • Block port 445/TCP and 135/TCP at your perimeter. (that is a good idea anyway)

What we do not know for sure:

  • The effectiveness of the June patch is disputed. Some say that it may prevent the PoC from working, but there is evidence that it does not fully patch the vulnerability.
  • Are there any exploit scenarios that do not require valid user credentials?
  • Some reports indicate issues with printing after applying the June patch.

for a good summary see: https://doublepulsar.com/zero-day-for-every-supported-windows-os-version-in-the-wild-printnightmare-b3fdb82f840c

Detection

Enable "PrintService-Operational" event logging. Exploit attempts (successful or not) will trigger event ID 316. [3]

Also see this GitHub: https://github.com/LaresLLC/CVE-2021-1675

Workarounds

An interesting workaround comes from Fabio Viggiani of Truesec. The exploit relies on loading a malicious printer driver. This can be prevented by restricting access to the printer driver directory. [4]

$Path = "C:\Windows\System32\spool\drivers"

$Acl = Get-Acl $Path

$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny")

$Acl.AddAccessRule($Ar)

Set-Acl $Path $Acl

 

[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675
[2] https://twitter.com/gentilkiwi/status/1410066827590447108?s=21
[3] https://twitter.com/MalwareJake/status/1410421445608476679
[4] https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

7 comment(s)

Comments

"You do not need it on clients that only print to shared printers."
Apologies - but windows clients DO need the print spooler service to print. Just verified.
I understand that Print Spooler needs to run on at least one domain controller in order to prune stale print queue objects, as stated in this article:
https://docs.microsoft.com/en-us/windows-server/security/windows-services/security-guidelines-for-disabling-system-services-in-windows-server#print-spooler

But MS also recommends that the spooler be disabled on DCs:
https://docs.microsoft.com/en-us/defender-for-identity/cas-isp-print-spooler#what-risks-does-the-print-spooler-service-on-domain-controllers-introduce

If print spooler is disabled on all domain controllers, what method is preferred for pruning stale print queue objects?
This idea looked interesting as a temporary fix. Changing the ACL on "C:\Windows\System32\spool\drivers".
You'd need to remove it again if you want to install a printer driver but that's kinda the point, really.

https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/

Also may be worth considering changing passwords on any domain admin accounts you suspect may have touched endpoints that could then in turn be stolen. Won't stop existing valid Kerberos tickets (to my knowledge) but will at least nullify the saved credentials from being obtained and reused via mimikatz, et al.
CISA are also advising to disable the Windows Print spooler service on Domain Controllers and systems that do not print:
https://us-cert.cisa.gov/ncas/current-activity/2021/06/30/printnightmare-critical-windows-print-spooler-vulnerability
Microsoft has assigned CVE-2021-34527 to #PrintNightmare, see https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527.

Their top advice is that the June patches did not introduce this bug - do install the June patches to fix CVE-2021-1675 and then look at the workarounds they have shared; 1: Disabling print spooler (breaks even local print) or 2: Stopping inbound remote printing via GPO until they have a new update available
Here's powershell i'm using for remote, non-domain gpo policy available endpoints to disable the rpc endpoint for print spooler. Your mileage may vary...

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Write-host "Trusting PS Gallery"
Set-PSRepository -Name 'PSGallery' -InstallationPolicy Trusted

Write-Host "Installing PolicyFileEditor V3"
Install-Module -Name PolicyFileEditor -RequiredVersion 3.0.1 -Scope AllUsers -Force

Import-Module -Name PolicyFileEditor

$MachineDir = "$env:windir\system32\GroupPolicy\Machine\registry.pol"
$UserDir = "$env:windir\system32\GroupPolicy\User\registry.pol"

Write-Host "Setting `Allow Print Spooler to accept client connections` to Disabled"
$RegPath = 'Software\Policies\Microsoft\Windows NT\Printers'
$RegName = 'RegisterSpoolerRemoteRpcEndPoint'
$RegData = '2'
$RegType = 'DWord'

Set-PolicyFileEntry -Path $MachineDir -Key $RegPath -ValueName $RegName -Data $RegData -Type $RegType

# apply the new policy immediately
gpupdate.exe /force

Restart-Service -Name Spooler -Force
I understand why blocking 135/TCP is included, but I also think 139/TCP being blocked at the perimeter would make sense to mention in this situation. Since at least some of the exploits include 139/TCP as a port option, might be good to add to the block list.

Diary Archives