Users with low privileges can access sensitive Registry database files on Windows 10 and Windows 11, leaving them vulnerable to a local elevation of privilege vulnerability known as SeriousSAM or HiveNightmare.
Doesn’t sound serious? Reassured that users must already have access to the system and be able to execute code on said system to use this vulnerability? Don’t be.
Using SeriousSAM, a user can access multiple system files, including the Security Accounts Manager (SAM) database. An attacker who successfully exploited this vulnerability could run arbitrary code with SYSTEM privileges. The attacker would then have full control, which means they can install programs, view, change, or delete data, and create new accounts with full user rights. Which is exactly what an attacker wants.
My mama said
SAM stands for Security Accounts Manager and it is supposed to be a protected database that can only be accessed by users with Adminstrator privileges. This was designed as such because the database contains the hashed passwords for all users on a system.
Now, I’ve always been taught that anyone with physical access to your system, and enough knowledge, can take it over. One of the reasons why this is true is that the “holder” of the system can dump those sensitive Registry database files when Windows is not running.
When Windows is not running the registry is not “mounted” and the “access violation” protection is inactive, since to another operating system (OS) they are just files like any other. You can see the caveat there. You need to look at the files from an external OS to pull this off. (I will leave the “how to” do that to your imagination.)
While dumping a registry hive from an inactive Windows machine like that may sound daunting to some, and difficult for malware to pull off, SeriousSAM makes it much easier. SeriousSAM removes the need for that external OS, and for Windows to be off, making it a much more achievable trick. It allows users (or malicious programs inadvertently run by those users) to bypass the “access violation” protection on the computer they’re using, while it’s running.
Pass the hash
“But the passwords are hashed!”, I heard you thinking. In that case, meet pass-the-hash attacks. Windows NT LAN Manager (NTLM) is a challenge-response authentication protocol used to authenticate a client to a resource on an Active Directory domain. When the client requests access to a service associated with the domain, the service sends a challenge to the client, requiring the client to perform a mathematical operation using its authentication token, and then return the result of this operation to the service. The service may validate the result or send it to the Domain Controller (DC) for validation. If the service or DC confirm that the client’s response is correct, the service allows access to the client. Sounds secure, right? Well, the fun part is that with the hash you have enough information to perform that “mathematical operation” required to gain access. The authentication process does not require the plaintext password. The hash is enough.
So, pass the hash is the name for a technique that allows an attacker to authenticate to a remote server or service by using the hash of a user’s password, instead of requiring the associated plaintext password as is normally the case.
Made easy
The vulnerability we have been referring to as SeriousSAM is listed as CVE-2021-36934 and while it is unclear exactly which versions of Windows are vulnerable, it looks as if some versions of Windows 10 and all versions of Windows 11 are affected, as long as System Protection, aka Shadow Volumes, is enabled. The Microsoft advisory says “…we can confirm that this issue affects Windows 10 version 1809 and newer operating systems”. The company is researching the issue and we will update this post once we know more.
The vulnerability got its other name, HiveNightmare, because it affects registry hives, and as a reference to the recently discovered PrintNightmare vulnerabilities in the Windows Print Spooler service. I think it’s a better name for this vulnerability because SAM is not the only sensitive Registry database that’s affected. Others are all stored in the %windir%system32 config folder, as is SAM. They are SYSTEM, SECURITY, DEFAULT, and SOFTWARE. Which means there might be more options for hackers with limited access to raise privileges or achieve remote code execution waiting to be found.
The underlying problem is, in Microsoft’s own words “overly permissive Access Control Lists (ACLs) on multiple system files”. Those lax permissions are carried over into the Shadow copies where the files are unmounted and as unprotected as the files on the dormant computer my mother warned me about. So, any user can dump the database from the Shadow copy and as such create a readable database.
Shadow Volumes are enabled by default so that doesn’t bring the number of systems at risk down a lot. It is a useful option, but in this case it is also what enables this vulnerability.
Mitigation
While Microsoft is expected to come up with an out-of-band patch for this vulnerability, there are some things you can do to defeat the vulnerability. Whatever you do to address problem, note that fixing the cause does not necessarily fix broken permissions in shadow copies you have already taken.
You can find some useful commands for discovering if your systems have Shadow copies enabled, and whether they are vulnerable in the CERT advisory. The advisory notes that “simply having a system drive that is larger that 128GB in size and then performing a Windows Update or installing an MSI will ensure that a VSS shadow copy will be automatically created.”
Microsoft recommends restricting access to the problematic folder and deleting Volume Shadow Copy Service (VSS) shadow copies to mitigate this issue.
Restrict access to the contents of %windir%system32config
- Open Command Prompt or Windows PowerShell as an administrator.
- Run this command: icacls %windir%system32config*.* /inheritance:e
Delete Volume Shadow Copy Service (VSS) shadow copies
- Delete any System Restore points and Shadow volumes that existed prior to restricting access to
.%windir%system32config - Create a new System Restore point (if desired).
Note: Deleting shadow copies could impact restore operations, including the ability to restore data with third-party backup applications.
