[English]Es sieht so aus, dass Windows 10 Funktionsupdates ab der Version 1809 bis hin zur aktuellen Version 21H1 die Zugriffsrechte auf die SAM-Datenbank so verändern, dass nicht administrative Benutzer auf diese zugreifen können. Ursache könnten die Volumenschattenkopien (Shadow Copy) sein, die standardmäßig aktiviert sind. Hier erste Informationen – ich bin momentan noch etwas am sortieren.
Anzeige
Ich bin gerade auf den nachfolgenden Tweet von Sicherheitsforscher Kevin Beaumont aufmerksam geworden, der eine Entdeckung von Mimikatz-Entwickler Benjamin Delpy gepostet hat. Benjamin Delpy ist die letzten Wochen hier im Blog ja häufiger genannt worden, weil er immer wieder neue Angriffsvektoren im PrintNightmare Print-Spooler-Dienst aufgezeigt hat.
Benjamin Delpy deutet noch recht vorsichtig an, dass es so ausschaut, als ob beim einem Upgrade von Windows 10 auf eine andere Windows 10 Version ein gravierendes Sicherheitsproblem auftritt. Man möge prüfen, ob die Schattenkopien für den Systemschutz aktiviert seien (diese ist aber standardmäßig eingeschaltet). Kevin Beaumont rückt das dann in den Kontext: Es sieht so aus, als ob die SAM-Datenbank von Windows 10, wo auch die Nutzerkennwörter gespeichert sind, für Nicht-Administratoren zugreifbar seien.
Anzeige
Im Moment testen die Leute rauf und runter. Die nachfolgenden Tweets fassen das Ganze ziemlich kompakt zusammen.
Jeff McJunkin hat es mit Will Dormann getestet. Ab Windows 10 Version 1809 sind die ACLs der SAM-Datenbank nach einem Upgrade so gesetzt, dass jeder Benutzer darauf zugreifen kann. Blog-Leser 1ST1 hat dann in diesem Kommentar den obigen Tweet verlinkt. Kevin Beaumont bestätigt, dass die Access Control Lists (ACLs) für die SAM-Datenbank unter Windows 10 falsch gesetzt werden. Jeder Standardnutzer kann wohl auf diese SAM-Datenbank zugreifen. 1ST1 schreibt dazu:
Der nächste große Haufen?
https://twitter.com/GossiTheDog/status/1417259606384971776
C:\Windows\System32>icacls c:\windows\system32\config\SAM
c:\windows\system32\config\SAM VORDEFINIERT\Administratoren:(I)(F)
NT-AUTORITÄT\SYSTEM:(I)(F)
VORDEFINIERT\Benutzer:(I)(RX)
ZERTIFIZIERUNGSSTELLE FÜR ANWENDUNGSPAKETE\ALLE ANWENDUNGSPAKETE:(I)(RX)
ZERTIFIZIERUNGSSTELLE FÜR ANWENDUNGSPAKETE\ALLE EINGESCHRÄNKTEN ANWENDUNGSPAKETE:(I)(RX)Da sollte eigentlich kein Benutzer zugreifen können. Auch SECURITY hat falsche Berechtigungen. Nachvollziehbar anscheinend seit 1809 bis 21h1.
Ich habe mal icacls auf einem Windows 10 21H1 Testsystem ausführen lassen, und bekam die gleichen Werte im Fenster der Eingabeaufforderung eines Standardbenutzers angezeigt.
Wenn ich es nicht vollständig falsch interpretiere, hat die SAM für normale Benutzer durch das RX-Flag Lese- und Ausführungszugriff. Das heißt, jeder Benutzer kann die SAM-Datenbank mit den Nutzerpasswörtern auslesen. Der Sicherheitsbock schlummert seit Jahren in Windows 10 und niemandem ist das aufgefallen. Beaumont konnte das Problem auf seinem Windows 10 21H1 ebenfalls nachvollziehen und bestätigt, dass auch der Ordner SECURITY falsche Berechtigungen hat.
Soll man reagieren?
Sicherlich fragen sich Administratoren jetzt, ob sie mal schnell die ACLs anpassen sollen, so dass die Standardnutzer keinen Zugriff mehr haben. An dieser Stelle kippe ich mal einen Hinweis von Beaumont hier rein, der schreibt:
Übrigens würde ich nicht in Panik verfallen, es ist wie es ist. Die Anwendung von Abhilfemaßnahmen, um ACLs selbst zu ändern, kann Dinge kaputt machen, und es ist sehr wahrscheinlich, dass es sowieso schon seit Jahren so ist. Letztendlich wird MS das patchen.
Und er schließt mit dem Hinweis: Gute EDR-Tools sollten SAM-Dumping-Warnungen anzeigen. Zudem verschlüsselt Microsoft ja die SAM-Einträge (siehe). Inwieweit das umgangen werden kann, vermag ich nicht zu beurteilen.
Ergänzung: Kevin Beaumont hat diesen HiveNightmare Exploit auf GitHub eingestellt, um den Inhalt der SAM-Datenbank zu dumpen, wie er in diesem Tweet mitteilt.
Ich frage mich an dieser Stelle aber: Was ist mit Microsofts-Entwicklern los. Das Marketing wird nicht müde, zu betonen, dass Windows 10 das sicherste Windows aller Zeiten ist und lobt seinen Windows as a service-Ansatz, der von einer Katastrophe in die Nächste schlittern lässt. Vorne wird die Haustür auf Hochglanz gepinselt, und an der Hinterfront klaffen Scheunentor große Sicherheitslöcher. Auch wenn die aktuelle Geschichte jetzt keine so gravierende Schwachstelle ist, weil Verschlüsselung etc. greift, ist das Ganze unschön (beachtet aber, dass sich diese erste Einschätzung ändern kann, siehe auch die folgenden Kommentare). Wenn es noch eines Beispiels bedurft hätte, dass das WaaS mit den halbjährlichen Funktionsupdates in der gegenwärtigen Form schlicht gescheitert ist, wäre dies der Beleg. Oder wie seht ihr das?
Ergänzung: Es liegen inzwischen Sicherheitswarnungen von Microsoft und dem US-CERT sowie neue Erkenntnisse gegenüber obigen Ausführungen vor, die ich im Blog-Beitrag HiveNightmare: Neue Details zur Windows-Schwachstelle CVE-2021-36934 veröffentlicht habe.
Anzeige
Nein, Panik ist wahrscheinlich erstmal zu viel, denn immerhin funktioniert ein simples "type c:\windows\system32\config\SAM" und änliches nicht, da wird der Zugriff verweigert. Aber irgendjemand wird vielleicht einen Weg finden. Übrigens sind nur die Dateien im config-Ordner betroffen, der Ordner config selbst ist für Benutzer nicht lesbar. Aber mal schauen, was da noch kommt…!
Aber nur, weil das System auf die Datei zugreift. Daher geht der POC über die Schattenkopien.
Ja tatsächlich auf meinen Arbeitsnotebook, auf dem ich keine administrativen Rechte habe, erhalte ich die gleiche Anzeige wie oben. Auf meinem privaten System bei dem ich einen Cleaninstall mit 20H2 gemacht habe erhalte ich in der CMD ohne Adminrechte augeführt einen Zugriff verweigert :D
Simpler Programmierfehler oder einfach nur eine der vielen jahrelang genutzten Lücken von/für Geheim- und sonstige Dienste?
Alles angefangen vom kleinsten Chip mit irgendwelcher Firmware, über CPUs, Grafikshadern, Netzwerkstacks, TPM-Komponenten bis hin zu jeder Benutzeroberfläche jedes Betriebssystems ist garantiert von verschiedenen Playern vollgepackt mit Backdoors, Lücken und Aushebelungsmöglichkeiten, und manchmal fliegt irgendwas davon irgendwem schön um die Ohren, das ändert aber sicherlich nichts an den grundsätzlichen Ansprüchen bzgl. dieser Art Zugangsmöglichkeiten.
Ich hab mal nachgesehen:
Schon im Installationsimage vom 2018' ist VORDEFINIERT\Benutzer bei SAM enthalten.
Gegenprobe:
Im 2015' Installationsimage fehlt VORDEFINIERT\Benutzer !
Es kommt also nicht per Update / Upgrade sondern ist auch bei Neuinstallationen so gesetzt …
Kann dies hier nicht nachvollziehen, getestet auf 2 Clients 21H1 19043.1110:
NT-AUTORITÄT\SYSTEM:(I)(F)
VORDEFINIERT\Administratoren:(I)(F)
Das besondere an diesen Clients ist, dass ehemals Windows 7 darauf lief.
(Auf einem neuen Win 10 Client verhält es sich aber so wie hier beschrieben)
MfG,
Chris Ueberall;
Gleiches hier. War allerdings immer Windows 10, ich habe keine Ahnung mehr mit welcher Build ich angefangen habe. Aktuell ist 21H1.
Hier[TM] zeigt ein im Februar 2020 von Windows 7 auf Windows 10 1909 (und mit dessen Wartungsende auf 20H2) aktualisiertes System diese Schwachstelle: mit Ausnahme des Benutzerprofils von SYSTEM (%SystemRoot%\System32\Config\SystemProfile) haben alle Dateien und Unterverzeichnisse von …\Config die schädliche Berechtigung.
Moin,
Kann ich bei meinem 20H2 nicht erkennen (wurde mit 20H2 frisch installiert).
Auf diese SAM-Datei hat nur das SYSTEM, die Administratoren-Gruppe und mein Domänen-User Zugriff. Mein Rechner ist natürlich in einer Domäne, ggfs. verhält es sich dort anders?
Kann ich gerade nicht prüfen.
SECURITY hat die gleichen NTFS-Rechte wie meine SAM-Datei.
MfG
Hallo,
ich habe das ganze jetzt an meiner Rechner getestet und dort hat mein Domänen-User nur (I)&(F).
Ich habe das gleiche habe ich auch mit einer Windows 11 (Build: 22000.51) VM getestet und dort erhielt ich folgendes für SAM und SECURITY: "VORDEFINIERT\Administratoren:(I)(F)
NT-AUTORITÄT\SYSTEM:(I)(F)
VORDEFINIERT\Benutzer:(I)(RX)
ZERTIFIZIERUNGSSTELLE FÜR ANWENDUNGSPAKETE\ALLE ANWENDUNGSPAKETE:(I)(RX)
ZERTIFIZIERUNGSSTELLE FÜR ANWENDUNGSPAKETE\ALLE EINGESCHRÄNKTEN ANWENDUNGSPAKETE:(I)(RX)"
Mfg
VORDEFINIERT\Benutzer:(I)(RX)
^^^^^^^^^
Damit haben alle Benutzer Leserechte.
Ja mag sein, aber dies ist eben nur bei meiner Windows 11 VM so, bei meinem Windows 10 System hat mein Domänenbenutzer nur (I) & (F) und dort ist der Eintrag "VORDEFINIERT\Benutzer:" nicht vorhanden.
Und (F) bedeutet Fullaccess … was noch schlimmer ist …
Benutzer oder Domänenbenutzer sollten hier nicht aufgelistet sein …
Ah o.k. Danke.
Kann ich hier (21H1 – 10.0.19043.1110) nicht erkennen. (Domänenzugehörig)
[c:\windows\system32\config\SAM: Zugriff verweigert
0 Dateien erfolgreich verarbeitet, bei 1 Dateien ist ein Verarbeitungsfehler aufgetreten.]
https://i.imgur.com/xQg5bNT.png
Falls das noch ein Unterschied macht: Windows 10 Enterprise – 64-Bit
Kann ich hier auch nicht bestätigen.
System mit 1709 angefangen und über die einzelnen Halbjahres-Hops bis auf 21H1.
Dort hat VORDEFINIERT\Benutzer sowie mein Domänenbenutzer nur (I)&(F).
Ist auch ein Domänenrechner
VG
Aber bedeutet (F) nicht Fullaccess ?
Und die Domänenuser dürften doch auch NICHT drin sein …
Das wäre ja noch schlimmer !
Oder versteh ich das falsch ?
Mit icacls sehe ich das ich als Domänenuser RX-Rechte hätte, wenn ich per Explorer zur SAM möchte bekomme ich aber den Dialog das ich keine Rechte dafür hätte…
So ganz kann ich das Problem aber auch nicht nachvollziehen. Unter Linux kann ja auch jeder die Shadow einsehen, oder übersehe ich hier etwas?
Der Explorer will imho den Ordner auslesen, was nicht geht.
Wie sieht es mit einem portablen Dateimanager aus? Kannst Du von einem Standardnutzer mit HiveNightmare.exe (siehe mein Link am Artikelende auf Github) die SAM in den Benutzerordner auslesen lassen?
Mit Freecommander das selbe "Sie verfügen nicht…."
https://imgur.com/a/1J7Rhan
Hivenightmare sagt mir "Zugriff verweigert", wird aber auch von unserem Panda 360 beim Aufruf geblockt. Mal whitelisten.
Ohne Virenscanner kommt: "Assuming no errors, Khajiit should find wares in SAM-haxx".
Ps. bin lokaler Admin, kein Domainadmin und lasse das Programm auch nicht per UAC als Admin laufen.
Ah, jetzt hab ichs geschnallt. Mit einem vorher erstellen Volume Shadow Copy (VSC) liest das Tool tatsächlich die File aus. Ja, er liest die File aus, aber nur wenn man einen Snapshot (Volume Shadow Copy) hat. Wie schon oben geschrieben ist das bei Linux ja auch möglich als User die Shadow auszulesen, sehe also da nicht wirklich ein wildes Sicherheitsproblem. In Firmen sollten die User ohnehin über das AD verwaltet werden…
Danke für die Ergänzungen. Als wildes Sicherheitsproblem wurde es oben im Text auch nicht thematisiert, da die SAM-Passwort-Einträge verschlüsselt sind. Aber unschön ist es schon – ich denke, MS wird es patchen müssen.
Ergänzung: Allerdings tue ich mich schwer, die wirkliche Tragweite abzuschätzen. Tools wie Mimikatz können die verschlüsselten Info ja auslesen und dann zur Verwendung bereitstellen. Hier erhalte ich unterschiedliche Informationen von den US-Kollegen.
Stimmt, sollte schon gefixed werden. Unschön würde es zb auf einem Terminalserver wenn User sich dann einfach als lokaler Admin anmelden könnten, wenn ich gerade mal so nachdenke *grusel*. Da müssen es nicht mal AD-Anmeldedaten sein um richtig schaden anrichten zu können. Zumindest liegt nichts davon mal direkt im Klartext da.
Auf Terminalservern bzw. allgemein Windows Servern sind die Dateirechte der SAM und SECURITY in Ordnung. Vielleicht kann man das auf den Workstations via icacls reparieren, in dem man den Benutzern das Recht entzieht.
Niemand hat die Absicht, eine Mauer zu b^H^W^W^W "pass-the-hash" zu verwenden!
Soviel zu den "verschlüsselten" Kennwörtern.
Hat sich im Folgeartikel geklärt – danke für den Einwurf – ist halt alles work in progress und die Leserschaft steuert die eigenen Erkenntnisse bei – so haben alle was davon.
Diese saublöde (und dummerweise seit ca. 30 Monaten NICHT entdeckte) Schlamperei Microsofts zeigt, dass die ihre Prozesse NICHT im Griff haben.
Ich argwöhne, dass Lukas Lyk diese Schwachstelle NICHT gezielt gesucht/gefunden hat, sondern per Zufall beim "Spielen" mit einer anderen Schwachstelle — denn sobald jemand mit auch nur etwas Ahnung von Windows diese Berechtigungen sieht zündet eine Supernova in dessen Kopf. Der Exploit dazu ist trivial!
Vergleiche dazu das in https://skanthak.homepage.t-online.de/quirks.html#quirk13 dokumentierte FEHL-Verhalten von FindFirstFile()/FindNextFile() sowie GetFullPathName(): diese Funktionen werden von UAC, SAFER und AppLocker benutzt, um "sichere" von "unsicheren" Pfaden zu unterscheiden — und die Fehler erlauben, diese "Sicherheiz"-Features zu umgehen.
Quark, unter Linux kann standardmäßig nur root shadow lesen.
Ha, dachte das war vor einigen Jahrzehnten mal anders. Gerade getestet und tatsächlich. Na dann.
Ich habe versucht, es per Powershell copy-item aus der VolumeShadowCopy rauszuhuholen, müsste eigentlich gehen, "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\Windows\System32\config\SAM" müsste eigentlich der richtige Pfad sein, aber ich bekomme immer "Ein Teil des Pfades … konnte nicht gefunden werden.". Die Windows-Partition ist laut Diskpart die Nummer 4, müsste also passen.
das stimmt so nicht, in vielen Firmen gibt es einen Fallback Local Admin zB durch LAPS, damit wäre das SAM dann doch wieder problematisch.
LAPS ist ein gewisser Schutz, weil der Administrator auf allen Systemen ein anderes Passwort hat, aber der lokale Account bleibt damit weiterhin angreifbar.
Gab es schon erfolgreiche Attacken auf die SAM bzw. SECURITY Datei, dass es jemand tatsächlich gelungen ist, da Daten auszulesen, oder ist die Datei verschlüsselt?
C:\WINDOWS\system32> icacls c:\windows\system32\config\SAM
c:\windows\system32\config\SAM NT-AUTORITÄT\SYSTEM:(I)(F)
VORDEFINIERT\Administratoren:(I)(F)
1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten.
Sowohl auf einem über die Jahre hochgezogenen 20H2 als auch auf einem frisch aufgesetzten.
Beides Domänenrechner.
Ich konnte es reproduzieren und die Datei mit dem Exploit dumpen, ohne dass Adminrechte erforderlich waren.
Allerdings war System Protection nicht angeschaltet und musste erst aktiviert werden und danach ein Wiederherstellungspunkt erstellt werden – für beides waren Adminrechte nötig.
Das System (alte TestVM) wurde nie geupgraded (installiert als 1909 und ist auch jetzt noch 1909). Das Device ist in einer Domäne.
Sieht so aus, als ob die Schattenkopien den Snapshot aufweisen – siehe auch den anderen Kommentar von Stefan als Domain-Nutzer.
Bitte haltet Euch vor Augen: während Delpy Wege zur Ausnutzung mit Video vorführt, also wirklich von jedem in 1 Minute nachstellbar, zweifeln hier noch Leute ob der Schwere. Und besser noch, man kann lesen "Auch wenn die aktuelle Geschichte jetzt keine so gravierende Schwachstelle ist, weil Verschlüsselung etc. greift…" (äh…nein! Mit diesen Hashes kann man alles machen) und der Text schließt mit "Oder wie seht ihr das?" :-)
Das ist doch keine Ansichtssache. MS baut mal wieder Mist und was dieser Artikel vornehmlich tun sollte, ist aufklären, wie man's behebt (Workaround): Schattenkopien löschen! Im Netzwerk als immediate Task als Batch deployen: vssadmin delete shadows /all /quiet
Und zwar JETZT. Und aufpassen, dass MS's Defender nicht dazwischenfunkt :-) siehe https://administrator.de/forum/windows-defender-ausschlussliste-zieht-nicht-1060209053.html
PS: Ja, man sollte wissen, was dieser Befehl tut, bevor man ihn absetzt.
Ich gebe dir bzgl. der Einschätzung inzwischen Recht. Bedenke aber, dass der Artikel ein Work in Progress ist – wo stündlich neue Erkenntnisse auftauchen.
Bezüglich deines "Oder wie seht ihr das?" ganz schlicht: Das war ein Aufruf an die Leserschaft, ihr Wissen dazu beizutragen und nicht unbegründete Meinungen zu posten. Mit deinem Hinweis hast Du entsprechende Informationen geliefert, also Zweck meines "Oder wie seht ihr das?" erfüllt.
Zweiter Aspekt des "Oder wie seht ihr das?": Stand vor dem Satz, dass ich WaaS unter der aktuellen Konstellation als gescheitert ansehe, da mein Bauchgefühl mir sagt, dass die semi-annual Feature Updates einen riesigen Druck aufbauen, dass solche Fehler passieren. Mit einem WaaS, bei dem alle fünf Jahre ein Funktionsupdate kommt, gäbe es möglicherweise weniger solcher Probleme. Da wäre die Meinung der Leserschaft gefragt.
Dieser Fehler hat IMHO nichts damit zu tun, dass das jetzt "WaaS" ist. Servicepacks gab es auch schon vorher. Das mit den falschen Berechtigungen ist ein Fehler, ein Fehler, ein Fehler – der übrigens in der install.wim zu stecken scheint. Und Fehler gab es auch schon früher, auch neue in Servicepacks.
"Mit deinem Hinweis hast Du entsprechende Informationen geliefert, also Zweck meines „Oder wie seht ihr das?" erfüllt." – jou, da gebe ich Dir Recht. Es ist auch nicht böse gemeint. Es soll nur vor Augen führen, wie es läuft – die Infos liegen vor, aber es wird geredet und diskutiert und das Handeln bleibt auf der Strecke.
Es ist nicht schwer, dies abzufedern, deswegen sollte man sofort handeln.
"Es ist nicht schwer, dies abzufedern, deswegen sollte man sofort handeln."
Die Schattenkopien haben ja meist auch einen sinnvollen Einsatzzweck. Jetzt zu sagen "löscht die alle mal, dann seid ihr sicher" ist dann auf einer Höhe mit Microsofts aussage man solle doch den Spooler deaktivieren um vor PrintNightmare geschützt zu sein. Holzhammermethode.
Ja, stimmt, das könnte einige Backup-Systeme aus dem Tritt bringen, die über VSS sichern. Im Zweifelsfall ist das nächste inkrementelle Backup dann ein Voll-Backup.
Aber Ok, man macht das ja nur auf Workstations, und die sind normalerweise nicht im Backup.