In a rush to be the first to publish a proof-of-concept (PoC), researchers have published a write-up and a demo exploit to demonstrate a vulnerability that has been dubbed PrintNightmare. Only to find out they had alerted the world to a new 0-day vulnerability by accident.
What happened?
In June, Microsoft patched a vulnerability in the Windows Print Spooler that was listed as CVE-2021-1675. At first it was classified as an elevation of privilege (EoP) vulnerability. Which means that someone with limited access to a system could raise their privilege level, giving them more power over the affected system. This type of vulnerability is serious, especially when it is found in a widely used service like the Windows Print Spooler. A few weeks after the patch Microsoft raised the level of seriousness to a remote code execution (RCE) vulnerability. RCE vulnerabilities allow a malicious actor to execute their code on a different machine on the same network.
As per usual, the general advice was to install the patches from Microsoft and you’re done. Fast forward another week and a researcher announced he’d found a way to exploit the vulnerability to achieve both local privilege escalation and remote code execution. This actually happens a lot when researchers reverse engineer a patch.
Only in this case it had an unexpected consequence. A different team of researchers had also found an RCE vulnerability in the Print Spooler service. They called theirs PrintNightmare and believed it was the same as CVE-2021-1675. They were working on a presentation to be held at the Black Hat security conference. But now they feared that the other team had stumbled over the same vulnerability, so they published their work, believing it was covered by the patch already released by Microsoft.
But the patch for CVE-2021-1675 didn’t seem to work against the PrintNightmare vulnerability. It appeared that PrintNightmare and CVE-2021-1675 were in fact two very similar but different vulnerabilities in the Print Spooler.
And with that, it looked as if the PrintNightmare team had, unwittingly, disclosed a new 0-day vulnerability irresponsibly. (Disclosure of vulnerabilities is considered responsible if a vendor is given enough time to issue a patch.)
Since then, some security researchers have argued that CVE-2021-1675 and PrintNightmare are the same, and others have reported that the CVE-2021-1675 patch works on some systems.
Whether they are the same or not, what is not in doubt is that there are live Windows systems where PrintNightmare cannot be patched. And unfortunately, it seems that the systems where the patch doesn’t work are Windows Domain Controllers, which is very much the worst case scenario.
PrintNightmare
The Print Spooler service is embedded in the Windows operating system and manages the printing process. It is running by default on most Windows machines, including Active Directory servers.
It handles preliminary functions of finding and loading the print driver, creating print jobs, and then ultimately printing. This service has been around “forever” and it has been a fruitful hunting ground for vulnerabilities, with many flaws being found and fixed over the years. Remember Stuxnet? Stuxnet also exploited a vulnerability in the Print Spooler service as part of the set of vulnerabilities the worm used to spread.
PrintNightmare can be triggered by an unprivileged user attempting to load a malicious driver remotely. Using the vulnerability, researchers have been able to gain SYSTEM privileges, and achieved remote code execution with the highest privileges on a fully patched system.
To exploit the flaw, attackers would first have to gain access to a network with a vulnerable machine. Although this provides some measure of protection, it is worth noting that there are underground markets where criminals can purchase this kind of access for a few dollars.
If they can secure any kind of access, they can potentially use PrintNightmare to turn a normal user into an all-powerful Domain Admin. As a Domain Admin they could then act almost with impunity, spreading ransomware, deleting backups and even disabling security software.
Mitigation
Considering the large number of machines that may be vulnerable to PrintNightmare, and that several methods to exploit the vulnerability have been published, it seems likely there will soon be malicious use-cases for this vulnerability.
There are a few things you can do until the vulnerability is patched. Microsoft will probably try to patch the vulnerability before next patch Tuesday (July 12), but until then you can:
- Disable the Print Spooler service on machines that do not need it. Please note that stopping the service without disabling may not be enough.
- For the systems that do need the Print Spooler service to be running make sure they are not exposed to the internet.
I realize the above will not be easy or even feasible in every case. For those machines that need the Print Spooler service and also need to be accessible from outside the LAN, very carefully limit and monitor access events and permissions. Also at all costs avoid running the Print Spooler service on any domain controllers.
For further measures it is good to know that the exploit works by dropping a DLL in a subdirectory under C:WindowsSystem32spooldrivers, so system administrators can create a “Deny to modify” rule for that directory and its subdirectories so that even the SYSTEM account can not place a new DLL in them.
This remains a developing situation and we will update this article if more information becomes available.
Update July 2, 2021
Microsoft acknowledged this vulnerability and it has been assigned CVE-2021-34527. In their description Microsoft also provides an extra workaround besides disabling the Print Spooler service.
Disable inbound remote printing through Group Policy
You can also configure the settings via Group Policy as follows:
- Computer Configuration / Administrative Templates / Printers
- Disable the “Allow Print Spooler to accept client connections:” policy to block remote attacks.
Impact of workaround This policy will block the remote attack vector by preventing inbound remote printing operations. The system will no longer function as a print server, but local printing to a directly attached device will still be possible.
