On the 20th of July 2021 Microsoft announced that "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." This 0-day vulnerability affects Windows 10 version 1809 and newer, Windows Servers seem not to be affected.
Background: Windows 10 stores its registry data in a small number of proprietary database files, also known as hives. Hive files are normally located in
C:\Windows\System32\config and this directory is normally restricted, so regular users aren't able to use it. As we're interested, let's have a look into this directory through Carbon Black LiveResponse:
 C:\Windows\system32\config\> ls Directory of C:\Windows\system32\config\ 07/21/2021 08:36 AM GMT <DIR> . 07/21/2021 08:36 AM GMT <DIR> .. 07/25/2021 02:28 PM GMT 1048576 BBI 06/25/2021 04:46 PM GMT 28672 BCD-Template 07/21/2021 08:36 AM GMT 30146560 COMPONENTS 07/25/2021 02:28 PM GMT 1048576 DEFAULT 07/26/2021 09:54 PM GMT 4194304 DRIVERS 11/19/2020 07:41 AM GMT 32768 ELAM 07/25/2021 02:28 PM GMT 65536 SAM 07/25/2021 02:28 PM GMT 32768 SECURITY 07/26/2021 09:49 PM GMT 96468992 SOFTWARE 07/25/2021 02:28 PM GMT 13631488 SYSTEM 12/07/2019 09:14 AM GMT <DIR> systemprofile 06/25/2021 03:48 PM GMT <DIR> TxR
Note: I deleted logfiles and temp files from the output to avoid too much noise.
The file we now want to focus on is the
SAM file. SAM is an acronym for Security Account Manager, which stores and organizes information about each user on a system. It stores sensitive security information, such as hashed user and admin credentials and this is why attackers often try to dig deeper into this file to gain credentials out of it. Normally the SAM file is locked while windows is running and is reserved for the OS only. So also an administrator cannot access it. But that's just in theory! If we check the access control list (through the
ICACLS utility) for that file, we directly see that something is not correct:
 C:\Windows\system32\config\> icacls SAM config\SAM BUILTIN\Administrators:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Users:(I)(RX) Successfully processed 1 files; Failed processing 0 files
Interesting here is now that BUILTIN\Users have read access for the
SAM file, so what blocks a normal from accessing it, isn't the permission but the situation that windows blocks access during OS runtime (as it's using the file itself).
How to fix it
There is no official fix provided by Microsoft yet but they're providing a temporary walkaround. You need to restrict access to all files in the
System32\config folder so only priviliged users or the system have access to it's content. Login to the endpoint, open an administrative command prompt and run:
icacls %windir%\system32\config\*.* /inheritance:e
This will set the inheritance level (
/inheritence:e enables it) and provides the ACL for the config folder.
We can validate, if the ACL was set correctly by checking the permissions again:
C:\Windows\System32> icacls config\SAM config\SAM NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) Successfully processed 1 files; Failed processing 0 files
But that's not it! When your endpoints have Volume Shadow Copies (VSS) enabled (also known as restore points), the system can be restored to a previous state where the correct ACL isn't set. In other words: any unprivileged user could just read out data such as your Windows access control secrets or password hashes from the shadow copies instead. So check for existing volume shadow copies by running
vssadmin list shadows and check if some exist. If so, delete them. As new shadow copies are created they will have the appropriate permissions to not allow privilege users access to the files in the
The fast & easy way
At VMware Carbon Black we do our best to stop breaches and prevent them before they even occur. Our Threat Analyst Unit (ΤAU) provides a HiveNightmare powershell script, you can run via LiveResponse or locally on any endpoint. Let's break down, what the script does:
- checking, if the endpoint is vulnerable or not to CVE-2021-36934
- if endpoint is vulnerable: restrict access to
- delete automatically all volume shadow copies
Warning: Before running the script and removing the shadow copies, customers should weigh the risk of deleting potential back-ups versus removing copies of system files that could be accessible by unprivileged user accounts.
You can run the script locally on your endpoint or through Carbon Black LiveResponse:
Live Response for device 5269608  c:\cb_remediation\> put . File uploaded  c:\cb_remediation\> ls Directory of c:\cb_remediation\ 07/27/2021 03:31 PM GMT <DIR> . 07/27/2021 03:31 PM GMT <DIR> .. 07/27/2021 03:31 PM GMT 3770 HiveNightmare.ps1  c:\cb_remediation\> execfg powershell .\HiveNightmare.ps1 ------------------------- --System Not Vulnerable-- -------------------------
I'm currently working on a LiveQuery to check for vulnerable systems and playing around with Enterprise EDR to get more insights about potential exploited volume shadow copies.