CVE-2021-36934 (HiveNightmare / SeriousSAM)

Topic

New Reply

[WCHS]

I have some questions about the update guide for CVE-2021-36934 (aka HiveNightmare/SeriousSAM) posted at <here>

1. If I understand the guidance, the first operation is to restrict access and the second operation is to delete the shadow copies. Is the order important?

2. I read the Caution statement which says

Restoring your system from a backup could restore the overly permissive ACLs and therefore revert your system to a vulnerable state. After restoring a backup, you must verify that the ACLs are correct to ensure that the restore operation did not reintroduce this vulnerability.

a) What does “restoring your system from a backup” mean – i) does this refer to restoring the system backup image? ii) Or does this refer to a complete restore of files and folders (in contrast to the system files)? iii) what about restoring a single folder or a single file (in contrast to all of the files and folders)?

b) How does one verify that the ACLs are correct?

3. If you have restricted access and have deleted shadow copies, and then you follow that with a backup that creates a system image, backups files and folders (most likely they will be files and folders since the last backup), and also creates shadow copies, is that later backup (of system image, of lately modified files/folders, and newly created shadow copies) “good” for restoring, whether it be a system image, all files and folders (including those that were backed up before the work-around), some files and folders (including those that were backed up before the work-around), or a shadow copy of a file (I presume that no shadow copy will have a date that precedes this new backup date)?

• This topic was modified 3 years, 9 months ago by WCHS.

Reply | Quote

Replies

You take a backup of your system on say 7/28.  You then make the changes to fix up the permissions. Later on you realize you need to restore your computer. If you restore from a backup, it will inherit the looser permissions and you’ll have to redo it. As I read it, it’s a full restore, not a “file” on your system that triggers the permissions.

To check  the ACLS, run those testing commands again. VU#506989 – Microsoft Windows 10 gives unprivileged user access to system32\config files (cert.org)

As I’m understanding it, yes a new backup with the new permissions would be fine.

Susan Bradley Patch Lady/Prudent patcher

1 user thanked author for this post.

windbg

Reply | Quote

Let’s see if I get this straight:
Let’s say that on 7/29 I fix the permission problem by running those two commands 1) to restrict access and 2) to delete shadow copies. Then, let’s say I make a new system image and I do a new backup of files and folders.

So, now down the road (let’s say on 7/30), I can restore the new system image or restore the files and folders (some or all) or retrieve a previous version of a file or folder (i.e., access a shadow copy) – all without exposure to the vulnerability?

Reply | Quote

That’s my understanding, yes.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

As far as checking the ACLs, one of those commands does not work:
It’s icacls %windir%\system32\config\sam

It looks like it’s looking for something named ‘icacls’, but there is no directory ‘sam’ or ‘SAM’. There is a file SAM, but it’s not a directory.

Consequently, I get the message that the path doesn’t exist.

I’ve also tried the command in non-administrative PowerShell, too. Same results.
I do have shadow copies as revealed by vssadmin list shadows

Reply | Quote

Not Powershell, but use command line or cmd.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

Using the non-elevated command prompt to check ACLs, I get the same thing as shown below in #2380736 – PowerShell

The non-elevated command prompt was icacls %windir%\system32\config\sam

Again, there’s no line that says BUILTIN\USERS: (I) (RX) nor are there two lines that say anything about APPLICATION PACKAGE AUTHORITY, as cert.org says there should be.

Reply | Quote

I tried something else, using PS non-admin. First, I changed the directory to C:\, and then I used the command icacls Windows\system32\config\sam. Here it is: (I’ve covered up the info about my real computer name and my real username.)

In my output, there’s no line that says BUILTIN\USERS: (I) (RX) nor are there two lines that say anything about APPLICATION PACKAGE AUTHORITY, as cert.org says there should be.

So, I am at a loss as to how to check the ACLs.

Reply | Quote

Don’t use powershell. Use command line.  Black background, not blue

 

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

Susan Bradley wrote:

Don’t use powershell. Use command line. Black background, not blue

Yes, I realize now that there’s a difference (command prompt vs PS command), but the command prompt doesn’t yield the kind of output that cert.org says I should get.

Reply | Quote

You should get either:

Vulnerable:
C:\Windows\system32\config\sam BUILTIN\Administrators:(I)(F)
                               NT AUTHORITY\SYSTEM:(I)(F)
                               BUILTIN\Users:(I)(RX)
                               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

Or this:  Non vulneable

C:\Windows\system32\config\sam: Access is denied.
Successfully processed 0 files; Failed processing 1 files

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

But I get neither!!

Reply | Quote

Using an elevated Administrator command prompt type: whoami

What is the result of: icacls %windir%\system32\config

Do you see that third account listed in the output?

Reply | Quote

anonymous wrote:

Using an elevated Administrator command prompt type: whoami

What is the result of: icacls %windir%\system32\config

Do you see that third account listed in the output?

I think I understand your questions. Here are my answers.

whoami produces mycomputername\mypersonalfoldername (these are cover terms for my actual computer name and my actual personal folder name)

This mycomputername\
mypersonalfoldername is the same string that I see in what you are calling the third account in the icacls %windir%\system32\config\sam output (see the image <here>).

This laptop dates back to 2016 (i7-6500U-Skylake U). It came with version 1607, then updated to 1703, 1709, 1803, 1809, 1903, 1909, and now 20H2. (I skipped 2004).

DIFFERENCE WHEN COMPARED TO MY NEWER LAPTOP
I have a newer laptop which dates back to 2019 (i7-8565U-Whiskey Lake U). It came with version 1903, and I have updated to 1909 and 20H2. (Again I skipped 2004). The two machines have been treated pretty much the same as far as files and folders, file structure, apps, even down to the Desktop. In other words, whatever is on one is on the other and in pretty much the same place. Both are by the same manufacturer, both are up-to-date on OEM drivers, OEM BIOS, both are up-to-date on Patch Tuesday CUs through June and I’ve never installed Previews on either one, just CUs. Both use the same A/V software. Settings on the two machines are the same (at least that’s the intent, although I haven’t drilled down to EVERY setting ANYWHERE to confirm that). Group Policy is the same (both are Pro). The only difference in the devices that I can identify is their version histories — the older one started out on 1607 (which means that it once had HOMEGROUP or HomeUsers) and the newer one started out on 1903 (and never had HOMEGROUP or HomeUsers).

On this newer machine, I did a whoami. Result is the same mycomputername\
mypersonalfoldername although the actual names for the computer and the personal folder are particular to that device. The output for icacls %windir%\system32\config\sam is as cert.org say it would be if it’s vulnerable: i.e., third line says BUILTIN\Users: (I)(RX), fourth and fifth lines say something about APPLICATION PACKAGE AUTHORITY …

So, the older machine is yielding an unexpected icacls output. But, I don’t know what to make of it.

Reply | Quote

Another difference that I forgot to mention is that the older computer, which started out under version 1607, is connected to an MS account, so under folder Properties>Security will be SYSTEM, Firstname Lastname (my e-mail address), Administrators, and sometimes HomeUsers (for folders created before version 1903).

The newer computer, which started out with version 1903, is on a local account, so under folder Properties>Security there is SYSTEM,
Mypersonalfoldername (Mycomputername\mypersonalfoldername), and Administrators

Reply | Quote

Thank you for your replies, this is strange indeed…

What is the result of: icacls %windir%\system32\config

Please retry that command exactly as you see it, but do not add anything to it. I was curious if the computername\username was also among the listed permissions for the config directory. Admittedly the answer may enlighten us or not, Thank you.

Do these computers have any OEM utilies, such as a support assistant?

Reply | Quote

Maybe you have found another one of Microsoft ‘s bug that requires repair.

Reply | Quote

By any chance have you used any sort of “decrapifyer” tool to remove Microsoft store or other cleaner tools?

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

no decrapifiers — no cleaners, Microsoft Store is active. The only removal tool I have used is Microsoft’s Flash-Removal tool, but that was a Windows Update.

Reply | Quote

Susan Bradley wrote:

Don’t use powershell. Use command line.  Black background, not blue

 

Unfortunately that’s not 100% accurate:

An apparent non-elevated PowerShell console… which is actually a non-elevated commandline console, yet with a blue background.

IMO when you enter cmd into a PowerShell console the background should change colour automatically as a visual aid. 🙂

Reply | Quote

You should get an access denied error trying to view the ACLS (permissions) from a standard user account after application of Microsoft’s mitigation.

icacls will display help text with no parameters it may help you understand the symbols use for permissions, some of them are not intuitive.

Reply | Quote

a) What does “restoring your system from a backup” mean – i) does this refer to restoring the system backup image? ii) Or does this refer to a complete restore of files and folders (in contrast to the system files)? iii) what about restoring a single folder or a single file (in contrast to all of the files and folders)?

a)
i) Yes, the affected config directory and files will be in the currently old unpatched image backups.
ii & iii) No, not with regular user files this issue does not affect them. But if you happen restore the affected windows\system32\config directory and/or files that are inside the config directory from an old unpatched backup it will revert to the defective state. You will have to reapply the mitigation.

b) In an elevated Administrator PowerShell window type: icacls $env:windir\system32\config\*.*
Or an elevated Administrator command prompt window: icacls %windir%\system32\config\*.*

Before mitigation this set of permissions is what you will see for all the files in the config directory: BUILTIN\Users:(I)(RX)
After mitigation is applied you should see that the normal builtin Users account do not have any permissions.

3) If you create a new image after the mitigation step you should be okay if you have to restore that disk image. Clearly add a comment about this mitigation to the fresh image backup.

Also, thank you for reminding me to apply this mitigation.

Reply | Quote

anonymous wrote:

Or an elevated Administrator command prompt window: icacls %windir%system32config*.*

After processing 69 files, that elevated Administrator command prompt, yields nothing nowhere that says “BUILTIN\USERS: (I) (RX)” nor anything about APPLICATION PACKAGE AUTHORITY, as cert.org says there should be.

Nor does that command prompt say “Access denied”, as cert.org says would show up, if the system is not vulnerable.

The output is essentially the same as the image in my other posts: 3 lines keep repeating, file by file:
1. NT AUTHORITY\SYSTEM: (I)(F)
2 BUILTIN\ADMINISTRATORS: (I)(F)
3. MYCOMPUTERNAME\myusername: (I)(F)

Reply | Quote

Versions of Windows 10 from 1809 forward may be different but only the System account or Administrators should have permissions listed, if the third account is an Administrator it is possible to remove that account’s permissions using icacls.

Reply | Quote

WCHS wrote:

The output is essentially the same as the image in my other posts: 3 lines keep repeating

Your permissions are not correct on the CONFIG directory, and probably not on the rest of the Windows directories. Why this has occurred we don’t know.

If you are concerned about the vulnerability, I would create an image backup and then apply the MS workaround.
If it is a personal system that you keep up to date and clean, it may be better to leave it alone and wait for MS to fix it properly.

If you want to fix the permissions you will need to reinstall Windows. An “over the top” installation may fix it, otherwise it’s full reinstall including all software.

cheers, Paul

Reply | Quote

Paul T wrote:

If it is a personal system that you keep up to date and clean, it may be better to leave it alone and wait for MS to fix it properly.

Has there been a fix for the CVE-2021-36934 (HiveNightmare / SeriousSAM) bug yet?

Reply | Quote

WCHS wrote:

Has there been a fix for the CVE-2021-36934 (HiveNightmare / SeriousSAM) bug yet?

Yes: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934

1 user thanked author for this post.

WCHS

Reply | Quote

I have read the document at the link @b provided and I have also read KB5005357 – Delete Volume Shadow Copies.

I am Win10/Pro, 21H1. Before installing the monthly CUs, I have been using Backup and Restore (Windows 7) to back up my Libraries and my C:\USERS folders & files and to make a system image, all of which are kept on a USB external drive.

AS FOR MY LAPTOP, I have just issued the Command Prompt vssadmin list shadows /for=%systemdrive% and the results show that I have Volume Shadow copies. In addition, if I right-click on a Libraries file or a C:\USERS file whose time stamp is before the last B&R-7 backup, there are ‘Previous versions’ that I can restore. I believe that both the Volume Shadow copies and the ‘previous versions’ are on my laptop because B&R-7 put them there.

AS FOR MY EXTERNAL DRIVE, as I understand it, my B&R-7 Libraries folders & files and C:\USERS folders & files are not vulnerable because the bug concerns system files. But, as I understand it, the system files are a part of the B&R-7 system image and hence, those system files are vulnerable to CVE-2021-36934 (HiveNightmare) because the permissions on the B&R-7 system files are still unrestricted. Since B&R-7 always erases (or overwrites) the old system image on the external drive and replaces it with the newest one, that means that the currently newest system image is still vulnerable to the bug and should not be used for a System Restore. But, I need to have a system image that has restricted permissions on the system files.

That means that I need to figure out how to run B&R-7 BEFORE installing the August Tuesday Patch KB5005033 but also AFTER solving the CVE problem.

I think the solution can be found in this Command Prompt, which will restrict system permissions and will, I think, do the same thing that KB5005033 does:
icacls %windir%\system32\config\*.* /inheritance:e

So, I am thinking that I could do this:
1. Delete the Volume Shadow Copies with this Command Prompt:
vssadmin delete shadows /for=%systemdrive% /Quiet

2. Check to be sure all Volume Shadow copies have been deleted with this Command Prompt:
vssadmin list shadows /for=%systemdrive%

3. Issue this Command Prompt to restrict permissions:
icacls %windir%\system32\config\*.* /inheritance:e

4. Run Backup and Restore (Windows 7) to back up my Libraries and C:\USERS and make a new system image. System files in the system image backup will now have the restricted permissions they are supposed to have.

5. Unhide and install KB5005033 so that my monthly Tuesday CUs are up-to-date.

Does this sound like the correct approach??

Reply | Quote

Yes, but use your system after installing KB5005033 to see that there are no problems.

Reply | Quote

WCHS wrote:

Does this sound like the correct approach?

An alternative is to make a backup using one of the free 3rd party apps. These allow you to keep as many backups as you require, but you may need a new disk if B&R-7 might clobber the files. Moving to the 3rd party backup and abandoning B&R-7 is also a possibility.

cheers, Paul

Reply | Quote

Yes, I know that you always tell me that. Some time ago, I’ve tried one of your suggestions for a 3rd-party app (Aoemi). It deleted the data in every partition except the C:\ partition and the EFI partition. The partitions whose data were deleted were OEM partitions that held a system image, WINRETOOLS, and DELLSUPPORT.

I’ve become familiar with B&R-7, I know how to use it, and I feel comfortable using it. I know many users feel it is out-moded, clumsy, awkward, etc, but it has worked for me. I don’t think this CVE thing has to be ‘the straw that broke the camel’s back’, thereby forcing me to use a 3rd party app.

I’m asking if using the ‘icacls’ command before running B&R-7 will fix the CVE problem so that I can get a good system image before installing the August patches.

I am not asking for advice to use a 3rd party app.

Reply | Quote

Stepping back from the specifics here, I’m on 21H1 and up to date. If I tried meddling anywhere near the shadow volume copies when the method was first postulated prior to the release of the  fix “package” Windows defender blocked the activity (sorry, the exact definition invoked is now gone from protection history..) as the Windows defender definitions updated almost immediately so I couldn’t even see if Serious SAM worked.

Post this month’s cumulative update, the folder itself seems to no longer be present in ShadowCopy1 location, as the shadow copy service is now set to manual and is not running, so Microsoft may have done a belt and braces fix and turned off the service as well as clearing the copies. That is to say you could be trying to fix a problem which now doesn’t exist..

For this problem it could actually be more risky to have a backup with the current  passwords in it, as unless they’ve tweaked Windows 7 recovery for it re-use in Windows 10, the backups are in “open” zip files from what I recall, so malware could potentially still find the backup registry hives if you leave the backup drive connected, and those files will be accessible as they’re not in use so the shadow copy status would be irrelevant. If you’re lucky setting a backup password might encrypt the backup files but perhaps check your backup through explorer and see what you can find just in case.

Reply | Quote

oldguy wrote:

Stepping back from the specifics here, …
That is to say you could be trying to fix a problem which now doesn’t exist..

I guess you did step back from the specifics.  I haven’t installed the August Tuesday patch yet.  I want to do a B&R-7 backup before I do that.  Why?  b/c I want a good system image that has restricted permission system files, in case something goes wrong with the August patch.  So, how do I  get a good system image?  I think the answer is to do the ‘icacls’ command before running B&R-7 and before installing the August Tuesday patch.

I don’t leave my backup drive connected. It is connected only when I decide to do a B&R-7 backup.
I don’t use B&R-7 to backup system files in zip files. Only my Libraries and folders & files under C:\USER are backed up in zip files.

So, you say your August patch cleared your Volume Shadow copies? If so, does that mean that every monthly CU going forward will also clear Volume Shadow copies?

So, the problem of unrestricted permissions on the system files in the system image still exists at the moment b/c cause I haven’t installed the August Tuesday patch yet. 

Reply | Quote

I have nothing to save so I just let Microsoft patching do it’s thing and see what breaks. It hasn’t so far.

I spent years scraping what was left of data from machines and reinstating them, so really I was just intending to point out a hole in performing a backup that way for those people who might not realise it’s there (as Windows can search inside ZIP files by default, and malware can use that). You have to mount WIM, FFU files before you can get at the content without specific tooling.

That said I did see one Acer where I had to reinstall from DVD (fortunately had one from a similar enough system) as in checking I found the ransomware had “interfered” with one of the WIM files in the recovery area (but for some reason didn’t then go to the trouble of setting the date right!)

To the ends of backing up your system if it has crashed and burned to a point where mounting the file system is all that’s possible, I thought I would share a way you can boot to the command prompt of a Windows 10 DVD and (assuming you have supplied any bitlocker credentials required, and your machine is in UEFI mode with a GPT partition layout so Windows is on drive C, and let’s say in this instance your external drive is drive f.. plug it in after starting the command prompt and wait, to avoid any BIOS support letter assignment strangeness.)

The sequence is:

md f:\dismbackup

md f:\dismbackup\todaysdate

DISM.exe /Capture-Image /ImageFile:f:\dismbackup\todaysdate\backup.wim /CaptureDir:c:\users /name:backup

DISM.exe /Apply-Image /ImageFile:f:\backup.wim /Index:1 /ApplyDir:f:\dismbackup\todaysdate

Note the folder nesting is for a reason – things will get confusing for the GUI if you extract the archive to a folder in the root of the drive (special attributes – will always be called “users” for one, so that can look  odd on a freshly installed machine which has a real one as well.). Of course you will also need to take ownership of the files in the location formerly f:\dismbackup\todaysdate on a suitable machine on which you are presumably checking you have your files before starting over.

The obvious no brainer here is you can’t just restore the users folder to the original installation this way as the user registry is inside it and doing so at best can cause strange things to happen (at worst you need to reinstall!)

If you wanted a whole system backup you need to look at partitioning and imaging all bar the MSR (reserved) partition, or into if using Syspep causes you issues (bar creating an extra account you can kill later) as in if it doesn’t, you can look into imaging a FFU disk image using DISM, for which that is a requirement.

As you need to attain control of the local machine to exploit serious SAM I would have thought patching and protection might be more in the foreground, unless of course your machine is in a more “hostile” environment in which case locking out the boot menu and bitlockering (setting a security block on that applet for users other than your account) as if you can get to the hard disk via recovery media you can flip the bit in the SAM file to enable the actual built in administrator account for use. I’m guessing you knew that and have enabled the account concerned, set a password and disabled it again if you needed that level of security, so I’ll probably say no more on this thread.

As said, these are comments are for all…  not suggesting you specifically need to do anything at all,  but someone might find it useful.

 

Reply | Quote

Thanks for all of your information. I am not at that point right now, at least I hope not.

My machine is working fine, pre-August Patch Tuesday updates. I always call upon Backup and Restore (Windows 7) to do a backup (of C:\USER and my Libraries) and I also always do a system image prior to installing these Week B patches.

Right now, I am wondering how I can make the system files in the system image “good” before I do (in this order): 1) a B&R-7 backup of C:\USERS and my Libraries; and 2) the installation of KB5005033 (the August Patch Tuesday patch).
So, I’m wondering if the icacls command will do that (i.e., make the system image “good”) before I do 1) and 2).

P.S. Making the system files in the system image “good” via the icacls command means restricting the permissions on system files according to the arguments of the icacls command as laid out in workarounds of https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934 (i.e., #3 of #2386342).

Reply | Quote

It’s the right tool but it’s pretty powerful meddling with hive properties. For example simply making the default hive read only with Attrib stops another user in a domain setting logging into another machine in their workgroup they shouldn’t use (no new account can be created as a read only hive file can’t be populated by the out of box process so the account won’t load) and doing the same to an existing  user hive will stop the logon service letting them log in if they have previously (we did this some way back on 1706 but guessing it might still work..). You can go as far as you like with this

Here’s what my SAM has :

SAM NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)

The icacls method is here: (half way down) – I can’t see a reason you can’t use it from the recovery console if you really have to.

https://www.bleepingcomputer.com/news/microsoft/new-windows-10-vulnerability-allows-anyone-to-get-admin-privileges/

 

Reply | Quote