PoC für Windows Print-Spooler-Schwachstelle öffentlich, hohes RCE-Risiko

Sicherheit (Pexels, allgemeine Nutzung)[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.

PoC für Windows Print-Spooler-Schwachstelle

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.

PrinterNightmare RCE

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.

Info zu gelöschtem PoC

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.


Anzeige

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.

Printer-Spooler-Schwachstelle 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.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Sicherheit, Windows abgelegt und mit Sicherheit, Windows verschlagwortet. Setze ein Lesezeichen auf den Permalink.

29 Antworten zu PoC für Windows Print-Spooler-Schwachstelle öffentlich, hohes RCE-Risiko

  1. 1ST1 sagt:

    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/

    • Günter Born sagt:

      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.

  2. Mario sagt:

    Huntress hat auch Infos dazu zusammengetragen:
    https://www.huntress.com/blog/critical-vulnerability-printnightmare-exposes-windows-servers-to-remote-code-execution und
    https://www.reddit.com/r/msp/comments/ob6y02/critical_vulnerability_printnightmare_exposes/

    Es wird auch ein "fix" besprochen, bei dem die ACL im Spooler angepasst werden.
    Das hat scheinbar weniger Nebeneffekte als das Stoppen des Dienstes.

    • Günter Born sagt:

      Danke, die ACL-Lösung ist eigentlich naheliegend – bin mal gespannt, wie die sich schlägt.

      • Richard B. sagt:

        ACL Lösung scheint nicht 100% abzusichern:
        https://www.reddit.com/r/sysadmin/comments/ob4s06/printnightmare_0day_exploit_allows_domain_takeover/h3nhuw3/

        wg. "SeRestorePrivilege "
        Siehe im aufgeklappten Thread auf Reddit (Unterpunkte aufklappen)

      • Robert Richter sagt:

        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…

        • Thomas sagt:

          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?

          • robnau sagt:

            Das Skript muss mit SYSTEM-Rechten ausgeführt werden. Nutzt dazu PsExec aus den PsTool mit dem Befehl: psexec -i -s powershell.exe

        • Jürgen Garbe sagt:

          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?

  3. Robert Richter sagt:

    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?

    • MOM20xx sagt:

      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

  4. MOM20xx sagt:

    aha und der druckspooler am client ist immun? ich sag nur lokale pdf drucker oder was auch immer.

  5. Felix Leven sagt:

    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.

    • MOM20xx sagt:

      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.

  6. Jan Berg sagt:

    Was heisst das für einen normalen Nutzer?Sollte ich die Druckwarteschlange deaktivieren`?
    Bei services.msc finde ich keinen Spooler.

  7. Hansi sagt:

    Ich freue mich schon auf eine Lösung von https://twitter.com/0patch
    Langsam Zeit den Agent auf allen WinSchrott Systemen einzusetzen.

  8. Carsten sagt:

    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.

  9. Felix Leven sagt:

    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!

  10. Jörg sagt:

    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

  11. graffunder sagt:

    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"

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.