HiveNightmare: Neue Windows 10-Schwachstelle CVE-2021-36934

Zur Info: In Windows 10 gibt es ab Version 1809 einen gravierenden Bug. Die ACLs auf die Hives mit den Informationen in der Registry werden falsch gesetzt. Das führt dazu, dass jeder Benutzer den Inhalt der Security Accounts Manager (SAM)-Datenbank über deren VSS-Schattenkopien auslesen kann. Mit Tools wie mimikatz und pass-the-hash lassen sich diese Informationen zur Rechteauswertung missbrauchen.

Ich hatte gestern bereits die ersten Hinweise in einem Blog-Beitrag zusammen getragen. Sowohl Microsoft als auch das US-CERT haben die Nacht Sicherheitshinweise verfasst. Daher gibt es einen Nachtragsartikel im Blog - ein Beitrag für den heise Newsticker ist raus. Als Workaround ließen sich die ACLs für die betreffenden Dateien per GPO setzen.

HiveNightmare: Neue Details zur Windows-Schwachstelle CVE-2021-36934

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1066687503

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

Ausgedruckt am: 23.11.2024 um 07:11 Uhr

10 Kommentare

Neuester Kommentar

Hi,
ich habe das Setzen der NTFS-Berechtigungen per GPO umgesetzt und es funktioniert.

Der Eintrag dazu in der GptTmpl.inf unter "[File Security]" lautet

"%SystemRoot%\System32\config",2,"D:PAR(A;OICI;0x1200a9;;;S-1-15-2-1)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;CI;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)"  

E.

Edit:
Oder wenn man eine extra GPO für nur dafür schreiben will:
Der komplette Inhalt der INF

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"  
Revision=1
[File Security]
"%SystemRoot%\System32\config",2,"D:PAR(A;OICI;0x1200a9;;;S-1-15-2-1)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;CI;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)"  

Das entspricht:

Ergebnis:

Exakt das gleich Ergebnis, welches man mit dem von MS angegeben Workaround erreicht.

@emeriks
Und nun sag mir, was hat die Gruppe "Alle Anwendungspakete" für eine Relevanz hier? Muss sie drauf sein (hier ist sie es nicht)?
Stellt sie ein Risiko dar, spricht, könnte ein Nichtadmin dieses Konto impersonaten?

Zitat von @kgborn:

Zur Info: In Windows 10 gibt es ab Version 1809 einen gravierenden Bug. Die ACLs auf die Hives mit den Informationen in der Registry werden falsch gesetzt.

Hey,
ich hatte das heute in deinem Blog schon entdeckt und wundere mich doch manchmal über die "Panikmache".
Natürlich es ist ein Problem, Sicherheitsleck wie auch immer, aber stutzig machen mich dann solche Sachen:

Im Blog steht:

Zur Schwachstelle gibt es die Erkenntnis, dass ab Windows 10 Version 1809 die Access Control Lists (ACLs) mit den Berechtigungen für die Hive-Dateien:

c:\Windows\System32\config\sam
c:\Windows\System32\config\system
c:\Windows\System32\config\security

in manchen Szenarien fehlerhaft gesetzt werden. Dann werden der Gruppe der Standardbenutzer Leserechte auf diese Dateien gewährt.

Mich würden jetzt diese Szenarien interessieren, denn weder in meinen System (Privatumgebung mit Domainanbindung), noch auf Systemen ohne Domain, noch auf den Firmensystemen habe ich Leserecht der Gruppe Standardbenutzer entdecken können.

Demnach bin ich nirgends davon betroffen und da stellt sich natürlich die Frage was bedeutet "in machen Szenarien" und wie dramatisch ist es überhaupt...

P.S.: Hinzu kommt, dass mein System auch beim Zugriff auf den config-Ordner Adminberechtigungen haben will.
Demnach müsste doch eine Schadsoftware die darauf abzielt auch als Admin ausgeführt werden, oder irre ich da?

Zitat von @DerWoWusste:
@emeriks
Und nun sag mir, was hat die Gruppe "Alle Anwendungspakete" für eine Relevanz hier? Muss sie drauf sein (hier ist sie es nicht)?
Stellt sie ein Risiko dar, spricht, könnte ein Nichtadmin dieses Konto impersonaten?

Diese ist im Original in der ACL des Ordners C:\Windows\System32\Config. Diese habe ich 1:1 in die GPO übernommen.
Das Problem ist ja auch nicht die ACL des Ordners sondern der Dateien darin. "Alle Anwendungspakete" wird nicht an die Dateien vererbt.

@dertowa:
Bei uns war es so gewesen, dass die BuiltIn-Gruppe "Benutzer" für die Dateien im Ordner "Config" Lese-Rechte hatte.

Es schadet nichts, das per GPO umzusetzen. Es beugt aber vor, falls Du dann morgen von diesem Szenario betroffen sein solltest.

Diese ist im Original in der ACL des Ordners C:\Windows\System32\Config.

Wie gesagt: bei mir nicht.

Das Problem kann ich sowohl auf einem einzelnen 1909 Professional, zu dem ich kein Installationsmedium habe, als auch auf neu installierten 21H1 Enterprise feststellen.
Bei den 21H1 Enterprise sind nur die als solche installierten Versionen betroffen; ebenfalls vorhandene 21H1, die von 20H2 aktualisiert worden waren, sind nicht betroffen.

Ein Blick ins Image bestätigt dies, oben 21H1 und unten 20H2:

Es handelt sich jeweils um ESD-Images des Media Creation Tools aus Dezember 2020 bzw. Juni 2021. Die Enterprise-Wim wurde zu Diagnosezwecken extrahiert.

Grüße
Richard

@dertowa: Wundern darfst Du dich gerne - ob es Panikmache ist, mag jeder selbst entscheiden. Der Umstand, dass Du nicht betroffen bist (warum auch immer, die Szenarien sind prinzipiell im Blog beschrieben, warum es bei einigen Domain-Membern nicht der Fall ist, wenn die 20H2 mal außen vor ist, weiß ich nicht), ändert nicht daran, dass der Fehler auftritt, von Microsoft bestätigt und in der Einschätzung bzw. in den Workarounds vom 20. bis 23. Juli 2021 inzwischen mehrfach revidiert wurde.

Ich stelle die Informationen im Blog ein, handeln muss jeder selbst - ist nicht mein Job, eure Arbeit zu machen. Der Bug, zusammen mit Mimikatz und Pass-the-Hash ist ein wunderbares Einfallstor, um seine Malware unter Standardkonten eine Rechteausweitung zu gewähren. Was Du dann in deinem Umfeld draus machst, ist deine Sache. Wenn Du nicht betroffen bist, fein. Inzwischen haben sich ja einige Leute gemeldet, die betroffen sind

.

Wo ich dir Recht gebe: Bisher ist kein Fall bekannt, wo das ausgenutzt wird. Falls das Kind aber irgendwann in den Brunnen gefallen ist, schauen die Betroffenen betröppelt aus der Wäsche.

Hinzu kommt, dass mein System auch beim Zugriff auf den config-Ordner Adminberechtigungen haben will.
Demnach müsste doch eine Schadsoftware die darauf abzielt auch als Admin ausgeführt werden, oder irre ich da?

Ja, da irrst du. Da die Datei SAM unterhalb von config ja stets geöffnet und somit eh gesperrt ist, erfolgt der Angriff gegen die Schattenkopie der Datei, falls es diese gibt. Und dazu sind, wenn man denn betroffen ist, keine Adminrechte erforderlich. Du kannst die SAM somit kopieren und/oder Hashes sofort verwerten, um Identitäten anzunehmen oder auch das Kennwort des lokalen Admins zu ändern. Wenn du dabei Methoden verwendest, die der Virenscanner nicht kennt, hast du gewonnen.

Nachdem man sowieso noch die VSS Kopien löschen muss, reicht das Setzen der Berechtigungen nicht aus, die alten VSS müssen auch gelöscht werden.
Hier ein kurzes (hingepfuschtes) Powershell-Skript was aber klappt. Einfach als GPO bei startup raushaun und wenn die Clients regelmäßig neu starten sollte das passen:

if([System.IO.File]::Exists("C:\temp\vssDeleteJuly2021.txt")){'already ran'}  
else{
#fix wrong acl
icacls $env:windir\system32\config\*.* /inheritance:e
#delete vss (german and english to be sure)
if((vssadmin list shadows) -Match ("Quellcomputer")){vssadmin delete shadows /for=$Env:SystemDrive /Quiet} else {'Nothing to do'}  
if((vssadmin list shadows) -Match ("Machine")){vssadmin delete shadows /for=$Env:SystemDrive /Quiet} else {'Nothing to do'}  
#place file to make sure it runs only once
New-Item C:\temp\vssDeleteJuly2021.txt
}