Windows 10: SAM-Zugriffsrechte ab 1809 nach Upgrade kaputt, Benutzerzugriff möglich

Windows[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.

Windows 10 upgrade changes SAM ACL

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.

Windows 10 SAM ACLs broken

Im Moment testen die Leute rauf und runter. Die nachfolgenden Tweets fassen das Ganze ziemlich kompakt zusammen.

Windows 10 SAM ACLs broken

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.


Anzeige

Windows 10: SAM ACLs

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.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

41 Antworten zu Windows 10: SAM-Zugriffsrechte ab 1809 nach Upgrade kaputt, Benutzerzugriff möglich

  1. 1ST1 sagt:

    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…!

  2. Anonymous sagt:

    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

  3. Frau Holle sagt:

    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.

  4. jup sagt:

    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 …

  5. Chris Ueberall sagt:

    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;

    • Mark Heitbrink sagt:

      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.

  6. Max sagt:

    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

  7. Lorem Ipsum sagt:

    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

  8. jNizM sagt:

    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

  9. SteFan sagt:

    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

  10. jup sagt:

    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 ?

  11. Stefan sagt:

    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?

    • Günter Born sagt:

      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?

      • Stefan sagt:

        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…

        • Günter Born sagt:

          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.

          • Stefan sagt:

            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.

          • 1ST1 sagt:

            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.

          • 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.

        • Qu sagt:

          Quark, unter Linux kann standardmäßig nur root shadow lesen.

        • 1ST1 sagt:

          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.

        • Michael sagt:

          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.

          • 1ST1 sagt:

            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?

  12. gpburth sagt:

    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.

  13. ASlowTurtle sagt:

    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.

  14. Bernhard Diener sagt:

    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.

    • Günter Born sagt:

      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.

      • 1ST1 sagt:

        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.

      • Bernhard Diener sagt:

        "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.

        • Stefan sagt:

          "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.

          • 1ST1 sagt:

            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.

Schreibe einen Kommentar zu Lorem Ipsum Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

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.