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
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: 12.11.2024 um 19: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
E.
Edit:
Oder wenn man eine extra GPO für nur dafür schreiben will:
Der komplette Inhalt der INF
Das entspricht:
Ergebnis:
Exakt das gleich Ergebnis, welches man mit dem von MS angegeben Workaround erreicht.
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)"
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?
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.
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.
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.@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?
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.
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.
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
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
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.Demnach müsste doch eine Schadsoftware die darauf abzielt auch als Admin ausgeführt werden, oder irre ich da?
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:
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
}