With #HiveNightmare, Windows 10 and 11 give up all user passwords

Updated 08:50BST July 2021, with Microsoft CVE, allocated overnight.

There appears to be a serious bug in Windows 10 1809 and above (including Windows 11) that lets any local user read different key registry hives and therefore access and dump the passwords of users -- across the SAM, SYSTEM, and SECURITY hives -- an extremely handy tool for escalation of privileges once the lowliest of footholds has been gained in a network by a Red Teamer or someone more maliciously minded.

(A hive is a logical group of keys, subkeys, and values in the Windows Registry -- effectively acting as a home for hashed passwords, application and network settings, system decryption keys and more).

First spotted by security researcher Jonas Lykkegaard ("Just so nobody is in doubt what this means, its EOP to SYSTEM for even sandboxed apps") and shared on Twitter, where it rapidly gained the moniker HiveNightmare, the bug lets any local non-admin user easily grab hashed passwords for all users on a system, which threat actors could break using readily available tools like John the Ripper or Hashcat to adopt the highest credentials.

Microsoft has allocated the bug CVE-2021-36934, 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."

Lykkegaard told The Stack that the find was a "random" one, saying he "did a dir list with permission and saw it while doing something else," but added that it was -- startlingly -- the third time he'd exposed a Windows update as making SAM files readable; in March 2021 spotting a similar bug in a Windows insider update and reporting it, noting at the time on Twitter that "Because I am such a nice guy - but still find the new bounties insulting - I stop it before it rools out to all Windows machines..." (He also reported CVE-2020-16938 in October 2020 for a similar issue. Microsoft users would be forgiven for wondering what is happening with QA).

HiveNightmare POC lands; security providers warn clients

As a HiveNightmare POC landed on GitHub from security researcher Kevin Beaumont ("I’ve made a version of this that drops a shell as SYSTEM by automating the remaining steps, but opting not to publish for now as it’s too EZ mode... I haven’t coded anything in C++ since 1999 so this was fun. I’m terrible at it...if you’re having imposter syndrome know that any old idiot can own Windows nowadays") Orange Cyberdefense -- one of Europe's largest security services provider -- classified an alert to enterprise clients at "level 4 out of 5".

The advisory, seen by The Stack, read: "This vulnerability allows non-administrator users to read different key registry hives and therefore the passwords of users, for example using the Volume Shadow Copy feature (also called VSS). This feature is enabled by default in some environments and useful to combat ransomware attacks by providing an always-on backup mechanism. But the SAM database can be read directly through VSS whatever the rights of the user, which allows for trivial local privilege escalation attempts. It is important to note that this vulnerability is not acknowledged by Microsoft at the time of writing this article (thus no CVE exists), but is tracked by our Managed Vulnerability Intelligence service here. Moreover, it is currently nicknamed by researchers #hivepermission or #HiveNightmare, to ride on the #PrintNightmare saga.

See also: Windows Print Spooler’s comedy of errors gets deeply serious, amid new bug, multiple attacks

Orange added: "A Proof-of-Concept is already available online. And not only SAM hives are found to be available, but also SYSTEM and SECURITY ones. It seems the versions above Windows 10 1809 may be vulnerable (according to tests by external researchers). The risk level is evaluated to high as of now, as an low-privilege account is needed and VSS turned on. But that combination exists in numerous environments."

Unlike an elevation of privileges bug in September 2019 caused by the way the SAM remote protocols established the remote procedure call (RPC) channel, this represents "a new way to access the SAM database even for non-administrator users," Orange Cyberdefense's advisory notes, "that can thus read the hashes of all local accounts on the system, through the VSS feature... the products affected by this vulnerability are the following: Win10 1809 and higher are vulnerable. Win10 1803 and earlier versions are not vulnerable. A PoC is already available online publicly on a Github repository. This alert will be updated as more information becomes available."

(Lykkegaard notes: "But the SAM database can be read directly through VSS whatever the rights of the user, which allows for trivial local privilege escalation attempts. The VSS has a copy of the SAM file with the same permissions. We can read that only because [the] permissions on original file is wrong. The original is already opened and locked because of that. Thats why we instead open the copy in VSS."

CERT/CC (part of a federally funded research and development center operated by Carnegie Mellon University) said in a write-up on July 20 that it was " currently unaware of a practical solution to this problem."

In a write-up by Will Dorrmann, CERT/CC suggested 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."