PrintNightmare, The zero-day hole in Windows – here’s what to do

Breaking in and taking over

As you probably know, EoP means that someone who has already compromised your computer, but is stuck with the sort of access that you would have yourself when logged on as a regular user, can promote themselves to a more privileged account without needing to know the password for that account.

That’s bad enough, but RCE refers to a bug by which cybercriminals can break into your computer in the first place, without needing any password for any account on your computer.

If an RCE bug also permits EoP, then that’s even worse, because it essentially combines breaking in and taking over into a single, high-drama security hole.

Of course, the upgrade in the severity of CVE-2021-1675 from EoP to RCE didn’t matter – or so everyone thought – as long as you’d already applied the Patch Tuesday update.

After all, closing a security hole protects you whether that hole is an EoP, an RCE, or both.

Not all bugs created equal

Apparently, what happened next was an unfortunate publication mistake.

Researchers from the cybersecurity company Sangfor, who were preparing to present a paper on Print Spooler bugs at a forthcoming Black Hat conference in August 2021, seem to have decided that it would be safe to disclose their proof-of-concept work earlier than intended.

After all, what harm in discussing and demonstrating the Print Spooler RCE-and-EoP bug openly, given that it was now publicly documented and had been patched two weeks earlier?

You can probably guess where this is going.

It seems that the newly-disclosed Print Spooler bug discovered the Sangfor researchers wasn’t actually the same security hole that was fixed on Patch Tuesday.

In short, the Sangfor crew inadvertently documented an as-yet-undisclosed RCE bug, thus unintentionally unleashing a zero-day exploit.

The researchers apparently took down the offending information once the mistake was figured out…

…but by then it was too late, because the exploit code had already been downloaded and republished elsewhere.

Pandora’s jar had already been opened, and it was too late to close it up again.

The new-and-unpatched bug is now widely being described by the nickname PrintNightmare.

It’s a Windows Print Spooler Remote Code Execution Vulnerability, just like CVE-2021-1675, but it’s not prevented by the latest Patch Tuesday update.

Indeed, several independent researchers have published screenshots on Twitter showing the new exploit succeeeding on a Windows server that already has Microsoft’s June 2021 patches installed.

What to do?

There’s no official patch yet [2021-06-30T21:00Z].

We’re assuming that a fix will be released by Microsoft as soon as possible – perhaps even before next month’s Patch Tuesday updates are scheduled to arrive (12 July 2021), if a reliable patch can be created in time.

Watch out for a patch and deploy it as soon as you can once it’s out.

Until then, it looks as though disabling the Print Spooler on vulnerable computers is a satisfactory workaround.

If you have servers where you absolutely have to leave the Print Spooler running, we suggest that you limit network access to those servers as strictly as you can, even if it means that some of your users experience temporary inconvenience.

If you have servers where the Print Spooler is running but is not in fact necessary, turn it off and leave it off even after the patch comes out for this bug, on the principle of not exposing a larger attack surface than you need to.

Also, watch this space – more news as we have it!

PS. While you’re about it, please make sure that you have correctly installed the CVE-2021-1675 fix that came out on Patch Tuesday. There’s not much point in chasing after this new RCE bug for which there isn’t yet a patch if you are still exposed to the old RCE bug that does have a patch!

CHECKING THE PRINT SPOOLER ON YOUR OWN COMPUTER

To see if the Spooler service is running on your computer, you can use the Windows SC (Service Control) command from a command prompt window, e.g.

C:\Users\duck>sc query Spooler

SERVICE_NAME: Spooler
        TYPE               : 110  WIN32_OWN_PROCESS  (interactive)
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

You can prevent the spooler starting by itself, even after a reboot, with:

C:\Users\duck>sc config Spooler start= disabled

Note that you mustn’t put a space between the word start and the = character, but you do need a space between the = sign and the word disabled. You need to start your command prompt window (CMD.EXE) as Administrator to reconfigure services.

Reboot and you should see this:

C:\Users\duck>>sc query Spooler

SERVICE_NAME: Spooler
        TYPE               : 110  WIN32_OWN_PROCESS  (interactive)
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 1077  (0x435)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

If you are interested in knowing where the Service Control Manager stores the configuration data for your Windows services, you can use the REGEDIT program (don’t change anything unless you are sure what you are doing).

You will find the Spooler service data in the registry key HKEY_LOCAL_MACHINE\SYSTEM\​CurrentControlSet\​Services\Spooler. The registry value Start determines how and when the service will start up:

0 = start at bootup (used for drivers without which the system can’t start at all, e.g. disk drivers); 1 = start while Windows is loading (used for drivers that need to be ready during Windows initialisation); 2 = start automatically once the Windows System Control Manager software is running; 3 = start only when explicitly requested (e.g. using sc start command); 4 = disabled (refuse to start even if asked).

LISTEN NOW: UNDERSTANDING VULNERABILITIES

Learn more about vulnerabilities, how they work, and how to defend against them.
Recorded in 2013, this podcast is still an excellent and jargon-free explainer of this vital topic.