[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:
What we do not know for sure:
for a good summary see: https://doublepulsar.com/zero-day-for-every-supported-windows-os-version-in-the-wild-printnightmare-b3fdb82f840c DetectionEnable "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 WorkaroundsAn 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]
[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675 --- |
Johannes 4473 Posts ISC Handler Jul 2nd 2021 |
Thread locked Subscribe |
Jul 2nd 2021 10 months ago |
"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. |
BeigeHat 7 Posts |
Quote |
Jun 30th 2021 10 months ago |
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? |
chasb 1 Posts |
Quote |
Jun 30th 2021 10 months ago |
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. |
Matt 4 Posts |
Quote |
Jul 1st 2021 10 months ago |
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 |
Anonymous |
Quote |
Jul 1st 2021 10 months ago |
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 |
dotBATman 70 Posts |
Quote |
Jul 2nd 2021 10 months ago |
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 |
Anonymous |
Quote |
Jul 3rd 2021 10 months ago |
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.
|
Anonymous |
Quote |
Jul 10th 2021 10 months ago |
Sign Up for Free or Log In to start participating in the conversation!