, ,

PrintNightmare still incompletely patched - What should I do... And what shouldn't I do?

, ,

There is so very much confusion about #PrintNightmare.

And I’m not claiming to know it all; not at all! 😉
But hopefully this blog post can give kind of an overview for administrators to make mitigation decisions from.

The short version

For full explanations, see below.

  • Disable Print Spooler service on any Windows device, that does not need to print.

  • For devices, that need to do print jobs- like user workstations - but not to print on behalf of remote users: Set this in Group Policy Computer Configuration\Administrative Templates\Printers\Allow Print Spooler to accept client connections - Setting: Disabled
    (Remember to restart the Print Spooler service for this mitigation to take effect!)

  • If in any way possible: Apply the Microsoft patches and make sure Point and Print Restrictions are configured with the secure settings, and Package Point and Print - Approved Servers is configured.

  • If none of the above are options: You can consider the unofficial mitigations, like 0Patch or the “Deny-SYSTEM-in-ACL-mitigation”. But be careful not to cause outages or things breaking, especially regarding the “Deny-SYSTEM-in-ACL-mitigation”.

[UDATED JULY 19 with recommendations regarding the new attack vector: Package Point and Print connections]

[UPDATED JULY 8:
The pace at which information and knowledge is changing about this is mind-boggling…
THE GOOD NEWS:
Patches are available for all supported Windows versions
THE BAD NEWS:
The patch is incomplete, and now it turns out, that Remote Code Execution is still possible, if Point and Print Restrictions are configured for no prompts.
(And Local Privilege Escalation is still possible)

I’m updating this blog post accordingly and adding information about 0Patch as a mitigation possibilty]

[UPDATED JULY 7:
Emergency Out-of-Band patches for #PrintNightmare are finally being rolled out.
But note:
1: Not all supported Windows versions have a patch yet, but they will come soon.
2: Currently, the fix only protects against Remote Code Execution, not against the Local Privilege Escalation bug.
So, keep Print Spooler disabled on all systems, that don’t need it.
And keep the Group Policy:
Computer Configuration\Administrative Templates\Printers\Allow Print Spooler to accept client connections - Setting: Disabled
On systems that don't have to function as a print server.]

[UPDATED JULY 6: with bad news: A new attack method makes any Windows system with Print Spooler accessible vulnerable]

[UPDATED JULY 5, 17:30 CET, with notes about the suggested fix denying SYSTEM Modify permissions to the Spool\Drivers folder]

What is PrintNightmare?

I won’t start to make a write-up, which so many others have already done, and also done better than I would have been able to.

But the most important thing to know is: It is highly critical, as it can lead to complete Domain take-over, it is currently not patched by Microsoft, and PoC code is out there.




Here’s Kevin Beaumont’s write-up, if you need to understand, what the vulnerability is all about:

Zero day for every supported Windows OS version in the wild — PrintNightmare | by Kevin Beaumont | Jul, 2021 | DoublePulsar




Is it CVE-2021-1675?

Well, kinda and kinda not…

PrintNightmare has been assigned CVE-2021-34527

Here’s what Microsoft has to say about it:

Is this vulnerability related to CVE-2021-1675?

This vulnerability is similar but distinct from the vulnerability that is assigned CVE-2021-1675, which addresses a different vulnerability in RpcAddPrinterDriverEx(). The attack vector is different as well. CVE-2021-1675 was addressed by the security update released on June 8, 2021.






A flow chart to the rescue!

Stan Hegt has released a flow chart on Twitter to try to make sense of it all.

[An earlier version of this post used version 1.1. However, it’s now much more simple… And much worse]

 
 

Breaking it down

Disable Print Spooler or not?

If you don’t need to print on that workstation/server, then go ahead and disable the Print Spooler for now.

On your DCs (unless they for some reason require the Print Spooler) then definitely yes: Disable it!

However, this is not an option on most workstations and also on some servers, besides (obviously) print servers, like Citrix/RemoteApp servers.



Prevent remote print using Group Policy?

For workstations and servers like Citrix servers, you probably need the Print Spooler service running, but you don’t necesarily need to accept other remote clients printing through the local Print Spooler.

For those, you can mitigate PrintNightmare by:

  • Setting in Group Policy: Computer Configuration\Administrative Templates\Printers\Allow Print Spooler to accept client connections - Setting: Disabled

  • Restarting the Print Spooler on all servers/workstations with this GP setting. (restarting the service is required for the GP setting to take affect



What about June Patch Tuesday? Does it protect me or not?

Previously, it was thought, that under certain circumstances, the June Patch Tuesday provided mitigation.

It turns out, though, that it is only true for attacks via MS-RPRN (MS Print System Remote Protocol).

If the attack is done via MS-PAR (MS Print System Asynchronous Remote Protocol), these mitigations have no effect.

Which leaves you with the - sadly - very simple flow chart above.


So:

  • No, June Patch Tuesday will NOT protect you from PrintNightmare.

  • No, controlling Point and Print Restriction settings will NOT protect you from PrintNightmare.

  • No, controlling UAC settings will NOT protect you from PrintNightmare.

  • No, removing Authenticated Users from the Pre-Windows 2000 Compatible Access group will NOT protect you from PrintNightmare.


What about the Patches released on July 7? Do they protect me or not?

Again: It’s complicated…

Local Privilege Escalation (gaining SYSTEM account rights) is still possible.
See the next section (Suggested attack surface reduction from Microsoft) for info on bringing down the risk of lateral movement.

Remote Code Execution is prevented with the patch, IF, AND ONLY IF:
Point and Print Restrictions are not set to allow installation of printer drivers without prompts or warnings.

If Point and Print Restrictions are not set to allow installation of printer drivers without prompts or warnings:
Then July patch from Microsoft is basically useless.

Should I change Point and Print Restrictions?

Well, as always, it’s hard to give a universally correct answer to, but in general: YES!

Because, if it is set to the vulnerable state, probably it’s because you had to, in order to support some printers, that were necessary for the organization.

That being said, changing the settings to a secure configuration, should only affect users trying to install the printer or update it.
If the printer is already there on the workstation, it should continue to work fine.

So I would say, that this is a very fair trade off between security and usability.

And should you - by making this change - find out, that nothing breaks, well then you’ve just spared your organization from an insecure configuration.

How to change the vulnerable Point and Print Restrictions setting

If the "NoWarningNoElevationOnInstall" value under the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint key is set to 1 (Which makes the system vulnerable), then chances are, that it’s been configured using Group Policy.

So if you want to change it to the secure setting, I would recommend using Group Policy to configure it.

  1. Find the GPO, that configures it to the insecure setting. (Use GPResult /h or Group Policy Management Console’s Group Policy Modeling feature)

  2. Set the correct setting in a GPO, that has higher priority than the one with the insecure setting. (Or change it directly in the GPO with the insecure setting, if you think, that it will become a permanent setting)

The secure configuration is:

Computer Configuration\Administrative Templates\Printers\Point and Print Restrictions is set to Enabled and has the setting:

Security Prompts:

When installing drivers for a new connection = Show warning and elevation prompt

When updating drivers for an existing connection = Show warning and elevation prompt


New attack vector: Package Point and Print connections

New attack vectors keep surfacing.

Using Package Point and Print connections, a user could get a new print driver from a server on the internet, and could have files copied onto the computer without them being checked for correct signature; and being executed in SYSTEM context.

How to avoid?

Using Group Policy:

Configure Computer Configuration\Administrative Templates\Printers\Package Point and Print - Approved Servers

Using this GP setting, you can decide which print servers, you trust.

This will effectively put you in control.

By doing so, you don’t need to make the change, that Will Dormann suggests on kb.cert.org, in order to protect against this vulnerability… But it would still be a great idea to do it anyway:

Block outbound SMB traffic at your network boundary

The problem about this in relation to preventing the Package Point and Print vulnerability is, that you could still be vulnerable, if the [MS-WPRN] Web Point-and-Print Protocol is used instead of SMB for the attack.

But it’s still absolutely worth considering blocking SMB connections to the internet anyway!


Suggested attack surface reduction from Microsoft

Microsoft writes this under Mitigations for CVE-202134527:

“Mitigations

To reduce the attack surface and as an alternative to disabling printing, check membership and nested group membership in the groups listed below. Attempt to reduce membership as much as possible, or completely empty the groups where possible. Due to legacy configurations and backwards compatibility, some of these groups may contain Authenticated Users or Domain Users, which would allow anyone in the domain to exploit the domain controller.

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

Note: Removing members from these groups may cause other compatability problems.
”
— https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527

Will the guidance above prevent PrintNightmare from affecting me?

No 😉

This is a suggestion to attempt limit the consequences, if PrintNightmare hits your network.

Consider a scenario, where you have protected your workstations and most servers, but not your print servers.

In that case, an attacker could gain SYSTEM access to that server.

What if one the admins, who have logged on to that server, is a member of Domain Admins?

In that case Lateral Movement is made much easier for the attacker, and he could soon take over the domain.

So, it is a very good advice, not just because of PrintNightmare but just as a general recommendation to improve your security posture.

But be aware at the same time, what Microsoft says in the note:

“Removing members from these groups may cause other compatability problems.”

So, do this with caution, not in panic!
Only remove users and groups, that you positively know, have no justification for being in the group.
(And you will probably find some of those, if you have not done this in a while)



What does the “Pre-Windows 2000 Compatible Access” group have to do with it?

[ALL THE INFORMATION BELOW WAS ONLY RELEVANT WITH MS-RPRN AS THE ATTACK VECTOR. WITH MS-PAR IT IS NOW IRRELEVANT, AS CONTROLLING MEMBERSHIP OF THIS GROUP NO LONGER PROTECTS DCs AGAINST PRINTNIGHTMARE]

This WAS the problem with PrintNightmare on Domain Controllers:

Because Authenticated Users are members of the BUILTIN group Pre-Windows 2000 Compatible Access group on DCs, they will get an elevated NtQueryInformationToken while being used to compromise the system using the PrintNightmare vulnerability.

 
 

So, can’t we just remove Authenticated Users from the Pre-Win2K Compat Access group?

[UPDATE: NO, IT WILL NOT PROTECT AGAINST PRINTNIGHTMARE, AS THIS MITIGATION DOESN’T WORK, WHEN USING MS-PAR AS ATTACK VECTOR]

Probably, in many simple environments, you could successfully remove Authenticated Users from the Pre-Windows 2000 Compatible Access group, in which case the June patch would protect your DC.

And the name “Pre-Windows 2000 Compatible” does indicate, that there is no use for this group.

The Pre-Windows 2000 Compatible Access group’s original purpose was to allow NT4 machines and the like to use Active Directory.

However…

The thing is: The group has permissions all over Active Directory, and it leads to an elevated NtQueryInformationToken as depicted in the tweet above.

So how can you be sure, that nothing breaks, if you remove Authenticated Users from the Pre-Windows 2000 Compatible Access group?

  • Pre-Windows 2000 Compatible Access has been added explicitly to ACLs in the Domain

  • It is added to the Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Access this computer from the network - security policy setting in the “Default domain controller policy”

  • Some Unix-services, multifunction printers and devices alike might use it for AD queries

  • It could cause problems for ADFS installations.

  • Some Win32 apps might make use of that group for AD Queries

  • You could potentially even get issues with RemoteApps, if you remove Authenticated Users from that group

And so on.

For that reason, I would be very cautious about removing Authenticated Users from Pre-Windows 2000 Compatible Access. [UPDATE: AND BECAUSE IT WOULD ONLY PROTECT WHEN ATTACKERS USE MS-PRPN AS ATTACK VECTOR, NOT MS-PAR]

And remember: Even though it’s mentioned in the list from MS of groups to limit memberships, they do also state, that it can lead to compatibiliy issues.

Should I remove “Everyone” from Pre-Windows 2000 Compatible Access?

If you find out, that the Special Identity “Everyone” is a member alongside Authenticated Users, then your domain is running in Pre-Windows 2000 Compatible Permissions mode.

This is an insecure mode, and unless you still have NT4-systems or Unix-system that cannot authenticate to AD, you have no use for it.

In most cases, removing Everyone from the Pre-Windows 2000 Compatible Access group would be safe.
And if you are in a situation, where it would break things, you should fix the system requiring Everyone in the group and make it a priority. You shouldn’t stay in Pre-Windows 2000 Compatible Permissions mode.

But that’s just a general security recommendation again, not specific to PrintNightmare.


What about denying SYSTEM Modify permissions on the ACL of C:\Windows\System32\spool\drivers?

I have been asked about a suggested temporary fix, which denies SYSTEM Modify permissions on the the C:\Windows\System32\spool\drivers folder.

Does it work?

It should mitigate the attack.
However, @ericappelboom reports, that he succesfully compromised a system even after implementing this fix.

 
 

Should I use the ACL fix?

Using a Deny rule on the SYSTEM account naturally is a little “adventurous”. 😉

Considering it’s being questioned, whether it even fully mitigates the attack, and considering there are already reports of things breaking when implementing this fix, I would recommend using this fix, only if there is really no other option.

[UPDATE JULY 6: Now, that it’s clear, that the June Patch Tuesday combined with correct Point and Print Restriction settings and UAC settings does NOT work as mitigation, I can appreciate, why some would consider it for Print Servers, where you can’t disable Print Spooler or disallow remote print jobs.
But still: It’s not a part of Microsoft’s official recommended workarounds, it will prevent changes to the print drivers on the print server, and other issues or things breaking are very possible]

How about 0Patch’s micropatch?

I have been hesitant to even bring this up, because I have had zero experience with 0Patch in the past, and I didn’t know, what it could break.

But considering, that all this time with knowledge changing hourly and MS’s patches are incomplete, 0Patch have had a micropatch, that works and fully prevents the attack.
And it has been released for six days now, and I haven’t heard of issues.

0Patch have promised to keep the patch free at least until next Patch Tuesday, possibly even longer, if they still fail to completely patch the vulnerability.

So I have dived in and tried it out.

This is what they themselves have to say about how to get started:

“If you want to use them, create a free account at 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.”
— https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.html

I would add: Don’t install the July 7 patch, if you plan to use 0Patch!

The account creation and agent install is easy enough.

However, the patch didn’t apply on my testmachine.

0Patch-NotApplied.jpg

Turns out, the affected DLL isn’t patched, until it is loaded. 0Patch says:

When it's needed (e.g., when installing a new printer, probably also when you print), localspl.dll gets loaded, and patched by 0patch.

I was able to make it update simply by opening Devices and Printers.

But be aware of this: It is not patched, until the conditions above are met.

0Patch-Applied.jpg

The beauty of 0Patch’s approach is:

Q: What will happen with these micropatches when Microsoft issues their own fix for PrintNightmare?

First off, we absolutely recommend you do install all available security updates from original vendors.When Microsoft fixes PrintNightmare, their update will almost certainly replace localspl.dll, where the vulnerability resides, and where our micropatches are getting applied. Applying the update will therefore modify the cryptographic hash of this file, and 0patch will stop applying our micropatches to it. You won't have to do anything in 0patch (such as disabling a micropatch), this will all happen automatically by 0patch design.

You won’t be able to verify the patch by looking at the file, because patching is done in memory.

I get the same result with sigcheck before and after patching

LocalSpl.dll-Sigcheck.jpg

Should I use 0Patch’s micropatch?

Not if you can use one of the more official mitigations.

If you are considering the Deny SYSTEM ACL, I would be inclined to recommend 0Patch over denying SYSTEM Modify access, as the ACL method is known to break things, and 0Patch is currently not.

Summing up

This section has been moved to the top of the article