[German]Windows 10 has a serious vulnerability CVE-2021-36934 as of version 1809, which allows the Security Accounts Manager (SAM) database to be read via VSS shadow copies. This opens the door for local attackers to gain privileges from administrators and potentially move around networks. Meanwhile, the potential and scope of affected machines is becoming clearer, which is why I am publishing this follow-up article.
The HiveNightmare vulnerability CVE-2021-36934.
In yesterday's post Windows 10 upgrade breaks SAM access rights from 1809 upward, user access possible, I had published initial findings about the vulnerability in Windows discovered by security researcher Jonas Lyk. At that time, the discussion about the issue has just started between Kevin Beaumont, Benjamin Delpi and others on Twitter. I was not aware of the scope of the affected machines or the consequences of the vulnerability when I wrote the article. There has since been a lot of feedback from readers, and both Microsoft and US-CERT have issued security alerts.
Security researcher Kevin Beaumont calls the vulnerability HiveNightmare – a reference to the vulnerability in the Windows Print Spooler service known as PrintNightmare. Hive is the English name for the Windows Registry structure files. In total, there are five files SYSTEM, SECURITY, SAM, DEFAULT and SOFTWARE in the folder C:\Windows\system32\config. Beaumont had already published yesterday a tool to read the content of the Security Access Management (SAM) database.
For the vulnerability, there is discovered, that as of Windows 10 version 1809, the Access Control Lists (ACLs) with the permissions for the hive files:
will be set incorrectly in some scenarios. Then, the Users group of Windows 10 is granted read permissions to these files. If there is a volume shadow copy (VSS shadow copy) of the system drive, a non-privileged user can read these files, which is fatal, especially for the Security Accounts Manager (SAM) database.
Security warning from US-CERT and Microsoft
Since the publication of my article yesterday, Microsoft has published security advisory CVE-2021-36934. It confirms a Windows Elevation of Privilege vulnerability that allows local elevation of privilege.
– CVE-2021-36934 | Windows Elevation of Privilege Vulnerability
– Version: 1.0
– Reason for Revision: Information published.
– Originally posted: July 20, 2021
– Updated: N/A
– Aggregate CVE Severity Rating: N/A
The vulnerability that allows this elevation of privilege exists because of wrong permissive access control lists (ACLs) in several system files, including the Security Accounts Manager (SAM) database. An attacker who successfully exploited this vulnerability could execute arbitrary code with SYSTEM privileges, Microsoft said in the security advisory.
An attacker could then install programs; view, modify or delete data; or create new accounts with full user privileges. The attacker must have the ability to execute code on a victim system to exploit this vulnerability. Microsoft is not aware of an exploit, but the company is still investigating the matter.
The US-CERT security alert is much more telling. Will Dormann, who works as an analyst for CERT, has been looking into the vulnerability and has exchanged information with the security researchers mentioned above. US-CERT writes that a volume shadow copy (VSS shadow copy) of the system drive allows a non-privileged user to access these files (like the SAM), among others, which can be used for the following scenarios.
- Extract account password hashes from the SAM database using tools such as mimikatz and Pass-the-Hash and exploit them for privilege escalation
- Find out the original Windows installation password
- Find out DPAPI computer keys. These are used to decrypt all private computer keys
Captured password hashes of a computer account could be used for a silver ticket attack to move laterally (sideways) on a network. Benjamin Deply has already demonstrated on Twitter in a video what can be done with them.
Kevin Beaumont has published this article on doublepulsar.com. There he also writes that the workaround given below does not work because the VSS snapshots are read-only.
Which Windows clients are affected?
All Windows 10 versions from 1809 onwards are affected, and it doesn't matter if it's a new installation or an upgrade. This goes up to the current version 21H1 and also affects the new Windows 11. Only Windows 10 20H2 shows that new installations are not affected. This would also explain that many commentators on the articleWindows 10 upgrade breaks SAM access rights from 1809 upward, user access possible and on Facebook could not understand the vulnerability. To what extent clients are affected as members of a domain would have to be clarified by the administrators.
Are there workarounds?
German Blog reader Bernhard Diener made the suggestion yesterday on the blog in this comment, to use a batch script, running as a task with administrative privileges, to delete the VSS shadow copies with the command:
vssadmin delete shadows /all /quiet
Has the disadvantage that all VSS shadow copies are gone. In addition, the Defender can cause problems, as Bernhard states in the comment. Addendum: Within this tweet I read about collateral damages, if VSS shadow copies are deleted.
The US-CERT security article suggests as a workaround to execute the following commands in an administrative command prompt:
icacls %windir%\system32\config\sam /remove "Users"
icacls %windir%\system32\config\security /remove "Users"
icacls %windir%\system32\config\system /remove "Users"
These remove access permissions from the three hive files for the default users group. Afterwards, all VSS shadow copies of the system drive must be deleted – to prevent access to the information contained there.
Addendum: After writing the text above, Microsoft has added the following command to the workaround given within CVE-2021-36934:
icacls %windir%\system32\config\*.* /inheritance:e
This assures, that the whole folder with all objects are not accessible from standard user accounts.
German reader an former MVP Mark Heitbrink suggested to set the permissions using group policy ComputerConfiguration -> Policies-> Windows Settings -> Security Settings -> FileSystem (see this article for instance).
Cookies helps to fund this blog: Cookie settings