Forum Discussion
PrintNightmare for administrators: Trying to sum up the current knowledge for decision-making:
Hi guys, I wrote this blog post in the hope of making it possible to make decisions on how to mitigate PrintNightmare, while waiting for an official patch from Microsoft. I hope it's useful 🙂 htt...
https://www.windowslatest.com/2021/07/14/windows-10-build-19043-1110-is-now-available-download-offline-installers/
Hello.
It is worth installing this update!
Hello.
It is worth installing this update!
In general it's always worth installing Patch Tuesday patches 😎, and it seems that for some of the supported Windows versions this patch contains patches for PrintNightmare.
But this update isn't mentioned in MS's security advisory for CVE-2021-34527, so it doesn't seem to be important specifically for PrintNightmare.
I'd say that the patches from last week are the most important ones in combination with ensuring that Point and Print Restrictions are not configured in an insecure way.
My recommendations from the latest update of my blog post are:
* 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.
* 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”.
But this update isn't mentioned in MS's security advisory for CVE-2021-34527, so it doesn't seem to be important specifically for PrintNightmare.
I'd say that the patches from last week are the most important ones in combination with ensuring that Point and Print Restrictions are not configured in an insecure way.
My recommendations from the latest update of my blog post are:
* 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.
* 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”.
Yes, but the setting that poses a threat = is human error.
But organizations often delay the update - i encourage quick deployments!
Thank you for the interesting topic!- To be honest, I kind of feel, that Microsoft's statement is a bit of a low blow: "All reports we have investigated have relied on the changing of default registry setting related to Point and Print to an insecure configuration."
They are almost implying, that some customers have "hacked" their systems to an irresponsibly insecure state.
The fact is, that nowhere in the Group Policy help text for this GP setting does it state that the setting - which Microsoft has made available in Group Policy - is frowned upon, is bad security practice or at least explained the ramifications of setting this configuration.
You will even find Microsoft documents online, that will guide you step-by-step on how to set this this insecure configuration.
Also, many enterprises will have printers, that do not have Package Aware printer drivers and have therefore set up this policy in the insecure configuration simply to make things work for their users (and been guided on how to do it through Microsoft documentation).
I do feel, that Microsoft should be willing to take partly responsibility for this instead of just "washing their hands".https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
I think the time will not go back - well, it was revealed!