Microsoft fixt problemen labelprinters veroorzaakt door PrintNightmare-update

Microsoft heeft printerproblemen die veroorzaakt werden door de recente PrintNightmare-patch opgelost. Bepaalde Zebra- en Dymo-labelprinters werkten na update KB5004945 niet meer goed. De nieuwste update wordt automatisch binnen 24 uur verspreid.

Microsoft bracht in de afgelopen dagen meerdere noodupdates voor Windows 10 versie 2004, 20H2, en 21H1 uit om kwetsbaarheid CVE-2021-34527, beter bekend als de PrintNightmare-kwetsbaarheid, te verhelpen. Onder andere updates KB5003690, KB5004760 en KB5004945 werden kort na elkaar uitgebracht om de remote code execution-kwetsbaarheid via Windows' Print Spooler-functie te voorkomen. Kort daarna verschenen problemen bij het gebruik van bepaalde label- en bonnetjesprinters van in elk geval Zebra en Dymo, zo meldt Bleeping Computer. De oplossing daarvoor wordt verspreid via het Known Issue Rollback-systeem, wat tot 24 uur kan duren.

Overigens heerst er nog steeds onduidelijkheid of de PrintNightmare-kwetsbaarheid met de patch van Microsoft verholpen is. Meerdere beveiligingsonderzoekers beweren dat de exploit via de Point&Print-functionaliteit ook na het doorvoeren van de patch alsnog aanwezig is. In een blogpost stelt Microsoft gebruikers gerust; alles zou volgens de softwaregigant verder naar behoren werken en het bedrijf raadt gebruikers dan ook om de cumulatieve update KB5004945 zo snel mogelijk te installeren.

Reacties (46)

Lastige afgelopen week geweest: late informatie van Microsoft, mitigaties (Set-ACL op Sys32\Spool\Drivers), gpo's, toch weer een correctie op die GPO, KB's die voor Server2012R2 uitkwamen maar niet voor 2016, research onderzoekers uitwezen dat er om de KB heen gewerkt kon worden, etc etc. Het is onduidelijk geweest welke acties waar moesten plaatsvinden

Ik kan alleen aanbevelen in dergelijke gevallen maar 2 bronnen te vertrouwen. Dat is de vendor met kwetsbaarheden, in dit geval Microsoft, en de researchers die de kwetsbaarheden vonden en meldden, in dit geval QiAnXin. In principe is dat ook wat in de CVE belandt.
Jammer genoeg gebeurt het al te vaak dat tweedehands informatie wordt aangevuld vanuit bepaalde invalshoek of kennis, die niet altijd feitelijk correct of volledig is - en dat is heel moeilijk na te gaan.
Adequaat reageren kan ook alleen maar als je de moeite neemt om de (cvss van de) cve zelf te lezen en een impactanalyse te maken.

Beheerders die vandaag hun fabriek stil legden omdat er geen labels meer geprint konden worden, hebben dat mijns inziens dan ook vooral zichzelf te verwijten. Dergelijke (print/productie)systemen horen sowieso al voldoende geïsoleerd te zijn als preventieve mitigatie tegen allerlei viezigheid die mogelijk op andere delen van het netwerk geïntroduceerd wordt. Voor productie is je eigen Corporate LAN het wilde westen.

Updaten binnen industriële netwerken is zeker wel aan te raden (maar wordt beperkt gd aan). Je moet alleen wel eerst alles te en voor je het op de live omgeving uitrol 🙂.

Dat inderdaad. Bij van dit soort dringende last minute patches is er altijd een risico. Dat risico kan je zelf een eind beperken met gesegmenteerde uitrol en door de rest van de wereld de patch een paar dagen te laten testen. De doelstelling moet vanzelfsprekend zijn om op korte termijn helemaal up to date te zijn - zelfs op offline systemen. De impact- en risicoanalyse is de eerste en belangrijkste stap.

Bij ons was het even paniek en na veel contact met een andere umc resultaten vergeleken en patch toch breed uitgerold. Alleen USB verbonden Zebra en andere merken gingen raar doen waren het resultaat. Ik beheer zelf 700+ zebra's en moet er niet aan denken als dat uitgevallen was.

Zebra printers zijn zo lek als een mandje. Een beetje slechte software die ZPL naar de printen mag sturen en opeens zit die printen niet meer op het netwerk, of andere belangrijke configuratie is naar de knoppen omdat de input niet goed gesanitized was.
^ND2,P,1.1.1.1,255.255.255.255,1.1.1.1,1.1.1.1,N,9999,0,1

True maar wij zijn er wel afhankelijk van en je moet dan doelbewust de code's gaan sturen en met beetje kans heb je dan als werknemer toch wel een probleempje.

Mijn plan van aanpak voor servers:
1. overal waar mogelijkde Print Spooler service uitschakelen (weinig servers blijken het nodig te hebben)
2. waar Print Spooler nodig is:
2a. patchen
2b. checken dat die regkeys voor Point and Print niet bestaan
2c. waar mogelijk: inbound remote printing uitschakelen (dus enkel indien de Print Spooler lokaal gebruikt wordt)

Vergeet niet om alle werkplekken te patchen, die gebruiken precies de zelfde print spooler en zijn ook kwetsbaar. Uitschakelen van de print spooler op werkplekken is wat lastiger, ook je print to pdf gebruikt de spooler.

Precies, die werkplekken, hoe ga je daar mee om?
Mensen moeten hun prints kunnen blijven maken, PDFs moeten opgeslagen kunnen worden.
Dat kan je toch niet disablelen?
Dat is niet te doen....

Alleen printen vanuit localhost toestaan via de lokale firewall?

Alleen printen vanuit localhost toestaan via de lokale firewall?

Aan je reactie te zien, snap jij duidelijk de werking van de exploit niet.
Lees je eerst in, en geef daarna antwoord:

Printspooling op de localhost van elke cliënt connected workstation, zijn JUIST het probleem.

Je antwoord zorgt juist voor verspreiden van de exploit monitoring:
Juist die client workstation mogen juist niet meer kunnen printen in hun eigen spooler functie.

Het kan als lokale exploit ook misbruikt worden. Als het goed is heb je een antivirus / edr oplossing die er een detectie en preventie voor heeft. Al deed defender het niet zo heel goed afgelopen week.
Gelukkig is er een patch beschikbaar, ook al zijn er wat twijfels over hoe goed die werkt maakt het de exploit lastiger.

Je kunt nog monitoring inrichten Splunk heeft er een goed artikel over gemaakt https://www.splunk.com/en...tmare-cve-2021-34527.html met detectie query's.
SOC prime heeft ook rules gemaakt, https://socprime.com/blog...75-exploitation-attempts/

Dank voor je inhoudelijke reactie, ik heb nog nooit met Splunk gewerkt, dus ik ken dat niet.

Uiteraard, maar daar hebben we een apart team voor.

"2c. waar mogelijk: inbound remote printing uitschakelen"

Een bedrijf heeft z'n beveiliging dan toch uberhaupt niet in orde als dit allemaal maar gewoon open staat? Dit zijn gewoon microsoft standaard inbound firewall rules waar blijkbaar niks mee is gedaan. 😏

Kan ik bij een leek of gemiddelde consument nog begrijpen maar...

[Reactie gewijzigd door Marctraider op 10 juli 2021 11:14]

Is het niet handiger om eerst het risico voor de verschillende type servers in te schatten i.p.v. in het wilde westen de print spooler service uit te schakelen? Kan een hoop werk schelen.

Kan geen kwaad om de attack surface sowieso te verkleinen toch? Net als met het hyperthreading verhaal is ook hier de kans dat er weer nieuwe kwetsbaarheden gevonden worden. Geef het genoeg tijd

Ik ben het met je eens hoor!, maar afhankelijk van de omgeving, hoeveelheid servers en doel + mitigerende factoren/maatregelen kan er ook voor gekozen worden dat het risico (tijdelijk of blijvend) geaccepteerd wordt.

Dat is waar, soms heb je te maken met wel heel veel servers natuurlijk

Daar hebben we powershell voor.

[code]
# get your servers
$servers = Get-ADComputer -SearchBase "OU=serverOU,DC=mydomain,DC=com" -Filter *

# define some blocks we want to run on the servers
$block1 = {Get-WinEvent -LogName 'Microsoft-Windows-Printservice/Operational' -MaxEvents 10}
$block2 = {Stop-Service spooler;Set-Service -Name Spooler -StartupType Disabled}
$block3 = {Get-Service -Name Spooler | select -Property StartType, Status}

foreach ($server in $servers) {
# is the server there? otherwise don't bother
if(Test-Connection -ComputerName $server.DNSHostName -BufferSize 16 -quiet -count 2){
Write-Host ("Checking: {0}" -f $server.dnshostname)
$printevents = $null
try{
# invoke works better reaching through firewalls
# did the server do prints in the past at all?
$printevents = invoke-command -ComputerName $server.dnshostname -ScriptBlock $block1 -ErrorAction stop
}
catch{
if ($_ -match "No events were found that match the specified selection criteria."){ # no print events found, we are good to go
Write-Host ('Server OK for modification.')
$go = $true
}
else {
Write-Host ('Error: {0} in line: {1}' -f $_, $_.InvocationInfo.ScriptLineNumber)
$go = $false
}
}

if ($printevents){
$printevents
}elseif ($go){
#potential candidate, lets check the printer service
$result = Invoke-Command -ComputerName $server.dnshostname -ScriptBlock $block3
if ($result.StartType -like 'Automatic'){
Write-Host "Vulnerable system detected, stopping spooler and disabling spooler startup type..."
Invoke-Command -ComputerName $server.dnshostname -ScriptBlock $block2
}else {
Write-Host "Spooler service already disabled."
}
}else{
Write-Host "Skipped"
}
}else{
Write-Host ("Noshow: {0}" -f $server)
}
}
[/code]

Ging veel te veel tijd in kruipen. We hebben de vraag rondgestuurd. 1 reactie gekregen... Dus zijn we maar overgegaan tot disablen (met uitzondering van gekende usecases) en zien of er klachten kwamen.
Uiteindelijk had in ons geval maar 1% het nodig.

Plus dat sinds begin dit jaar onze servers ook default met een disablede printservice opgeleverd worden. PrintNightmare was niet de eerste vulnerability in de print spooler dit jaar.
Het disablen op bestaande servers stond nog op het todo lijstje. PrintNightmare heeft het enkel versneld...

Ah duidelijk verhaal, prima actie!

De “fix” heet LabelPrinterNightmare.

is de update van 2016 er nou ? zie door de bomen het bos niet meer ?

Ja, deze is 1 dag na 2012R2/2019 uitgekomen, dus in de nacht van woensdag op donderdag. In de eerste link in het artikel staat perfect per versie welke update je moet hebben.

Die is er al sinds 7 juli.

Kreeg 2 weken geleden ineens issues met een setje waar 2 zebra's via usb op lopen.
Zo'n beetje alles op los gelaten maar 1 van de machines bleef dienst weigeren.
Uiteindelijk maar een setje van een verse install voorzien met alle updates erbij waar het raar genoeg prima werkt..

alles werkt nog bij mij, LAbelwriter en HP laserjet. Eerste keer werkte inderdaad mijn dymo niet meer, kreeg inderdaad lege etiketten. Microsoft's test blijkbaar maar middelmatig

[Reactie gewijzigd door snrwo1 op 11 juli 2021 13:48]

Known issue rollback, iemand een TL;DR wat dit is? Wil dat zeggen revert patch en je bent weer kwetsbaar maar je Zebra doet het weer?

Het probleem is, als je fabriek een miljoen produkten per dag niet kan maken omdat de serienummerprinters het niet doen, dan zijn de prioriteiten gauw anders. Je kiest tussen een daadwerkelijk probleem en een mogelijk scenario, dat echter wel erger kan zijn en langer kan duren. En je redelijk omheen kan werken met dingen als poort blokades.

Dus ik snap het wel op zich. Ook werkende voor een producent. "We gooien ff alle printers uit" is niet iets dat goed gaat vallen.

Sowieso zijn die netwerken al zeer strak beveiligd vanwege het belang ervan en omdat een hoop apparatuur te oud is om nog gepatcht te worden. Sommige produktie apparatuur gaat tientallen jaren mee maar de software lang zo lang niet. Het is meestal maatwerk geweest en het bedrijf dat het gebouwd heeft bestaat allang niet meer. Dus je zal veel ouwe shit zien met een heleboel beveiliging eromheen. Niet ideaal maar het probleem compleet oplossen (met andere woorden herbouwen) is nog veel duurder.

[Reactie gewijzigd door GekkePrutser op 9 juli 2021 20:55]

Snap ik wel ik zit zelf ook regelmatig in die situatie. Het probleem is alleen dat als je het op de lange baan schuift je op een gegeven geforceerd wordt door een externe gebeurtenis om op een heel korte termijn alles om te gooien.

Stel bijv je systeem wordt gehackt door deze bug en heel je netwerk zit plotseling vol met ransomware. Dan is de schade vele malen groter dan even 1 of 2 dagen de printers eruit gooien, hoe belangrijk ze ook zijn.

Mijn ervaring is dat dit soort lekken altijd onderschat wordt en zoveel mogelijk wordt gedownplayed om niets te hoeven doen want de business. Maar over de gevolgen denkt men niet na.

Vroeger als je gehackt werd werd je servertje gebruikt om spam te versturen of een ddos aanval mee uit te voeren, dat was nog niet zo erg. Tegenwoordig wordt je gegijzeld en/of gaan ze er met je data vandoor en kan het je faillissement betekenen en dat wordt ondanks alle nieuwsberichten hierover nog altijd zwaar onderschat.

Stel bijv je systeem wordt gehackt door deze bug en heel je netwerk zit plotseling vol met ransomware. Dan is de schade vele malen groter dan even 1 of 2 dagen de printers eruit gooien, hoe belangrijk ze ook zijn.

Dat is precies de afweging waar ik op doelde. Kies je voor zekere schade nu of mogelijk veel grotere schade later.

Van ons (IT) is de focus helemaal niet op downplayen. Integendeel. Het is bij ons de business die tegenwerkt en gewoon een veto uitspreekt. Maargoed dan geven we het risico aan en proberen het zo goed mogelijk te beveiligen.

Dit. Klanten wijzen op de risico's, met enige nadruk op je expertise en ze dan zelf de keuze laten maken. Je geeft ze een duwtje in de goede richting en dan gaan ze, in de meeste gevallen, toch wel op de één of andere manier overstag. Ik merk dat bij onze klanten de bereidwilligheid om actie te ondernemen wel groter wordt, maar men vindt het met het toenemende aantal "lekken" waarvoor patches uitkomen ook wel vervelender worden. Recent nog de DNS patch en de exchange server patches. Goed, geeft de klant ook te denken over de oplossingen, veel klanten beseffen dat er een verschuiving plaats vind van wat wij als IT'ers doen. Niet meer hardware leveren, netwerkshare hier en daar, software pakketje erbij, mailservertje, maar actieve(re) rol in de continuïteit van je bedrijf wat betreft veiligheid en innovatie.

Het is niet redelijk om alleen maar uit te gaan van downplayen als men voorkeur heeft voor een bepaalde vorm van acceptabel resultaat.
Meestal is er in printen geinvesteerd omdat men het nodig heeft. Uitzetten of dat het vele bedrijfsuren en zelfs dagen niet beschikbaar is kan dus belangrijker zijn. En in een professioneel bedrijf is er dan biivoorbeeld ook al voor gezorgd dat gebruikers niet zomaar ongecontroleerd applicaties en malware kunnen laten uitvoeren en is er rekening gehouden met beperken van schade als het toch mis gaat.
Een professioneel bedrijf schuift dat niet op de lange baan. Zal er zelfs rekening mee houden dat de productie hoe dan ook dagen of veel langer niet bruikbaar kan zijn door problemen waar ze echt nauwelijks invloed op hebben, zoals een pandemie of natuurverschijnselen.

En als je vroeger gehackt werd terwijl je een snelle internetverbinding had, kreeg je 0-day films op je server als FTP. Wel jammer dat je ze niet kon zien omdat ze verborgen waren.

De vraag was wat een 'known issue rollback' is. Ik heb hier ook nooit eerder van gehoord.

Oh okee, ik dacht dat het ging om een term van zo'n fabriek zelf. Ik ook niet inderdaad (ik doe wel beheer maar niet van windows )

Known Issue Rollback heten bij microchips 'chicken bits'. Schakelaars in de nieuwste gedeeltes die een deel van de vernieuwing weer uit kunnen schakelen. In dit geval denk ik dat ze voor een setje drivers het een en ander weer voortoveren alsof er niets veranderd is. Met een beetje geluk doen ze het veilig, en gebeurt dat echt alleen voor de bestaande (bekende) drivers. Dus dat de fabrikant bij een volgende update het moet fixen. Met een beetje pech kan je door te zeggen dat je bijvoorbeeld de fabrikant 'Zebra' bent gewoon nog weer alles misbruiken.

[Reactie gewijzigd door Henk Poley op 12 juli 2021 08:45]

Onder Linux/Unix zijn er geen kerneldrivers om printers en scanners aan te sturen, dus dezelfde userspace CUPS driver werkt op alle systemen. Bovendien kun je eenvoudig de CUPS service uitschakelen of zelfs verwijderen zonder de gebruikerservaring al te zeer negatief te beïnvloeden. Hardware die geen Linuxdriver heeft, schaf ik sowieso niet aan.