durarain
Goto Top

Nach erster Reaktion gegen Print Nightmare keine GPO basierten Druckermappings mehr möglich

Hallo zusammen,

Als Reaktion auf die am vergangenen Donnerstag veröffentliche Sicherheitslücke "Print Nightmare" wurden meinerseits folgende Maßnahme ergriffen:
Nach Vorbild von diesem Artikel:
https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675 ...

Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.

Fazit am nächsten Morgen: Die Druckermapping via GPO funktionieren nicht mehr - Problematisch.

Die logische Gegenmaßnahme war dann, die GPO "umzukehren" und dem System User den Zugriff auf den Ordner wieder zu gewähren.
Böses Erwachen: Dadurch wurde keine Besserung erzielt.

Nach vielem hin und her scheint es so zu sein, dass sich die Treiber zerschießen und oder die Berechtigung auf den Pfad "C:\Windows\System32\spool\drivers" korrupt sind.

Ich habe es nach vielen Anpassungen an der Registry, Löschung von dem ganzen Ordner "C:\Windows\System32\spool\drivers" und etlichen Spooler neustarts zwei Rechner wieder lauffähig bekommen, habe aber noch 25 Clients vor mir und brauche eine Skriptbasierte Lösung.

Hat irgendwer ähnliche Probleme und Tipps, wie man effizient die Clients wieder Druckfähig bekommen könnte?

Content-Key: 894716439

Url: https://administrator.de/contentid/894716439

Printed on: January 31, 2023 at 06:01 o'clock

Mitglied: 148656
148656 Jul 03, 2021 at 17:12:24 (UTC)
Goto Top
Moin,

Welche Steps haben bei dir zum Erfolg geführt?
Die müsste man nur auf Kommandozeile Revue passieren lassen und schon hat mein den Kern des Skriptes. Dann noch ein bisschen Fehlerbehandlung und fertig ist der Zauber face-smile

Gruß
C.C.
Member: dertowa
dertowa Jul 03, 2021 updated at 18:42:34 (UTC)
Goto Top
Zitat von @Durarain:
Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.

Fazit am nächsten Morgen: Die Laufwerkmappings via GPO funktionieren nicht mehr - Problematisch.

Hey, warum entziehen?
Das Skript habe ich mir heute bei der angesehen und auf dem Printserver durchlaufen lassen.
screen
Es gibt dem SYSTEM lediglich verweigernde Berechtigungen, dadurch kann das SYSTEM keine Änderungen mehr vornehmen.
SYSTEM bleibt aber nach wie vor Besitzer des Ordners, also wird da nichts entzogen?

P.S.: Gerade mal im Testlab probiert und an einem Client das Skript laufen lassen.
Keine Probleme mit den Netzlaufwerken per GPO festzustellen, allerdings kann der Benutzer sich dann keine Drucker mehr hinzufügen.
Member: DerWoWusste
DerWoWusste Jul 04, 2021 updated at 10:15:59 (UTC)
Goto Top
Wäre es möglich, dass du im Titel von Laufwerken schreibst, aber Druckernappings meinst?

Ich kann das bei uns untersuchen; hatte eh noch eine Sonderschicht dafür eingeplant.
Member: Durarain
Durarain Jul 04, 2021 at 15:37:52 (UTC)
Goto Top
Zitat von @DerWoWusste:

Wäre es möglich, dass du im Titel von Laufwerken schreibst, aber Druckernappings meinst?

Ich kann das bei uns untersuchen; hatte eh noch eine Sonderschicht dafür eingeplant.

Ja, richtig. Ich meinte Druckermappings, habe ich im Eifer des Gefechts falsch angegeben.
Außerdem zur Info: Ich habe die GPO zu beginn so auf die Clients losgelassen:
gpo
Member: Durarain
Durarain Jul 04, 2021 at 15:39:32 (UTC)
Goto Top
Zitat von @dertowa:

Zitat von @Durarain:
Eine GPO erstellt, die dem System User den Zugriff auf den Pfad "C:\Windows\System32\spool\drivers" entzieht.

Fazit am nächsten Morgen: Die Laufwerkmappings via GPO funktionieren nicht mehr - Problematisch.

Hey, warum entziehen?
Das Skript habe ich mir heute bei der angesehen und auf dem Printserver durchlaufen lassen.
screen
Es gibt dem SYSTEM lediglich verweigernde Berechtigungen, dadurch kann das SYSTEM keine Änderungen mehr vornehmen.
SYSTEM bleibt aber nach wie vor Besitzer des Ordners, also wird da nichts entzogen?

P.S.: Gerade mal im Testlab probiert und an einem Client das Skript laufen lassen.
Keine Probleme mit den Netzlaufwerken per GPO festzustellen, allerdings kann der Benutzer sich dann keine Drucker mehr hinzufügen.

Okay, sehr Aufschlussreich. Ich denke ich lasse das Skript nun mal zur Reparaturzwecken laufen, schauen wir mal, eventuell stellt das die Funktion wieder her.

Ich denke das Problem ist, dass die Drucker in der GPO jedes mal neu gesetzt werden. Es werden quasi erst alle Druckermappings entfernt und dann neu zugewiesen, das wird der Grund sein, warum es dann nicht mehr funktioniert hat.
Member: Durarain
Durarain Jul 04, 2021 at 15:42:33 (UTC)
Goto Top
Zitat von @148656:

Moin,

Welche Steps haben bei dir zum Erfolg geführt?
Die müsste man nur auf Kommandozeile Revue passieren lassen und schon hat mein den Kern des Skriptes. Dann noch ein bisschen Fehlerbehandlung und fertig ist der Zauber face-smile

Gruß
C.C.

Das kann ich trotz Funktionstests zwischen meinen ausgeführten Schritten nicht genau fest machen. Ich habe in der Registry unter verschiedenen Pfaden die Drucker gelöscht (nach vorherigem Export natürlich), veruscht die Treiber zu bereinigen, unter dem Verzeichnis "C:\Windows\System32\spool\drivers" nach Recherche im Netz Dateien gelöscht usw. Und dann ging es an einem Client auf einmal wieder, nachdem ich mehrfach auf den Netzwerkdrucker geklickt habe. Ich bemühe mich weiter um eine einheitliche Lösung.
Member: Durarain
Durarain Jul 04, 2021 at 16:01:07 (UTC)
Goto Top
Diese Fehlermeldung erhalte ich, wenn ich versuche, eine Verbindung über die Freigabe herzustellen:
drucker_fehler2
Member: dertowa
dertowa Jul 04, 2021 at 16:43:08 (UTC)
Goto Top
Natürlich erhältst du die Meldung, sobald an den Clients das Skript gelaufen ist und das SYSTEM eine Verweigerung der Rechte erhält, kann der Client keine Drucker mehr hinzufügen, am Printserver darf man mit dem Skript nicht mal Berechtigungen oder Einstellungen der Drucker anpassen.

Daher halte ich das für die Clients aktuell auch als nicht praktikabel, zumindest so lang wie bei uns die Nutzer gern mal wechseln und die Drucker selbstständig tauschen.
Member: Durarain
Durarain Jul 04, 2021 at 16:51:53 (UTC)
Goto Top
Zitat von @dertowa:

Natürlich erhältst du die Meldung, sobald an den Clients das Skript gelaufen ist und das SYSTEM eine Verweigerung der Rechte erhält, kann der Client keine Drucker mehr hinzufügen, am Printserver darf man mit dem Skript nicht mal Berechtigungen oder Einstellungen der Drucker anpassen.

Daher halte ich das für die Clients aktuell auch als nicht praktikabel, zumindest so lang wie bei uns die Nutzer gern mal wechseln und die Drucker selbstständig tauschen.

Das erscheint mir natürlich auch als logisch, allerdings habe ich "System" an den Clients auch wieder auf den Pfad "C:\Windows\System32\spool\drivers" berechtigt, das lässt sich auch mit dem Powershell Skript nicht mehr rückgängig machen, wie es mir scheint!
Member: GrueneSosseMitSpeck
GrueneSosseMitSpeck Jul 04, 2021 updated at 17:01:21 (UTC)
Goto Top
ich versteh die Aufregung auch nicht so sehr... Druckertreiber nachinstallieren war schon immer ein Sicherheitsloch, aber früher nur theoretisch und man glaubte sich seit Windows 7 sicher, nachdem das Installieren von unsignierten Treibern nicht mehr zugelassen wurde.

Und schon aus eigenem Interesse unterbindet man das Einbinden von Benutzerdruckern komplett auf Terminal und Citrix-Servern und bietet vorkonfigurierte Druckwarteschlangen an. Punkt aus fertig. Bzw bei Citrix bietet man den Unviersal Printer driver an und sonst nix
Member: dertowa
dertowa Jul 04, 2021 at 17:18:53 (UTC)
Goto Top
Zitat von @Durarain:

Das erscheint mir natürlich auch als logisch, allerdings habe ich "System" an den Clients auch wieder auf den Pfad "C:\Windows\System32\spool\drivers" berechtigt, das lässt sich auch mit dem Powershell Skript nicht mehr rückgängig machen, wie es mir scheint!

Hä?
Also ich verstehe nicht was du getan hast.
Das Skript aus dem von dir genannten Blog weist nur dem SYSTEM die Verweigern - Berechtigungen zu.
Diese lassen sich mit dem "deaktivieren" Skript wieder rückgängig machen, von dem her klappt aus dem Blog alles wie versprochen.

Somit solltest du nach deiner GPO-Attacke mal checken wie die Berechtigungen nun effektiv aussehen und wer Besitzer der Dateien ist.
Member: Durarain
Durarain Jul 04, 2021 at 17:36:47 (UTC)
Goto Top
Zitat von @dertowa:

Zitat von @Durarain:

Das erscheint mir natürlich auch als logisch, allerdings habe ich "System" an den Clients auch wieder auf den Pfad "C:\Windows\System32\spool\drivers" berechtigt, das lässt sich auch mit dem Powershell Skript nicht mehr rückgängig machen, wie es mir scheint!

Hä?
Also ich verstehe nicht was du getan hast.
Das Skript aus dem von dir genannten Blog weist nur dem SYSTEM die Verweigern - Berechtigungen zu.
Diese lassen sich mit dem "deaktivieren" Skript wieder rückgängig machen, von dem her klappt aus dem Blog alles wie versprochen.

Somit solltest du nach deiner GPO-Attacke mal checken wie die Berechtigungen nun effektiv aussehen und wer Besitzer der Dateien ist.

Die Berechtigungen sind so wie sie sein sollten, in diesem Ordner. Dies habe ich auch nochmal mit dem Skript zur Zugriffswiederherstellung sichergestellt.
Member: dertowa
dertowa Jul 04, 2021 at 17:48:42 (UTC)
Goto Top
Pack mal bitte ein Bild her, denn wenn sie wären wie sie sollten, gäbe es wohl kein Problem mit dem Hinzufügen der Drucker, außer durch die Reparatur ist mehr kaputt gegangen. ace-sad"
Member: Durarain
Durarain Jul 04, 2021 at 17:52:30 (UTC)
Goto Top
Zitat von @dertowa:

Pack mal bitte ein Bild her, denn wenn sie wären wie sie sollten, gäbe es wohl kein Problem mit dem Hinzufügen der Drucker, außer durch die Reparatur ist mehr kaputt gegangen. ace-sad"

Danke, kein Problem, hier:
properties_check
Member: dertowa
dertowa Jul 04, 2021 updated at 18:11:49 (UTC)
Goto Top
Spannend, hier mal von meinem Client...
screen
Member: Durarain
Durarain Jul 04, 2021 at 18:23:02 (UTC)
Goto Top
Zitat von @dertowa:

Spannend, hier mal von meinem Client...
screen

Bis auf die nicht auf gelöste SID von dir und dass bei dir "jeder" und bei mir benutzer berechtigt sind, sehe ich keinen Unterschied.

Ich habe probehalber mal "jeder" auf die berechtigungsliste gesetzt, keine Änderung des Problems leider.
Member: dertowa
dertowa Jul 04, 2021 at 19:17:33 (UTC)
Goto Top
Naja lustig ist, dass die Berechtigungen hier auch in meiner privaten Umgebung so aussehen.
screen2
Beide Systeme sind Domainmember und Domainuser sind in den Berechtigungen gar nicht enthalten.
Member: O-Marc
O-Marc Jul 04, 2021 updated at 19:30:12 (UTC)
Goto Top
Hallo Durarain,

hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?

Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.
Member: DerWoWusste
DerWoWusste Jul 04, 2021 updated at 21:28:39 (UTC)
Goto Top
Ich würde das Gebastel lassen.
Entweder, man stellt Clients mit freigegebenen Druckern so ein, dass Nutzer nur noch lokal drucken können, oder man glaubt den Jungs von zeropatch, die eh nur auf DCs überhaupt eine Gefahr sehen und schaltet dort eben den Spooler um auf disabled.
Siehe https://www.ghacks.net/2021/07/03/workaround-for-the-windows-print-spool ...
und https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.htm ...
(Letztere haben sogar einen Patch dafür kostenlos abzugeben).
Member: Ex0r2k16
Ex0r2k16 Jul 05, 2021 at 08:44:25 (UTC)
Goto Top
Zitat von @DerWoWusste:

Ich würde das Gebastel lassen.
Entweder, man stellt Clients mit freigegebenen Druckern so ein, dass Nutzer nur noch lokal drucken können, oder man glaubt den Jungs von zeropatch, die eh nur auf DCs überhaupt eine Gefahr sehen und schaltet dort eben den Spooler um auf disabled.
Siehe https://www.ghacks.net/2021/07/03/workaround-for-the-windows-print-spool ...
und https://blog.0patch.com/2021/07/free-micropatches-for-printnightmare.htm ...
(Letztere haben sogar einen Patch dafür kostenlos abzugeben).

thx! Erst mal so umgesetzt.
Member: dertowa
dertowa Jul 05, 2021 at 09:25:51 (UTC)
Goto Top
Zitat von @Ex0r2k16:

thx! Erst mal so umgesetzt.

Ich hab das Thema zum Anlass genommen alle verbleibenden GUI Server mal zu checken ob der Druckspooler wirklich benötigt wird.
Also erstmal einfach überall aus. ;)
Verbleibend ist der Printserver übrig und der ist per Skript nun im Zugriff beschränkt.

Zudem habe ich das Thema noch mal zum Anlass genommen die Kollegen erneut zu sensibilisieren, denn irgendwo muss die Schadsoftware ja auch herkommen, die fällt ja nicht vom Himmel...
Member: Durarain
Durarain Jul 05, 2021 updated at 13:48:04 (UTC)
Goto Top
Zitat von @O-Marc:

Hallo Durarain,

hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?

Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.

Das hat leider nicht funktioniert. Ich denke man müsste die Berechtigungen in der Registry eventuell anpassen/zurücksetzen. Kennt da jemand einen Befehl? Setzte mich aktuell mit "secedit /configure /cfg" auseinander
Member: ArnoNymous
ArnoNymous Jul 05, 2021 at 14:10:43 (UTC)
Goto Top
Zitat von @Durarain:

Zitat von @O-Marc:

Hallo Durarain,

hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?

Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.

Das hat leider nicht funktioniert. Ich denke man müsste die Berechtigungen in der Registry eventuell anpassen/zurücksetzen. Kennt da jemand einen Befehl? Setzte mich aktuell mit "secedit /configure /cfg" auseinander

Moin,

nachdem du die Berechtigungen zurückgesetzt hast, hast du den Spooler aber schon auch neugestartet?

P.S.: Das Skript ist übrigens auch gar nicht für Clients gedacht.

Gruß
Member: SOlangsam
SOlangsam Jul 06, 2021 at 08:39:47 (UTC)
Goto Top
Moin,

ich sehe ebenfalls kein Problem bei den Clients. Lediglich für Printserver in zusammenhang mit DC's war es gemeint.

Um die Permissions zurückzusetzen, kannst du dich mit icacls und secedit auseinandersetzen:
How to reset File and Folder permission to default
Member: Durarain
Durarain Jul 06, 2021 at 12:13:41 (UTC)
Goto Top
Zitat von @ArnoNymous:

Zitat von @Durarain:

Zitat von @O-Marc:

Hallo Durarain,

hast Du mal versucht, die Berechtigungen mit icacls auf einem funktionierenden (oder unangetasteten) Computer in eine Datei zu speichern und mit dieser dann einen Restore der ACLs auf einem nicht funktionierenden Computer zu machen?

Das Script von truesec.com funktionierte bei mir übrigens nicht auf Windows 2012 R2-Computern.
Da war eine Anpassung nötig.

Das hat leider nicht funktioniert. Ich denke man müsste die Berechtigungen in der Registry eventuell anpassen/zurücksetzen. Kennt da jemand einen Befehl? Setzte mich aktuell mit "secedit /configure /cfg" auseinander

Moin,

nachdem du die Berechtigungen zurückgesetzt hast, hast du den Spooler aber schon auch neugestartet?

P.S.: Das Skript ist übrigens auch gar nicht für Clients gedacht.

Gruß

Den Spooler habe ich neugestartet - ja.
Nun zum aktuellen Fortschritt:
Es hat sich herausgestellt, dass an den meisten Clients die Vererbung erneut aktiviert werden muss, sodass auch sämtliche Unterordner von "C:\Windows\System32\spool\drivers" den "SYSTEM" User wieder mit Vollzugriffsrechten führen.

Nun gibt es einige Sonderfälle.
Zb via Remote Desktop gemappte/angebundene Drucker werden damit nicht wieder gangbar gemacht
Alle Rechner auf die ich auch nur zur "leichten" Fehleranalyse aufgeschalten war (also einfach nur Drucker entfernt und versucht über das mapping wieder hinzuzufügen), funktioniert es auch partout nicht mehr
Member: webofficial
webofficial Jul 08, 2021 at 14:35:23 (UTC)
Goto Top
hast du dafür mittlerweile eine Lösung gefunden? Ich stehe vor dem selben Problem. Ich habe mit dem Powershell Skript die ACL wieder entfernt, kann aber keine Drucker mehr hinzufügen. Auch das erneute Aktivieren der Vererbung bringt keinen Erfolg.
Member: Durarain
Durarain Jul 12, 2021 at 15:01:26 (UTC)
Goto Top
Hallo,

Also die Lösung in meinem Fall war, die Haken wie hier beschrieben zu setzen:
"Es hat sich herausgestellt, dass an den meisten Clients die Vererbung erneut aktiviert werden muss, sodass auch sämtliche Unterordner von "C:\Windows\System32\spool\drivers" den "SYSTEM" User wieder mit Vollzugriffsrechten führen."

Vor diesem Vorgang einmal als Admin den Besitz des Ordners übernehmen und den Spoolerdienst stoppen.

Und dann die Treiber an einem Printserver (optimalerweise einen neuen aufsetzen) austauschen. Ich habe zb anstelle von Kyocera dann die von dem Windows Update Treiberpaket genommen.
Member: dertowa
dertowa Jul 12, 2021 at 19:11:21 (UTC)
Goto Top
Zitat von @Durarain:
Und dann die Treiber an einem Printserver (optimalerweise einen neuen aufsetzen) austauschen.

Wenn man nicht alles verfummelt hat braucht es weder nen neuen Printserver noch neue Treiber...
Ich habe beim Printserver einfach das Skript wieder rückgängig gemacht und fertig.