Part 1: The Basics
Hard-copy printing may feel very “old school” now, but a recent flurry of activity related to the print spooler service on Windows operating systems has brought one of the oldest IT applications back into the spotlight again. Our Talos team has a detailed discussion in their blog post titled “PrintNightmare: Here’s what you need to know and Talos’ coverage”. [1]
Microsoft’s guidance for the issue is titled “Windows Print Spooler Remote Code Execution Vulnerability”, [2] for CVE-2021-34527.
Since this vulnerability is being actively exploited, of course now is an excellent time to devote a bit of attention to figuring out where in our environments we might have this service enabled. And, of course, an Orbital search is a quick way of getting an answer to that question. In Orbital’s catalog of prebuilt queries, there’s a very convenient generic search for Windows services.
In the catalog description for this search, take note of the cautionary text:
Fortunately, the query is built to make it easy to restrict the scope with an additional parameter. Here’s how that looks.
We enter “spooler” in the “Service Name” field, and the Catalog query will automatically pick that up when it runs. (In fact, the hardest part of this entire enumeration exercise may be knowing that Microsoft Windows uses the word “spooler” as the name for the Print Spooler service.) In the results, any systems that show up with the service status “Enabled” are potential targets for this vulnerability. If the system in question doesn’t need it, then the service should be disabled. The “Principle of Least Privilege” [3] is, after all, still excellent security advice: the bad guys can’t exploit something that’s not there.
Part 2: What If Things Aren't So Simple
Ah, but what if we have an endpoint – even a high-value endpoint, like maybe a server running financial applications – that still needs to run print services, at least locally? Well, for those cases, Microsoft’s recommendation [4] is to apply a Group Policy Object (GPO) to prevent the Spooler service from accepting inbound remote printing jobs.
So, getting back to Orbital, it’s easy to check if the first mitigation option has been applied to a system; just re-run the services query above and verify that the service state is now “Disabled”. But what about the GPO setting in the second option? Can we verify that in Orbital, too?
Of course we can. All we need is the right path for a custom query against the registry, and here it is:
SELECT key as reg_key, path, name, data, datetime(mtime,"unixepoch","UTC") AS last_modified FROM registry WHERE key = "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\" AND name = "RegisterSpoolerRemoteRpcEndPoint";
Here’s what the results from one such query look like:
Notice that, for this test, we didn’t even bother with the name = "RegisterSpoolerRemoteRpcEndPoint" part. That’s because, in a typical environment, there won’t be a lot of printing-related GPOs configured in the first place. And, as you can see in the following screen capture from gpedit on our test system, “Not configured” in this case would mean that the system is, by default, willing to accept remote client connections (and therefore potentially vulnerable). The data value of “2” in our Orbital results means “Disabled”, so this confirms that the GPO mitigation has been applied here.
Reference Links
[1] https://blog.talosintelligence.com/2021/07/printnightmare-coverage.html
[2] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
[3] https://csrc.nist.gov/glossary/term/principle_of_least_privilege
[4] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527#workarounds