HiveNightmare: Windows 10 and Windows 11 have a security vulnerability that can be exploited to gain administrative access to the registry
A local privilege escalation vulnerability has been discovered in Windows 10 that can used to gain access to otherwise inaccessible areas of the registry. In turn, this access makes it possible to discover passwords, obtain DPAPI decryption keys and more. The problem also affects Windows 11.
Dubbed HiveNightmare (because of the access it allows to registry hives), the zero-day vulnerability comes hot on the heels of the PrintNightmare security flaw. While no patch is currently available, Microsoft has provided details of a workaround in the meantime.
- After waking up from PrintNightmare, Microsoft has a workaround for another Windows Print Spooler vulnerability
- Microsoft is shipping Windows 11 in dark mode by default
- Microsoft is bringing Windows 11's game-enhancing DirectStorage feature to Windows 10
The vulnerability allows unauthorized access to very sensitive sections of the registry, specifically the Security Account Manager (SAM), SYSTEM and SECURITY hive files. A US-CERT advisory warns that the security flaw affects Windows 10 version 1809 and above, and a security researcher has found that this includes Windows 11.
- The US-CERT advisory warns of the potential impact of the flaw, pointing out a number of undesirable outcomes "including but not limited to":
- Extract and leverage account password hashes.
- Discover the original Windows installation password.
- Obtain DPAPI computer keys, which can be used to decrypt all computer private keys.
- Obtain a computer machine account, which can be used in a silver ticket attack.
The vulnerability is being tracked as CVE-2021-36934, and Microsoft describes it saying:
An elevation of privilege vulnerability exists because of overly permissive Access Control Lists (ACLs) on multiple system files, including the Security Accounts Manager (SAM) database. An attacker who successfully exploited this vulnerability could run arbitrary code with SYSTEM privileges. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. An attacker must have the ability to execute code on a victim system to exploit this vulnerability.
It was security research Jonas Lyk who discovered and shared details of the flaw, with additional work provided by Benjamin Delpy. Lyk's research also uncovered the vulnerability of Windows 11:
Microsoft shared details of the following workaround which should help mitigate against the vulnerability until a patch is produced:
Restrict access to the contents of %windir%\system32\config
- Open Command Prompt or Windows PowerShell as an administrator.
- Run this command: icacls %windir%\system32\config\*.* /inheritance:e
Delete Volume Shadow Copy Service (VSS) shadow copies
- Delete any System Restore points and Shadow volumes that existed prior to restricting access to %windir%\system32\config.
- Create a new System Restore point (if desired).
Impact of workaround Deleting shadow copies could impact restore operations, including the ability to restore data with third-party backup applications.
Note You must restrict access and delete shadow copies to prevent exploitation of this vulnerability.
The US-CERT advisory includes the following workaround:
Restrict access to sam, system, and security files and remove VSS shadow copies
Vulnerable systems can remove the Users ACL to read these sensitive files by executing the following commands:
icacls %windir%\system32\config\sam /remove "Users"
icacls %windir%\system32\config\security /remove "Users"
icacls %windir%\system32\config\system /remove "Users"
Once the ACLs have been corrected for these files, any VSS shadow copies of the system drive must be deleted to protect a system against exploitation. This can be accomplished with the following command, assuming that your system drive is c::
vssadmin delete shadows /for=c: /Quiet
Confirm that VSS shadow copies were deleted by running vssadmin list shadows again. Note that any capabilities relying on existing shadow copies, such as System Restore, will not function as expected. Newly-created shadow copies, which will contain the proper ACLs, will function as expected.