Windows “HiveNightmare” bug could leak passwords – here’s what to do!

As if one Windows Nightmare dogging all our printers were not enough…

…here’s another bug, disclosed by Microsoft on 2021-07-20, that could expose critical secrets from the Windows registry.

Denoted CVE-2021-36934, this one has variously been nicknamed HiveNightmare and SeriousSAM.

The moniker HiveNightmare comes from the fact that Windows stores its registry data in a small number of proprietary database files, known in Microsoft jargon as hives or hive files.

These hive files include a trio called SAM, SECURITY and SYSTEM, which between them include secret data including passwords and security tokens that regular users aren’t supposed to be able to access.

They’re kept in a special, and supposedly secure, folder under the Windows directory called C:\Windows\System32\config, as you see here:

C:\Windows\System32\config> dir
[. . .]
Directory of C:\Windows\System32\config
[. . .]
21/07/2021  12:57           524,288 BBI
25/06/2021  06:21            28,672 BCD-Template
21/07/2021  14:45        32,768,000 COMPONENTS
21/07/2021  12:57           786,432 DEFAULT
21/07/2021  12:32         4,194,304 DRIVERS
[. . .]
21/07/2021  12:57            65,536 SAM       <--some system secrets included
21/07/2021  12:57            32,768 SECURITY  <--some system secrets included
21/07/2021  12:57        87,556,096 SOFTWARE
21/07/2021  12:57        11,272,192 SYSTEM    <--some system secrets included
[. . .]

The moniker SeriousSAM comes from the filename SAM, which is short for Security Account Manager, a name that sounds as serious as the file’s content’s are.

If you have ever used password cracking or hacking tools (or found evidence of them on your network after detecting an active attack), you’ll know that the SAM database is where many cybercriminals start digging in order to try to get hold of administrator credentials to move around your network.

Fortunately, you need to have Administrator access already in order to get at the SAM data in memory, and you can’t get at the SAM registry hive on disk while Windows is running even if you are an Administrator, because the SAM file shown above is locked for the exclusive use of the operating system.

So far, so good.

Who can see what?

We wrote a tiny C program that you can use to get an “accessibility indicator” for any file on the system – it simply tries to open the filename or filenames you put on the command line, and reports the Windows error code if the file couldn’t be opened up for read access.

(The code below is in the public domain so you can do what you like with it, but you use it at your own risk.)

You don’t even need the Windows header files to compile it; you just need to tell your compiler or linker that it needs kernel32.dll and msvcrt.dll:

/* --- CHKIT.C --- */

void     *CreateFileA(char *name,unsigned mode,unsigned share,void *sec,unsigned disp,unsigned attr,void *tmpl);
int      CloseHandle(void *hnd);
unsigned GetLastError(void);
int      printf(char *fmt, ...);

int main(int argc, char **argv) {
   for (int i = 1; i < argc; i++) {
      printf("Opening file [%s]\n",argv[i]);
      void *hnd = CreateFileA(argv[i],0x80000000L,0,0,3,0x80,0);
      if ((long int)hnd == -1) {
         printf("Failed (GetLastError=0x%08X)\n",GetLastError());
      } else {
         printf("Worked (handle=%ld)\n",(long int)hnd);
         CloseHandle(hnd);
      }
   }
   return 0;
}

From an elevated command prompt (one that is running with Administrator privilege), we get the following result:

C:\Users\duck> chkit C:\Windows\System32\config\SAM C:\Windows\System32\config\SYSTEM C:\Windows\System32\config\SECURITY
Opening file [C:\Windows\System32\config\SAM]
Failed (GetLastError=0x00000020)
Opening file [C:\Windows\System32\config\SYSTEM]
Failed (GetLastError=0x00000020)
Opening file [C:\Windows\System32\config\SECURITY]
Failed (GetLastError=0x00000020)

Error 0x20 stands for ERROR_SHARING_VIOLATION, described officially by Microsoft as “The process cannot access the file because it is being used by another process.”

So far, still good.

Let’s try again from a non-elevated command prompt, where we’re running as a regular user:

C:\Users\duck> chkit C:\Windows\System32\config\SAM
Opening file [C:\Windows\System32\config\SAM]
Failed (GetLastError=0x00000020)

Ooooer! That can’t be right!

We should have received Error 0x05, short for the self-explanatory ERROR_ACCESS_DENIED, right away.

Seeing Error 0x20 means that the program was allowed to have a go at opening the file, and failed at that point, instead of being blocked from even trying to access the file in the first place.

And if we look at the ACL (access control list) for the SAM hive file, for instance, using the ICACLS utility, we see that this behaviour is down to a security blunder:

C:\Windows\System32> icacls config\SAM
config\SAM BUILTIN\Administrators:(I)(F)
           NT AUTHORITY\SYSTEM:(I)(F)
           BUILTIN\Users:(I)(RX)    <-- this is wrong - regular users should not have read access!
           APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
           APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

In other words, the SAM registry data (and the SECURITY and SYSTEM hive files, too) are protected at runtime against access by regular users because the files are in use elsewhere, not because the files are off-limits to regular users from the outset.

We need to fix that vulnerability, and Microsoft’s official workaround is to restrict the access control lists (ACLs) on everything in and below the CONFIG directory.

You need to be Administrator, and to make the following security change:

C:\Users\duck> icacls %windir%\system32\config\*.* /inheritance:e
processed file: C:\Windows\system32\config\BBI
[. . .]
processed file: C:\Windows\system32\config\SAM
[. . .]
processed file: C:\Windows\system32\config\SECURITY
[. . .]
processed file: C:\Windows\system32\config\SYSTEM
[. . .]
Successfully processed 45 files; Failed processing 0 files

Now, the ACL for the SAM file that we checked above looks much healthier:

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

Also, if we try to open the live SAM registry hive file again from a non-Administrator command prompt, we no longer get Error 0x20.

We now get the more security-conscious Error 0x05, telling us ACCESS_DENIED:

C:\Users\duck> chkit C:\Windows\System32\config\SAM
Opening file [C:\Windows\System32\config\SAM]
Failed (GetLastError=0x00000005)

Still not done!

But that alone is not enough.

If you have any system restore points (also known as Volume Shadow Copies) on your computer, those restore points include copies of your original SAM, SECURITY and SYSTEM registry hive file with the old and insecure access control settings.

C:\Users\duck> vssadmin list shadows

vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Contents of shadow copy set ID: {. . .}
   Contained 1 shadow copies at creation time: 21/07/2021 14:58:05
      Shadow Copy ID: {. . .}
         Original Volume: (C:)\\?\Volume{. . .}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2  <--this is the directory tree where the shadow file copies can be found
         Originating Machine: W10
         Service Machine: W10
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessibleWriters
         Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\System32\config

C:\Users\duck> chkit \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\System32\config\SAM
Opening file [\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\System32\config\SAM]
Worked (handle=136)

C:\Users\duck> vssadmin delete shadows /all
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Do you really want to delete 1 shadow copies (Y/N): [N]? y

Successfully deleted 1 shadow copies.