PrintNightmare Print Spooler Exploit

Es ist nicht das erste mal, dass der Windows Spooler als Einfallstor eines Angriffs genutzt wird. Ein im Sommer 2021 entdeckter Bug wurde von Microsoft mit einem Update am 2. Juni zwar gefixt, aber eine zweite Lücke ist dabei nicht geschlossen wurde. Anscheinend wurde aber diese Lücke bei einer Präsentation zur Black Hat 2021-Konferenz im August schon beschrieben und hat so den Weg in die Freiheit gefunden und wird ausgenutzt. Es gibt mehrere Lücken:

Dokument wird regelmäßig aktualisiert

Update: 6.7.2021. Security Updates verfügbar
Siehe auch https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527

Update 13. Jul 2021: Weitere Updates im Jul Patchday

Update 15. Jul 2021: Weitere Lücke CVE-2021-34481 Windows Print Spooler Elevation of Privilege Vulnerability
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34481

Lücke Status Beschreibung

CVE-2021-1675

Fix 8 Juni 2021

Fixes verfügbar für Windows Server 2008, 2012, 2012R2, 2016, 2019, Windows 7, 8.1, Windows 10
CVE-2021-34527
PrintNightmare

6./7. Juli Fix verfügbar

Am 6. Jul wurden Updates für neuere Windows 10, Server 2019 und sogar Server 2008/R2released
Am 7. Jul folgte dann Windows 2016, 2012/R2 und ältere Windows 10 Versionen

Angeblich sind die Updates aber nicht 100%. Es kann wohl immer noch an einer falschen Konfiguration liegen.

 CVE-2021-34481

15. Jul

 CVE-2021-34481 Windows Print Spooler Elevation of Privilege Vulnerability

Bitte beachten Sie das Diagramm auf "Microsoft Windows Print Spooler RpcAddPrinterDriverEx() function allows for RCE"
https://www.kb.cert.org/vuls/id/383432

Ich gehe davon aus, dass die Lücke auch im Spooler-Dienst von Windows XP und Windows Server 2003 und Vorgängerversionen vorhanden ist. Diese werden aber nicht mehr gepatched. Ich bin positiv überrascht, dass Microsoft auch Windows 2008/Windows 7 (erweitertes Supportende war 14. Jan 2020) berücksichtigt hat. Hoffen wir, dass dies bei CVE-2021-34527 auch der Fall ist. Dennoch sollten sie nicht darauf vertrauen, dass dies für alle zukünftigen Bugs der Fall ist.

Der einzige Vorteil dabei ist, dass der Angriff im Gegensatz zum Hafnium: Exploit nicht anonym und in der Regel nicht über Internet möglich ist. Der Täter schon in ihrem internen LAN sein. Aber auch das ist in Zeiten von Kennwort Phishing und Zugang per RDP/VPN ohne zweiten Faktor sehr oft möglich.

Das kann passieren!

Die Lücke ist durch jeder authentifizierte Konto in ihrem Netzwerk gegen einen Windows Server mit aktiven Druckserver (also alle) ausnutzbar. Die Lücke steckt in der Funktion "RpcAddPrinterDriverEx()", über welche ein authentifizierter Benutzer einen Treiber auf dem Server addieren kann.

Bitte fragen sie mich bitte nicht, warum ein Anwender auf einem Server einen Treiber addieren kann und dies nicht auf "Print Operator" und "Administrator" beschränkt ist. Wahrscheinlich ein historischen "Plug and Play"-Feature um den Administrator zu entlasten.

Diese Funktion kann leider nicht individuell abgeschaltet werden. Dieser Treiber muss kein Druckertreiber sein, sondern kann als SYSTEM beliebige Funktionen ausführen, z.B.

  • Benutzer zum Domänen Administrator addieren
    So kann sich ein Angreifer "hochstufen" um das gesamte Netzwerk zu übernehmen. Dazu muss er nur den Domain Controller erreichen. Daher steht der Schutz der Domaincontroller an erster stelle. Domain Controller sollten sowieso keine "Druckserver" sein, so dass die Aktionen relativ risikolos umgesetzt werden können.
  • Admin eines Server oder Workstation werden
    Auch wenn der DC geschützt ist, kann der Angreifer sich dann zum Administrator eines Mitgliedsservers oder eines Clients machen. Local Admin auf einem Exchange Server oder SQL-Server dürfte den verantwortlichen Personen auch schlaflose Nächte bereiten
  • Schadsoftware aufrufen
    Also Programm auf dem System kann er dann Logs auslesen, Keylogger-Funktionen nutzen, verschlüsseln, das System fernsteuern etc. Es kommt nun drauf an, wie der Angreifer arbeitet. Will er sich gleich offen zeigen oder nutzt er die Rechte erst einmal zum Ausspähen und Daten sammeln.

Es gibt bereits eine Schadsoftware, d.h. der Angriff ist nicht "theoretisch"
Es ist davon auszugehen, dass Angreifer die Zeit nutzen, um in möglichst vielen Netzwerk sich höhere Privilegien zu verschaffen, in denen sie aktuell "nur" Domain Benutzer sind.

Warnung des BSI
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-233732-1032.pdf?__blob=publicationFile

Betroffene Systeme und deren Schutz

Ich unterteile die Systeme in folgende Klassen:

System Option 1 Option 2 Beschreibung

Desktops

Ja

Nein

Hier können Sie den Spooler nicht stoppen, weil sonst die Anwender nicht mehr drucken können. Aber ein Desktop ist in der Regel nicht selbst "Druckerserver", damit andere PCs über diesen Desktop einen lokalen Drucker ansteuern. Insofern ist es möglich hier über Gruppenrichtlinien die Erreichbarkeit des Spoolers zu unterbinden.

Die meisten Drucker haben heute ja einen direkten Netzwerkanschluss und der Anwender kann unter Windows die Drucker in der Regel finden und selbst einrichten.

DruckServer

Nein

Nein

Wenn ihre Clients nicht selbst direkt zum Drucker ausdrucken, sondern ein zentraler Druckserver die Aufträge in einer Warteschlange verwaltet und die Treiber und Einstellungen bereitstellt, dann haben Sie einen gefährdeten Druckserver. Sie können die Schnittstelle nicht einfach unterbinden.

Tipp: Aktivieren Sie die Protokollierung, um Angriffe gemeldet zu bekommen und sorgen sie dafür, dass der Server nur die Drucker erreicht und nicht als Sprungbrett zu anderen Servern missbraucht werden kann. Vor allem melden sie sich nicht mit Domain-Admin-Berechtigungen an, die ansonsten ein Trojaner abgreifen könnte. Bis zum Fix ist ein lokaler Admin die bessere Wahl. Dennoch bleibt ein ungutes Gefühl.

Member Server

Ja

Ja

Ich habe schon ewig nicht mehr etwas direkt von einem Server ausgedruckt. Ich vermeide es sogar auf einem Server entsprechende Drucker einzurichten. Insofern habe ich auch kein Problem damit, den Spooler-Dienst zu beenden und zu deaktivieren. Das verhindert auch zukünftige Exploits und spart etwas Speicher. Leider kann der Druckdienst nicht als Windows Feature deinstalliert werden.

Es kann aber Server geben, die z.B. zur Druckaufbereitung, PDF-Konvertierung, Faxserver etc. doch den Spooler brauchen. Dann ist Option 1 besser

Domain Controller

Ja

Ja

SYSTEM auf einem Domain Controller ist ein Hauptgewinn für Angreifer. Daher sollten sie auf jeden Fall eine der beiden Optionen umsetzen. Ich würde sogar den Spooler deaktivieren, wenn Sie vom DC aus nicht drucken wollen, um auch zukünftig geschützt zu sein.

Ich hoffe, dass sie nicht einen DomainController haben, der zugleich Druckserver ist. Dann würde ich überlegen, diese Funktion schnell auf zwei Server zu trennen.

Schutz (Option 1)

Diese Option ist für Systeme, die selbst weiter drucken müssen aber keine Serverdienste im Netzwerk anbieten, d.h. eigentlich alle Clients und Server die kein Druckserver sind.

Microsoft stellt bis zur Verfügbarkeit eines Patches zwei Workarounds vor, die beide den Spoolerdienst in der ein oder anderen Weise einschränken. Der Angriff erfolgt "über das Netzwerk" und daher finde ich den Weg, diese Nutzung zu unterbinden, ideal für alle Systeme, die selbst kein Druckserver sind. Das können Sie per Gruppenrichtlinie in wenigen Minuten umsetzen.

Legen sie eine neue Gruppenrichtlinie an und stellen Sie die Option " Allow Print Spooler to accept client connections" auf Disabled

Das System kann dann noch selbst drucken aber ist kein Druckserver mehr. Das Risiko einer Störung ist minimal bis nicht vorhanden. Die Einstellung ist natürlich nicht für "Druckserver" geeignet, die von Clients angesprochen werden. Hier der Pfad und das Bild:

Computer Configuration / Administrative Templates / Printers / Allow Print Spooler to accept client connections = Diabled

Am besten legen Sie eine eigene Gruppenrichtlinie dafür an, die Sie auf die Domäne binden und dann ihre Druckserver davon ausschließen. Nach der Installation eines Patches könnten Sie die Änderung dann auch schnell wieder rückgängig machen. Die Einstellung addiert in der Registrierung folgenden Schlüssel:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers]
"RegisterSpoolerRemoteRpcEndPoint"=dword:00000002

Tipp: Wenn nichts passiert ist, dann würde ich die Richtlinie einfach aktiv lassen, denn sie sichert auch Clients gegen missbräuchliche Nutzung der dort installierten lokalen Drucker ab. Eigentlich sollte das sogar der neue "Default" sein

Schutz (Option 2)

Diese Option ist für Systeme die in der Regel überhaupt keine Druckfunktion benötigen

Der zweite Lösungsweg, den Microsoft sogar an erster Stelle sieht, ist die komplette Deaktivierung des Spooler-Diensts. Ich denke dass diese Anleitung zuerst dokumentiert wurde, ehe die etwas abgeschwächte Version über die Gruppenrichtlinie getestet und nachgereicht wurde.

Auch wenn mir diese Holzhammer-Methode weniger zusagt, ist sie für Systeme interessant die weder Druckserver sind noch auf denen selbst gedruckt wird. Wann haben Sie als Administrator auf einem Domain Controller, Exchange-Server, SQL-Server, WSUS-Server, Dateiserver das letzte Mal gedruckt? Aus meiner Sicht ist dies nicht mal ein temporärer Fix sondern kann als dauerhafte Lösung auf Servern genutzt werden, die weder Druckerserver sein sollen noch selbst drucken. Prüfen sie aber ob Anwendungssoftware damit umgehen kann, dass es keinen Spooler gibt.

Daher kann es auch als präventiven Schutz für zukünftige Lücken angeraten sein, auf solchen Systemen den Spooler-Dienst komplett zu stoppen und auf Dauer zu deaktivieren. Nebenbei sparen Sie sich etwas Hauptspeicher, was aber hier nicht das Ziel ist. Leider ist der Druck-Dienst keine eigene Rolle oder ein Feature in Windows und kann nicht separat deinstalliert werden.

Sie können per PowerShell, Gruppenrichtlinie etc. auf allen Systemen den Druckserver komplett beenden und deaktivieren, bis ein Patch zur Verfügung steht. Dies ist durchaus möglich, denn gerade viele Windows Server sind gar keine Druckserver oder drucken nicht selbst. Es könnte sogar dazu führen, dass Sie auf solchen Servern den Druckdienst auch nach einem Patch gar nicht mehr starten wollen um Speicher zu sparen aber vor allem einen zukünftigen Angriffsvektor zu vermeiden.

# Manelle Deaktivierung auf einem System
Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

Diese Befehle können Sie als Administrator natürlich auch gegen viele Server ausführen.

WWählen Sie den Filter bei Get-ADComputer mit Bedacht, denn ohne Spooler können Sie auch nicht mehr lokal drucken. Diese Methode ist nur etwas zum Schutz von Servern, die selbst auch nicht drucken. Vorsicht z.B. bei Druckservern.

foreach ($adcomputer in (Get-ADComputer -filter *)) {
   Invoke-Command `
      -ComputerName $adcomputer.Name `
      -ScriptBlock { 
                       Stop-Service -Name Spooler -Force 
                       Set-Service -Name Spooler -StartupType Disabled 
                   } 
}

Schutz des Druckservers

Wenn Sie aber noch einen Druckserver betreiben, dann wird es knifflig. Bei der Umsetzung einer der beiden Maßnahmen ist kein Druck über das Netzwerk mehr möglich. Das betrifft nicht lokal angeschlossen Drucker beim Anwender, z.B. im Home Office. Aber in Firmen müssen natürlich weiter Lieferscheine, Rechnungen u.ä. gedruckt werden. Bis zur Installation eines Updates können Sie aber versuchen den Server "weniger erreichbar" zu machen.

Wenn Sie z.B. Server und Clients voneinander in verschiedenen Subnetzen getrennt haben, könnten Sie über den Router oder die Firewall die IP-Adresse des weiterhin verletzbaren Servers filtern, so dass übergangsweise nur vertrauenswürdige Systeme den Druckdienst nutzen können. Oft reicht dies, um die wichtigen Druckvorgänge vom ERP-System über den Spooler weiter zu bedienen.

Es bleibt hier ein Restrisiko und der Weg ist auch nicht von Microsoft beschrieben.

Denkbar ist auch ein Filter auf dem Server selbst über die Windows Firewall:

Sie sind aber weiterhin im Risiko, dass ein Client diesen Server erreicht und die Lücke ausnutzt. Eine strenge Überwachung des Servers ist erforderlich, bis ein Patch installiert ist.

Dies ist aus meiner Sicht keine Lösung, wenn der Server ein Domain Controller ist. DCs können sie schlecht abschirmen und ein gelungener Angriff kompromittiert ihr Netzwerk. In dem Fall würde ich entweder die Druck-Server-Funktion auf einen anderen Server umziehen oder einen neuen Server als zusätzlichen DC bereitstellen, ehe sie dann diesen DC zum reinen Druckserver herunterstufen.

Angriffe erkennen

Windows kann durchaus dazu gebracht werden, gewisse Aktivitäten auch im Eventlog zu protokollieren. Leider sind die meisten Protokolle nicht aktiv. Wenn sie einen Druckserver weiter betreiben müssen, dann sollten Sie das Logging dazu aber aktivieren. Das geht per GUI im Eventlgviewer:

Die Aktion kann auch per PowerShell durchgeführt werden:

# Anzeige des Status
(Get-LogProperties "Microsoft-Windows-PrintService/Operational").enabled

# Logging aktivieren
$log= Get-LogProperties "Microsoft-Windows-PrintService/Operational"
$log.enabled = $true
Set-LogProperties -LogDetails $log

# Kontrolle des Status
(Get-LogProperties "Microsoft-Windows-PrintService/Operational").enabled

Alternativ können Sie auch .NET -Klassen bedienen:

Quelle: https://twitter.com/NathanMcNulty/status/1410290904049479680 
$log = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration "Microsoft-Windows-PrintService/Operational" 
$log.IsEnabled = $true
$log.SaveChanges()

Mit dem aktivieren Logging können Sie dann zwar nicht "genau" den Angriff erkennen aber im Eventlog landen dann Meldungen zum das Hinzufügen von Druckertreibern. So können Sie dann über ein Alarmierungssystem erkennen, dass ein Angriff erfolgt ist. Relevant sind die folgenden Events.

EventID Beschreibung und Links

316

Druckertreiber wurde addiert.

Das Sample installiert angeblich einen Druckertreiber "123" aber der Name kann sich natürlich ändern.

Normalweise ist die Drucker-Konfiguration auf einem Printserver ziemlich statisch und wird nur von Druck-Administratoren geändert. Hier sollten sie also hellhörig werden.

808

 Quelle: https://twitter.com/msandbu/status/1410294024838299657
Event habe ich selbst noch nicht gesehen

31017

 Quelle: https://twitter.com/msandbu/status/1410294024838299657
Event habe ich selbst noch nicht gesehen

Wenn Sie weitere Produkte im Einsatz haben, die z.B. den Start von Prozessen überwachen können, dann gibt es hier vielleicht auch noch Ansatzmöglichkeiten unerwünschten Code zu erkennen oder sogar zu blockieren.

Nachträglich kontrollieren?

Es werden wieder Administratoren erst nach bereits erfolgtem Angriff sich um ihre Systeme kümmern können und dann war das Logging natürlich noch nicht eingeschaltet. Was die Malware letztlich gemacht hat, kann niemand mit Sicherheit sagen. Auch beim Hafnium Exploit hat sich die ursprüngliche Malware sehr schnell verändert. Überlegen Sie, was sie als "SYSTEM" auf dem Server alles anstellen können. Der Spooler schreibt per Default keine Logfiles wie ein Webserver und nach der Kaperung könnte ein Angreifer auch die Spuren verwischen, wenn Sie diese nicht durch ein SIEM oder Log-Management in Echtzeit ausleiten. Wenn der Angreifer nicht sofort einen sichtbaren Schaden verursacht hat,  dann Insofern sind die Prüfpunkte, wie so oft:

  • Mitglieder bzw. Last Modified von Privilegierten Gruppen
    Wenn der Angreifer sich zum Admin machen will, dann addiert er sich in Gruppen. Dies kann in einem Auditing auffallen und geprüft werden. Dies sollten Sie regelmäßig wiederholen. Dies kann sehr gut per Skript automatisiert werden, z.B. im Rahmen eines Monitoring.
  • Neue Dateien/unbekannte Dienste/geplante Tasks
    Sie können sich dabei aber nicht auf das "Last Modified"-Datum der Dateien verlassen, denn die kann der Angreifer zurückdatieren.
    Es könnte ja sein, dass er sich erst später zum Admin machen will
  • Bekannte Malware
    Ein Virenscanner auf allen Systemen sollte Standard sein. Nur so kann zumindest bekannte Malware erkannt und blockiert werden. Auch wenn die aktuellste Malware vielleicht nicht gleich erkannt wird, könnte sie ein paar Tage später auffallen.
  • Remote Zugriff / Anmeldungen überwachen
    Der Angriff geht nur von intern mit einem Benutzernamen. Selbst wenn alle Mitarbeiter vertrauenswürdig sind ist das kein Schutz, denn allzu oft haben Angreifer schon gültige Zugangsdaten von Anwendern auf Vorrat und warten nur auf so eine Change, um sich dann per VPN oder RDP anzumelden und zuzuschlagen. Eine Protokollierung der Anmeldungen kann Spuren sichern und vielleicht können Sie für eine Zeit den externen Zugang minimieren.
  • YARA/Sigma und Co
    Security Scanner, Virenscanner und SIEM-Systeme können erkennen, wenn der Spooler-Dienst eine Datei schreibt, die kein Druckjob ist. Laut einer Sigma-Regel (https://GitHub.com/SigmaHQ/sigma/pull/1588/files) verrät sich sein Angriff durch einen Schreibzugriff auf "C:\Windows\System32\spool\drivers\x64\3\old\1\123". Ich habe noch nicht versucht, Diesen Pfad mit einem "DENY:SYSTEM anzulegen. Aber sicher wär das auch wohl nicht.

Weitere Informationen habe ich auf Hafnium Nachbereitung und Firmen werden gehackt skizziert. Allerdings sind Verallgemeinerungen schlecht möglich. Eine Firma braucht eine maßgeschneiderte Lösung, basierend auf einer Risikobewertung und der Möglichkeiten diese auch zu betreiben.

Spooler-Bugs

Leider ist der Spooler ein Dienst, der schon häufiger durch Nachlässigkeit bei der Überprüfung aufgefallen ist. Umso wichtiger ist es, dass Sie diesen Vorfall mal wieder zum Anlass nehme, generell über das "Drucken" nachzudenken. Viele Firmen nutzen Drucker schon unabhängig von einem Server, z.B. im Home Office oder haben wenige dedizierte Druckserver auserkoren. Damit sollte der Spooler-Dienst auf den anderen Systemen entsprechend ohne "Serverfunktion" konfiguriert werden, wie ich dies oben als zweite Option beschrieben habe. Es wird sicher nicht die letzte Lücke einer Komponente sein, die schon lange in Windows immer wieder mitgeführt wird.

Insofern ist eine Beschränkung des Einsatzes des Windows Spoolers auf weniger Server durchaus eine generell gute Idee

Weitere Links