PrintNightmare Part II – Print Spooler Remains Vulnerable Across Windows
As we reported last Wednesday, multiple proof-of-concepts recently came out showing how the Windows Print Spooler can be used to escalate privileges and remotely load code, specifically a DLL from a file share with SYSTEM level privileges. Since Wednesday there has been a number of new findings that we thought were important to share.
Editors Note: Since the publication of the patch, we’ve posted a Part III to our blog related to this vulnerability that explains how to ensure the patch protects your systems. The below information is still useful for those who can’t patch and need ways to mitigate, want to understand it better, or ways to detect the vulnerabilities usage.
Is It The Same Vulnerability As The One Patched in June?
According to Microsoft, this vulnerability is similar to CVE-2021-1675, and while it calls the same function, RpcAddPrinterDriverEx(), the attack vector and vulnerability are different. Microsoft says the defect existed prior to the June 2021 updates and was not the result of attempting to patch the earlier noted vulnerability. As such, this remote code execution component has been assigned CVE-2021-34527. This is what is formally dubbed “PrintNightmare”.
While the exploitation of this requires an attacker to be inside your network and have credentials for an authenticated user, this is still something you want to address as soon as you reasonably can, with the highest priority being placed on your Domain Controllers.
What’s Vulnerable?
Initially, we understood that Domain Controllers were fully vulnerable, and that hasn’t changed. However, client systems and members servers have been found to be vulnerable, if either of these conditions exist:
- Point and Print is enabled. You can disable it via these three registry values:
Location for Values: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint
– NoWarningNoElevationOnInstall = 0
– UpdatePromptSettings = 0
– RestrictDriverInstallationToAdministrators = 1 - If the Authenticated Users group is nested within any groups mentioned further down in this blog.
What Are My Options?
For systems that don’t need to share their printers with other systems, you can disable inbound remote printing which will prevent the system from being vulnerable.
Method 1 – Group Policy (System Admins / Enterprise)
- In the group policy editor, go to Computer Configuration > Administrative Templates > Printers.
- Look for the option Allow Print Spooler to accept client connections, double-click on it, and select Disabled.
Method 2 – Registry
This is ideal for those running Home editions of the operating system or those not on a domain or familiar with Group Policy.
- Press Win+R at the same time to launch the RUN dialog box.
- Type regedit and press Enter.
- Navigate to the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT
- Select the Windows NT key and right-click, choosing the New > Key option.
- Name the new key Printers.
- Click on the key you just created, Printers, which should appear nested under the Windows NT one.
- On the right-hand pane of the registry editor, right-click and select New > DWORD (32-bit) Value option.
- Set the new DWORD name as RegisterSpoolerRemoteRPCEndPoint and set the value to 2.
- Restart.
For systems that don’t need to print at all, you can disable the print spooler through the following methods.
For domain controllers, please be aware that if no domain controller has the print spooler running, you will manually have to delete any printers that are published to Active Directory when they are decommissioned.
Method 1 – Services Control Panel
- Press Win+R at the same time to launch the RUN dialog box.
- Type services.msc and press Enter.
- Locate the Print Spooler in the list of services and click on it.
- Right-Click and and click on Properties.
- Change Startup Type to Disabled.
- Click the Stop button if the service is currently running.
- Click on Apply, Click on OK.
- Close the Services Control Panel window.
Method 2 – PowerShell
- Open an Administrative PowerShell window. (Right-Click PowerShell and choose Open As Administrator)
- Run the following commands:
Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled - Close the Administrative PowerShell window.
For Domain Controllers or servers that must continue to host printing services, here is what you can do to monitor for the exploitation:
If you are unable to disable print services, you can enable PrintService-Operational event logging, which is not enabled by default. Follow the below steps:
- Open an Administrative PowerShell window. (Right-Click PowerShell and choose Open As Administrator)
- Run the following commands:
$logDeets = Get-LogProperties ‘Microsoft-Windows-PrintService/Operational’
$logDeets.Enabled = $true
Set-LogProperties -LogDetails $logDeets
Get-LogProperties ‘Microsoft-Windows-PrintService/Operational’ - Close the Administrative PowerShell window.
You can check the status of the log at any time by using the following command in PowerShell:
Get-LogProperties ‘Microsoft-Windows-PrintService/Operational’
You can then review this log and look for Event ID 316 which will notate additions or updates to printer drivers, which includes any malicious loads based on testing.
You can also use Process Monitor to view running processes and check the path and names of EXE’s and DLL’s loaded up.
What Else Should I Know?
The vulnerability can be given further benefit if User Account Control (UAC) is not set to notify a user when programs try to make changes. Often, this feature has been disabled by Administrators or even home users because confirming a change is seen as annoying, but it remains a viable protection mechanism. From my standpoint as a security professional, UAC should be enabled.
There are three ways to ensure UAC is enabled.
Method 1 – Registry
- Press Win+R at the same time to launch the RUN dialog box.
- Type regedit and press Enter.
- Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- Look in the right-hand pane for EnableLUA. If it has a value of 0, then the feature is turned off, change it to 1.
- Close the Registry Editor.
- Restart.
Method 2 – UAC Control Panel
- Press Win+R at the same time to launch the RUN dialog box.
- Type useraccountcontrolsettings and press Enter.
- Make sure the slider is at least set to Notify me only when apps try to make changes to my computer (default) or higher.
- Click OK.
Method 3 – Group Policy (System Admins / Enterprise)
- Navigate to Computer Configuration > Security Settings > Local Policies > Security Options
- Look for the option User Account Control: Run All Administrators in Admin Approval Mode, double-click on it and set it to Enabled.
- Review other UAC-related settings and adjust to meet your environment and risk tolerances.
There’s also one more thing that’s been mentioned by Microsoft. Checking membership in the following groups within your Active Directory Domain can help you to reduce your attack surface as another means to mitigate the risk of this, and other potential vulnerabilities. You should attempt to reduce membership as much as possible or completely empty the groups where it is appropriate. Due to legacy configurations and backwards compatibility, these groups could contain Authenticated Users or Domain Users, which would allow anyone in the domain to exploit the domain controller.
These are sensitive groups and incorrect actions could have a significant impact on your production environment or security posture. I STRONGLY recommend evaluating the usage of any accounts in these groups and documenting their membership, along with making a plan and staggering the removals so you can monitor activity and reduce potentially negative impact.
- Administrators
- Domain Controllers
- Read Only Domain Controllers
- Enterprise Read Only Domain Controllers
- Certificate Admins
- Schema Admins
- Enterprise Admins
- Group Policy Admins
- Power Users
- System Operators
- Print Operators
- Backup Operators
- RAS Servers
- Pre-Windows 2000 Compatible Access
- Network Configuration Operators Group Object
- Cryptographic Operators Group Object
- Local account and member of Administrators group
Alright, Any More Takeaways?
Honestly, yes. Many of the mitigations mentioned should likely be adopted as hardening measures for your environment to help reduce the overall attack surface and ensure those legacy configurations or poorly programmed drivers aren’t the sources of exploitation for your environment. If this tweet from one of the researchers of the vulnerability is any further proof, we have far more concerns coming for the Print Spooler.
This is not quite accurate:
“For systems that don’t need to share their printers with other systems, you can disable inbound remote printing which will prevent the system from being vulnerable.”
The issue isn’t whether or not a printer is simply shared with other systems, it is whether or not the system is acting as a print server as a means of sharing printers with other systems.
The section you are referring to is the remediation section, meant to provide general guidance as to what will help mitigate or reduce risk and the subsequent result of an action. It’s not there to qualify whether the risk inherently exists by its absense.
Christopher,
I’m trying to research more about Point and Print and how it affects our environment in relation to this CVE and the mitigations. It appears that we do not have the Registry key NoWarningNoElevationOnInstall set on endpoints. Given that, do you know if one should set the RestrictDriverInstallationToAdministrators Registry value as Microsoft recommends in this article? I mean, it probably can’t hurt, but from what I can we do not even have the PointandPrint subdirector in the Registry structure of our endpoints.
https://support.microsoft.com/en-us/topic/kb5005010-restricting-installation-of-new-printer-drivers-after-applying-the-july-6-2021-updates-31b91c02-05bc-4ada-a7ea-183b129578a7
Thanks for any guidance you might have.
John,
Good question! The RestrictDriverInstallationToAdministrators value would be a good hardening practice to avoid users from installing unsigned printer drivers to their system. This also means anyone in the Print Operators AD group will also be unable to do that moving forward on any systems its set on. Only a Domain Administrator will be able to install unsigned drivers at that point. If the keys do not exist, then you would go ahead and create them. It seems by default they aren’t created, think similar to what we have to do to enable TLS 1.1 and TLS 1.2. So with that value, and the two others Microsoft mention that help harden the Point and Print functionality are:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint
NoWarningNoElevationOnInstall = 0 (This tells the OS to show a UAC prompt to confirm, provided UAC enabled)
UpdatePromptSettings = 0 (This tells the OS to show a UAC prompt to confirm, provided UAC enabled)
RestrictDriverInstallationToAdministrators = 1 (This disables delegation and non-users from installing unsigned printer drivers)
I am hearing that privilege escalation may still be possible with these settings with the most recent patch just released, but I am waiting to do some testing and get additional confirmation. I’ll be sure to update once I have more info as far as whether the recent patch is successful.
Chris