[English]Sicherheitsforscher haben Proof-of-Concept-Code (PoC) für eine Remotecode Execution-Schwachstelle (REC) im Windows Print Spooler veröffentlich. Der POC-Code wurde zwar sofort wieder gelöscht, es ist aber davon auszugehen, dass Kopien gezogen wurden. Über die Schwachstelle CVE-2021-1675 ist es möglich, dass ein Angreifer Remote-Zugriff auf einen Windows Domain Controller erlangen und diesen übernehmen kann.
Anzeige
Schwachstelle CVE-2021-1675 und der POC
Ich bin erstmals über nachfolgenden Tweet auf den Sachverhalt gestoßen, der genauer in diesem Artikel beschrieben wird.
Der Sachverhalt ist schnell beschrieben: Laut Tenable veröffentlichten Ende Juni 2021 zwei verschiedene Forschungsteams Informationen zu CVE-2021-1675. Es handelt sich um eine RCE-Schwachstelle (Remote Code Execution) im Windows Print Spooler, die als PrintNightmare bekannt ist.
Schwachstelle im Juni 2021 nur teilweise gepatcht
Als die Schwachstelle ursprünglich beim Juni 2021-Patchday bekannt gegeben und durch ein Juni 2021-Update geschlossen wurde, galt noch ein geringer Schweregrad – denn es war nur eine lokale Code-Execution mit der Möglichkeit, erhöhte Berechtigungen zu bekommen, bekannt. Am 21. Juni 2021 wurde der Bedrohungsgrad jedoch auf Kritisch erhöht, da eine Remote Code Execution (RCE) möglich ist. Die Entdeckung wurde Zhipeng Huo vom Tencent Security Xuanwu Lab, Piotr Madej von AFINE und Yunhai Zhang vom NSFOCUS TIANJI Lab zugeschrieben.
Anzeige
Am 28. Juni twitterte das Forschungsteam von QiAnXin ein GIF, das die erfolgreiche Ausnutzung von CVE-2021-1675 zur Erlangung von RCE ohne technische Details oder Proof-of-Concept (PoC)-Code zeigt. Am 29. Juni veröffentlichten die Forscher von Sangfor eine vollständige technische Beschreibung mit PoC-Code auf GitHub.
Dieses Repository wurde jedoch nach nur wenigen Stunden wieder entfernt. In obigem Tweet wird behauptet, dass man den Code zurückgezogen habe, weil ihr eingereichter Vortrag auf der BlackHat-Konferenz in den USA angenommen wurde. Es ist unklar, ob sich die Forscher aufgrund des Tweets von QiAnXin entschieden haben, ihren PoC zu teilen. Die Forscher behaupten, diese Schwachstelle unabhängig von denjenigen entdeckt zu haben, denen die Offenlegung durch Microsoft zugeschrieben wird. Aber ab diesem Zeitpunkt war der Geist aus der Flasche, denn der GitHub-Post wurde vor dem Löschen bereits durch Dritte kopiert.
Schwachstelle ermöglicht RCE, Juni-Patch hilft nicht
Die Ausnutzung der Schwachstelle CVE-2021-1675 könnte entfernten Angreifern die vollständige Kontrolle über anfällige Systeme ermöglichen. Um RCE zu erreichen, müssten Angreifer einen Benutzer anvisieren, der sich beim Spooler-Dienst authentifiziert. Ohne Authentifizierung könnte die Schwachstelle ausgenutzt werden, um die Privilegien zu erhöhen. Der Ratschlag von Tenable lautet, die betreffenden Windows-Systeme mit den von Microsoft bereitgestellten Juni 2021-Updates zu patchen.
In obigem Tweet weist jemand darauf hin, dass ein vollständig gepatchter Windows 2019-Domänencontroller mit einem 0day-Exploit (CVE-2021-1675) vom Konto eines regulären Domänenbenutzers aus geknackt werden konnte und volle SYSTEM-Rechte erhielt. Der Ratschlag lautet: Deaktivieren Sie den "Print Spooler"-Dienst auf Servern, die ihn nicht benötigen. Weitere Sicherheitsforscher wie Will Dormann oder Mitja Kolsek bestätigen das.
Um die Ausführung von CVE-2021-1675 (PrintNightmare) zu erkennen findet sich in diesem Tweet der Ratschlag, nach kernelbase.dll, unidrv.dll sowie jeder anderen dll, die im gleichen Zeitraum von spoolsv.exe in Unterordner von C:\Windows\System32\spool\drivers\ geschrieben wurde, zu suchen.
Ergänzungen: Sicherheitsforscher Kevin Beaumont hat in diesem Artikel inzwischen einige Informationen zusammen getragen und diskutiert auch, was man zur Erkennung von Angriffen tun kann. Und von heise gibt es inzwischen diesen deutschsprachigen Beitrag mit einer Übersicht.
Ergänzung 2: Von Microsoft und der CISA gibt es inzwischen auch was zum Thema, siehe Windows Print-Spooler Schwachstelle (CVE-2021-1675, PrintNightmare) von MS bestätigt; CISA warnt.
Anzeige
Es kommt noch schlimmer. Es wurden scheinbar schon Angriffe auf Domain-Controller beobachtet, und es wird vorrübergehend empfohlen, auf den DCs den Druckdienst auszuschalten. Das hat aber einen kleinen Haken, wenn man seine Drucker übers AD veröffentlicht, und man einen Drucker entfernen will, dann muss man ihn dann zwei mal löschen, einmal im AD, einmal auf dem Druckserver. Sonst ginge dies auf dem Druckerserver automatisch, wenn man ihn im AD löscht. Wenn das dann mal gepatcht ist, kann man den Druckdienst auf DCs wieder einschalten. Hier ist näheres zu lesen: https://dirteam.com/sander/2021/06/30/todo-disable-the-print-spooler-service-on-domain-controllers/
Danke für die Ergänzung – war etwas spät die Nacht, eigentlich sollte das Thema bereits gestern Vormittag als Beitrag raus – aber durch die Server-Probleme war das nicht möglich.
Huntress hat auch Infos dazu zusammengetragen:
https://www.huntress.com/blog/critical-vulnerability-printnightmare-exposes-windows-servers-to-remote-code-execution und
Es wird auch ein "fix" besprochen, bei dem die ACL im Spooler angepasst werden.
Das hat scheinbar weniger Nebeneffekte als das Stoppen des Dienstes.
Danke, die ACL-Lösung ist eigentlich naheliegend – bin mal gespannt, wie die sich schlägt.
ACL Lösung scheint nicht 100% abzusichern:
wg. "SeRestorePrivilege "
Siehe im aufgeklappten Thread auf Reddit (Unterpunkte aufklappen)
In meiner Testumgebung auf einem 2012R2 Server schmeisst das Powershell-Script einen Fehler -> geht nicht!
Habe das in einer PowerShell als Domain-Admin ausgeführt:
Fehler -> Set-Acl : Die Sicherheits-ID darf nicht der Besitzer dieses Objekts sein.
habe das Script wie empfohlen erstellt:
$Path = "C:\Windows\System32\spool\drivers"
$Acl = Get-Acl $Path
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny")
$Acl.AddAccessRule($Ar)
Set-Acl $Path $Acl
Wenn ich es manuell über den Explorer erstelle, dann funktioniert der Eintrag, schmeisst aber beim Anwenden auf Unterverzeichnisse und Files bei manchen einen Fehler…
Ich habe auch das Problem, das es nicht geht:
"
Set-Acl : Die Sicherheits-ID darf nicht der Besitzer dieses Objekts sein.
+ Set-Acl $Path $Acl
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (C:\Windows\System32\spool\drivers:String) [Set-Acl], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.SetAclCommand
"
Jemand eine Idee?
Das Skript muss mit SYSTEM-Rechten ausgeführt werden. Nutzt dazu PsExec aus den PsTool mit dem Befehl: psexec -i -s powershell.exe
Schaut man sich die Rechte später an, sieht man, das der SYSTEM-Prozess diese auch (zurück-)setzen kann. Ist das Setzen dieses Deny-ACEs dann nicht witzlos?
Hallo Herr Born, Hallo @lle,
bitte korrigiert, falls ich falsch liegen sollte…
Wenn ich auf allen DCs und auf den Member Servern (nehmen wir mal an, die AD Drucker sind nur auf den Member Servern freigegeben und per GPO verteilt) den Printer Spooler mit 'net stop spooler' herunterfahre und dann den Dienst deaktiviere, dann sollte doch alles 'SAFE' sein? Denn der Spooler wird ja nur von Usern auf dem Server benutzt, aber nicht, wenn die User über ihre Workstations drucken (auf den freigegebenen Druckern der Member Server), oder liege ich da falsch?
in welchen spooler druckt wohl der lokal installierte adobe dc professional oder jeder andere pdf drucker oder xps drucker? billige gdi drucker oder lustige followme implementierungen verwenden auch das lokale spooler service zum drucken.
also da wird noch jede menge folgen
aha und der druckspooler am client ist immun? ich sag nur lokale pdf drucker oder was auch immer.
Immun nicht, sollten aber geschützt sein.
Siehe https://msandbu.org/printnightmare-cve-2021-1675/
Die Windows Firewall blockiert standardmäßig file and printer sharing. Sollte natürlich geprüft werden, ob das bei den clients angepasst wurde.
Den Client musst du natürlich z.B. per Applocker absichern, damit da erst garnicht das Angriffsprogramm gestartet werden kann.
Das bringt ihm ja nichts, wenn z.b. Win10 Pro dort eingesetzt wird ohne Applocker…
Daher finde ich die Frage schon berechtigt. Sollte der Angriffsvektor auch Clients betreffen ist das wirklich eine heftige Lücke
gemäß: https://www.heise.de/news/PrintNightmare-Schadcode-Luecke-in-Windows-bedroht-ganze-Netzwerke-6124838.html
Das Problem findet sich im Printer-Spooler-Service von Windows. Dem derzeitigen Informationsstand zufolge sind davon alle Versionen von Windows 7 SP1 bis Server 2019 betroffen.
nachdem spoolsv.exe auf einem höherwertigen port auf 0.0.0.0 tcp listen betreibt. könnt es auch da knallen.
Dann setze die Software Restriction Poilcy um. Das ist der Vorgänger von Applocker und wird von der Pro Version unterstützt.
Eine Anleitung zur SRP findest du z.B. bei schneegans.de oder beim Stefan Kanthak.
Vielleicht endlich mal Servercore einsetzen ? 2016 Spooler installiert, aber deaktiviert – 2019 Spooler Service nicht vorhanden.
Die Client-Seite ist natürlich sehr ärgerlich, aber zu erwähnen, dass Server angegriffen werden die keine Druckserver sind, ist doch mehr der Mimi im "Semper"-Style oder ?
DC, ist DC, ist DC, das haben wir alle schon in den NT-Schulungen gelernt.
Auch wenn diese Seite durchaus informativ ist, fehlt meistens die Ehrlichkeit der kommentierenden User, dass die Hersteller einem 2021 sehr genau sagen, was zu tun ist und was keine gute Idee ist. Sprich viele Fehler wurden sehr oft, bereits an ganz anderer Stelle gemacht.
cool was man nicht alles lernen kann und irgendwo nachlesen kann und selbst mit hardening machen kann. warum schafft es der os hersteller nicht per default? warum wird das spooler service dann nicht weggehauen wenn ich die active directory rollen installiere und den server zu einem domain controller promote? warum wirds bei member servern überhaupt mitinstalliert?
lesen kann ich vieles und dann selbst nach justieren. warum aber hat das os weder am client noch am server einen sinnvollen default was die installation betrifft. das geht ja tiefer bis hin zu verschlüsselungen.
warum kann windows per default nicht nur sichere verschlüsselungen und algorithmen anbieten? warum muss ich da in registry oder mit iiscrypto erstmal nachbessern.
sorry ihr macht euch das alle sehr leicht mit dem kann man immer nachlesen und machen.
Was heisst das für einen normalen Nutzer?Sollte ich die Druckwarteschlange deaktivieren`?
Bei services.msc finde ich keinen Spooler.
Ich denke, private Nutzer sollten erst einmal abwarten. Ergänzung: Siehe auch Microsofts-Hinweise in Windows Print-Spooler Schwachstelle (CVE-2021-1675, PrintNightmare) von MS bestätigt; CISA warnt
Auf Deutsch heißt der Dienst Druckerwarteschlange.
Ich freue mich schon auf eine Lösung von https://twitter.com/0patch
Langsam Zeit den Agent auf allen WinSchrott Systemen einzusetzen.
Falls noch nicht bekannt, es gibt noch einen weiteren Workaround, welcher gerade für Clients, die drucken müssen interessant ist. Siehe hier:
https://blog.truesec.com/2021/06/30/exploitable-critical-rce-vulnerability-allows-regular-users-to-fully-compromise-active-directory-printnightmare-cve-2021-1675/
Bei uns bin ich jetzt alle drei Varianten durch. Die Clients mit der vom link beschriebenen Art per GPO versorgt. Den File&Druckserver mit den ACLs "abgesichert" und alles andere, was nicht unbedingt drucken muss den spooler Dienst deaktiviert.
jetzt auch offiziell vom MS
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
sollten lieber einen patch ausserhalb vom patchday liefern.
Man sollte im beruflichen und professionellen Umfeld lernen,
da der eigene Job möglicherweise davon abhängt. Infos sind so einfach zu erhalten und umzusetzen wie noch nie in der M$ Welt der letzten 25 Jahre.
Siehe oben, die vom Hersteller empfohlene OS Variante in der aktuellen Version verwenden und viele deiner Anmerkungen sind von Installationsbeginn an, kein Thema.
Per Baselines, die mittlerweile auch jeder nutzen sollte, weil sie angeboten werden oder FIPS140 Mode, sind auf viele der Verschlüsselungsthemen ebenfalls erledigt.
ABER, diese fadenscheinigen Argumente höre ich oft, meistens von den Firmen die preislich sehr attraktive Software einsetzen, welche mich am Ende dazu zwingt, die von dir aufgeführten, sinnvollen Änderungen alle wieder rückgängig zu machen!
Hallo,
anbei Ergänzungen zum PrintNightmare von 0patch, die den Exploit evtl. etwas besser einschätzbar machen:
https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.html
Domänencontroller:
"Our current understanding is that without any custom configuration and with June 2021 Windows Updates applied, only Windows Servers that act as a domain controller are affected (confirmed for versions 2012, 2016 and 2019). The reason seems to be that when a server is a domain controller, a Pre-Windows 2000 Compatible Access group is created for some legacy compatibility, and the Authenticated Users group is a member of this group. This makes all domain users a member of Pre-Windows 2000 Compatible Access group, which is an important piece of the puzzle for exploiting this vulnerability."
Wird auch hier angesprochen:
https://www.theregister.com/2021/07/01/printnightmare_windows_fix/
Wenn ich das richtig verstehe, sollte man die Jeder bzw. Authentifizierte Benutzer Gruppe aus der "Prä-Windows 2000 kompatibler Zugriff"-Gruppe entfernen. Dies ist wohl eine Voraussetzung für ein Funktionieren des Exploits.
Clients / Memberserver in der Domäne:
"However, non-DC servers and Windows 10 systems with June 2021 updates can also be vulnerable in at least these cases:
UAC (User Account Control) is completely disabled [source], or
PointAndPrint NoWarningNoElevationOnInstall is enabled [source].
Nevertheless, our remote attacks on Windows 10 were so far not successful against domain-joined Windows 10 machines, where the attack would be most worrisome. We were so far only able to launch the exploit using credentials of a local user on a non-domain Windows 10 machine, and such credentials are likely not known to an attacker. So these tests so far only confirm a possible local privilege escalation (a local user exploiting PrintNightmare to gain local System privileges)."
Wird auch hier noch einmal bestätigt:
https://twitter.com/wdormann/status/1410680952389525515
Wenn ich diese Infos richtig deute, soll es in Domänenumgebungen standardmäßig nicht möglich sein, den Exploit von Remote auszunutzen, wenn auf den Clients UAC aktiv und eine standardmäßige aktive Beschränkung bei der Point & Print Gruppenrichtlinie nicht aufgehoben wurde. Allerdings muss mindestens der Juni 2021 Patch installiert sein.
Alle Infos sind noch nicht von Microsoft bestätigt.
Wir haben die o.a. Gruppen bereits vor längerer Zeit schon einmal aus der "Prä-Windows 2000.."-Grupp entfernt, ohne negative Nebenwirkungen gesehen zu haben.
Zur Sicherheit haben wir den Spooler-Dienst allerdings nun auch auf allen DCs beendet und deaktiviert, soweit dies noch nicht so war.
Grüße,
Jörg
Hallo.
Ich bin ein sbsoluter Laie.wad fir Diskussion betrifft .. aber.. am 02.07.31 ca. um 23:50 kspitulierte mein Druck-Spooler mitten im Druck – nachdem er bereits 15 von 19 Seiten gedruckt hatte.
Der einzige Unterschied: ich druckte vom Android-Handy aus (GS 280),über WLAN.Anbiter Telecom, DNS-Server Windows…
Gigaset-Handys sind ja "in Verruf" gekommen, wegen undefinierbarem Malwarenbefall – das GS280 soll zwar nicht dabei sein…aber wer weiß schon genau was das Google-Betriebssystem im Hintergrund so alles zu läst.. auf jedenfall ist auf meinem Handy einiges "seltsam".
Meine Vermutung: könnte ein Zusammenhang aufgrumd des genutzten Win-Servers bestehen?
Seitdem "spinnt" mein Browser und das WLAN besteht aus dauernden Lücken..es "stottert"