CVE-2021-36934 | HiveNightmare (SeriousSAM) and how to check if you're vulnerable

Read what HiveNightmare is all about and how to check if your endpoints are vulnerable and how to secure them.

CVE-2021-36934 | HiveNightmare (SeriousSAM) and how to check if you're vulnerable

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:

[5269608] 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:

[5269608] 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 System32\config folder.​​

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:

  1. checking, if the endpoint is vulnerable or not to CVE-2021-36934
  2. if endpoint is vulnerable: restrict access to config folder
  3. 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
[5269608] c:\cb_remediation\> put .
File uploaded

[5269608] 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

[5269608] c:\cb_remediation\> execfg powershell .\HiveNightmare.ps1
-------------------------
--System Not Vulnerable--
-------------------------

What else?

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.