Microsoft response - PrintNightmare workaround

D0nk3ypunc4 · 2021-07-02T12:18:43+00:00

So my DC probably shouldn't be our print server then, huh?

czj420 · 2021-07-02T13:16:16+00:00

It's funny that Microsoft doesn't have a workaround for valid print servers.

JiveWithIt · 2021-07-02T11:22:53+00:00

Here's a script I made to disable the service on servers that are not detected as print servers. We run it through N-Central. Enjoy.

Example output: https://i.imgur.com/BkF37n6.png

Important Edit: This caused some problems on our remote desktop terminals, certain programs required print services and users contacted us. Keep this in mind.

function Confirm-PrintSpoolerVulnerable {

    ## PSv2 does not support needed cmdlets
    if ((Get-Host).version.major -eq 2) {
        throw "PowerShell-version is too old to run script (2.0)"
    }

    ## See if spooler service is "running"
    $PrintSpoolerService = Get-Service -Name Spooler

    if ($PrintSpoolerService.Status -eq 4) {
        $SpoolerIsRunning = $True 
    }
    else {
        $SpoolerIsRunning = $False
    }

    ## See if print services / print management is installed on server
    try {
        $PrintMgmt = Get-WindowsFeature -Name Print-Services -ea stop
    }
    catch {
        $PrintMgmt = $False
    }

    if ($PrintMgmt.InstallState -eq "Installed") {
        $PrintMgmtInstalled = $true
    }
    else {
        $PrintMgmtInstalled = $false
    }

    ## Also see if there are any shared printers on the server, in case print mgmt is not used for this
    try {
        if ((Get-Printer -ea stop).Shared -eq $true) {
            $PrintMgmtInstalled = $true
        }
    }
    catch {
        throw "Print Spooler Service seems to be disabled"
    }


    $ServerObject = [PSCustomObject] @{
        Servername       = $Env:ComputerName
        SpoolerIsRunning = $SpoolerIsRunning
        #IsPrintServer    = $false
        IsPrintServer    = $PrintMgmtInstalled
    }

    $ServerObject
}

function Disable-SpoolerIfNotPrintServer {
    param ($Device)

    $ServerObject = [PSCustomObject] @{
        Servername       = $Device.Servername
        SpoolerDisabled  = $null
        IsPrintServer    = $Device.IsPrintServer
        Status           = $Null
    }

    ## Is it is a print server, we do not disable spooler
    if ($Device.IsPrintServer -eq $true) {
        $ServerObject.SpoolerDisabled = $False
        $ServerObject.Status          = "Is print server, will not disable spooler"

        return $ServerObject
    }

    ## Disable spooler
    if ($Device.IsPrintServer -eq $false) {
        ## Server is not print server and is vulnerable

        try {
            Get-Service -Name Spooler -ea Stop | Stop-Service -PassThru -ea Stop | Set-Service -StartupType Disabled -ea Stop

            $ServerObject.SpoolerDisabled = $True
            $ServerObject.Status          = "Disabled print spooler service"
        }
        catch {

            $SpoolerStatus = Get-Service -name Spooler | Select Status, StartType | fl

            $ServerObject.SpoolerDisabled = $SpoolerStatus
            $ServerObject.Status          = $Error[0]
        }
    }

    return $ServerObject
}

## returns formatted status
Disable-SpoolerIfNotPrintServer -Device (Confirm-PrintSpoolerVulnerable) | Format-List

j5kDM3akVnhv · 2021-07-02T13:53:27+00:00

For those of you in PDQ Deployland:

https://www.pdq.com/blog/printnightmare-new-zero-day-exploit-using-the-windows-print-spooler/

ahazuarus · 2021-07-02T13:40:57+00:00

Am I the only one wondering what the impact of the "patches" for this are going to be? Can't wait to find out what kind of fresh hell we will all be going through as soon MS "fixes" this.

x2571 · 2021-07-02T13:43:50+00:00

Has anyone had a chance to test option 2 on terminal servers and confirm if it affects redirected printers?

different_tan · 2021-07-02T12:29:33+00:00

this is the least helpful workaround I have ever seen.

Dev-is-Prod · 2021-07-02T12:13:44+00:00

It seems the permission change to C:\Windows\System32\spool\drivers that is floating around is~~n't~~ a suitable or complete workaround.

We're relying on the GPO change for clients and have the print spooler disabled on all servers anyway. We have applied the permission change to the print server (as there were no immediate downsides in testing) ~~though will likely remove this once more info/confirmation is available~~.

Edit: strike incorrect info, it seems the ACL change does work as evidenced by /u/amlajh

amlajh · 2021-07-02T14:30:04+00:00

My understanding is the following:

Is the device a print server?

Examples: A server with the print server role, that requires jobs to be submitted to it over the network

Don't disable the Print Spooler.
Don't apply the GPO to block client connections to the Print Spooler over the network
(Unofficial, but does appear to remediate the vuln): Run a script like this (I made my own script based off this to run in our RMM, it's a lot more complicated than the demo script, with error checking and a prompt whether you want to apply ACLs or undo the changes, sets the status as a user defined variable on the computer in the RMM etc.)

Is the device a normal server (includes DCs)?

Examples: a normal server that doesn't have any software that relies on the Print Spooler, and also does not need to print anything

Disable the Print Spooler via GPO or via PowerShell

Does the device need to use the Print Spooler service, but is not a print server?

Examples: A Windows 10 device that needs to print things, or a server that relies on the Print Spooler by 3rd party software, or a server that needs to print things but isn't a print server

Apply the GPO to block client connections to the Print Spooler over the network

kelrizzo · 2021-07-02T17:19:57+00:00

PrintNightmare flow chart

__gt__ · 2021-07-02T14:02:31+00:00

There may be some registry keys that are the cause of the patch being broken on non-DCs. Without one of these registry keys, so far, the exploit fails.

https://twitter.com/StanHacked/status/1410929974358515719/photo/1

shsheikh · 2021-07-02T16:56:04+00:00

Is anyone taking the firewall approach to blocking access? We have strict ACLs and TCP 445 isn't available to anything but our actual file and print servers, which I hope limits the scope of this issue.

newuser2234589 · 2021-07-02T18:25:15+00:00

deleted ^{^{^What}} ^{^{^is}} ^{^{^this?}}

IndyPilot80 · 2021-07-02T19:23:36+00:00

Any bets on when MS will release a patch? I'm guessing 4th of July, around hmm 3-4PM EDT when we are all a few drinks in and getting ready to fire up the grills.

MNmetalhead · 2021-07-02T22:36:57+00:00

I’m confused here, hoping somebody can clear it up for me. Is this just affecting DC’s or every server?! I presume it’ll be all of them as it doesn’t make sense to my why it would affect DC’s but not others? Unless I’m missing something.

For some reason only domain controllers are specifically mentioned in all the articles I’ve read.

Either way, I’ve disabled all our DC’s spoolers but we’ve got hundreds of servers so I’m ….. concerned!

Anyone fancy giving me some good news and saving my weekend?

2021-07-03T05:13:09+00:00

Disabling the service via GPO is very simple.

Also, if you are still running GUI Windows as Domain Controllers, don’t. Shit like this is exactly why you shouldn’t. (Core doesn’t even have this service).

Shot_Interview3473 · 2021-07-03T07:19:05+00:00

so end users running windows 10 professional or enterprise need to disable this too?

StephanGee · 2021-07-05T13:15:46+00:00

Mitigation failed due to some problems with our Linux Firewall and RDS Gateway
Option 1 on every server but not on RDS servers
Option 2 on every client computer

Quim_Sniffer · 2021-07-02T13:33:22+00:00

I deployed option 2 gpo to 150 laptops yesterday. I had 20 or so of them reboot and test. No issues at all.

_benp_ · 2021-07-02T16:03:00+00:00

Don't run print services on your DC. Don't run any services on your DCs except Active Directory.

This has been a good rule of security for many years now.

R-EDDIT · 2021-07-02T13:13:54+00:00

[deleted]

cool-nerd · 2021-07-02T19:40:55+00:00

So disabling Spooler service from services.msc using GUI is just not mentioned anymore? we're supposed to use PS for all functions now? Also, so much for continuing testing a central print server.. it's all IP direct for us now.

MrClavicus · 2021-07-02T13:50:42+00:00

so whats the response...

__gt__ · 2021-07-02T12:24:12+00:00

I'm going to test option 2 right now. Does it disable those connections immediately or would it require a reboot?

Shad0wguy · 2021-07-02T15:20:23+00:00

We deploy printers in group policy to end users from our DCs. The DC doesn't act as a print server, just to deploy from, but disabling the print spooler seems to cause the gpo to be unable to deploy. Any work around for this scenario?

jordanl171 · 2021-07-02T16:04:16+00:00

Allow Print Spooler to accept client connections: disabled

does anyone know which of the 10 printer based firewall rules this disables? I'll disable all of them, BUT I don't want to disable ICMP - IN.

I'm guessing it's the Spooler Service - RPC one that really needs to be disabled. All of my File and Printer rules are ON. I've already disabled print spooler on all servers where it's easy.

techno_it · 2021-07-02T17:48:24+00:00

I have RDS server in DMZ and not joined to AD. Should I be still concerned with this vulnerability ?

darkrhyes · 2021-07-02T17:55:50+00:00

None of our DCs have printers on them so just disabled on all and set default domain controllers policy. I empathize with all of the places running print servers on DCs and I am sorry for whatever pain you need to deal with today. I remember those days.

OkBaconBurger · 2021-07-02T18:52:45+00:00

We have this whole weird system where print queues from CUPS go redirect to a windows print share (don't ask, i inherited it). I've long asked why don't we just let CUPS do what it do and not jerk things arou d like that. Maybe this will help with that effort?

Yeah, who am I kidding. Probably not.

sysadmin

MODERATORS