0. The Issue
On 20 July 2021, Microsoft issued an alert for CVE-2021-36934 "Windows Elevation of Privilege Vulnerability". [1] The problem in this case is an overly permissive Access Control List (ACL) applied to system files, including the Security Accounts Manager (SAM) database. The workaround recommended by Microsoft is to manually fix the ACL settings and to remove VSS shadow copies on the affected system, because the shadow copies may include copies of the SAM database with the permissive ACL still applied.
The focus of this short Orbital Query Corner is how to verify ACL settings in an Orbital query.
1. The Query
Here it is:
SELECT
path, type, principal, access, inherited_from
FROM ntfs_acl_permissions
WHERE
path = (SELECT value FROM orbital_environment WHERE name = "windir") || "\System32\config" AND
principal LIKE regex_match(principal, "^((?!(SYSTEM|Administrators|TrustedInstaller|CREATOR OWNER)).)*$", 0);
We should spend a minute or two unpacking what's going on here, because there are a couple of cool things we can learn. First of all, if you've ever wondered how to use one of the Windows environment variables that point to important parts of the file system – in this case the %WINDIR% variable – here's the secret. Orbital has a special table, orbital_environment, that lets us access and use environment variables from the host. Combining the "windir" variable with the rest of the path to the affected system files lets us write proper file system queries. (Sure, the main Windows directory is usually "C:\Windows", but why risk failure in cases when it's not?)
Next, let's take a look at that regular expression (regex). Don't panic! It's not as bad as it might look at first. The important part is that we expect to find certain important entities ("security principals" to Microsoft) with access to system resources. What's less desirable is if someone else – like the general "Users" category in the case of CVE-2021-36934 is accidentally (or intentionally) granted more access than they should have. (For more information, see Microsoft's explanation of Security Principals. [2])
So, in this case, the purpose of the regex is to exclude from our query results any of the usual and expected items, like SYSTEM and Administrator. Anything that remains is something that we want to know about, and fix. ("No results for this host" is a very good answer.)
2. What About VSS?
Now that we've checked (and possibly fixed) the over-broad ACL settings, what about the second part of Microsoft's recommended remediiation, namely clearing any volume shadow copies that retain the vulnerable settings? There's a table in orbiital that we need for that, Win32_ShadowCopy, built from WMI and freshly added to Orbital in the 4.8.0 update. [3]
With that new piece in place, here's how to use it:
SELECT
DeviceObject,
VolumeName,
Win32_Volume.DriveLetter,
CASE ExposedLocally
WHEN "0" THEN "False"
ELSE "True"
END exposed_locally,
ExposedName,
ExposedPath,
CASE ExposedRemotely
WHEN "0" THEN "False"
ELSE "True"
END exposed_remotely,
ID,
DATETIME(InstallDate, "unixepoch", "UTC") AS install_date,
OriginatingMachine,
CASE Persistent
WHEN "0" THEN "False"
ELSE "True"
END persistent_across_reboots,
ServiceMachine
FROM Win32_ShadowCopy
JOIN Win32_Volume ON Win32_ShadowCopy.VolumeName=Win32_Volume.DeviceID;
Still Want More?
For further reading, we recommend the very detailed write-up of this vulnerability at CERT [4].
Credits
This article would not have been possible without the assistance of Sasha Mozil in the Research and Efficacy (RET) team, who is the source of both of the finely-crafted queries shown above.
Links and References
[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934
[2] https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-principals
[3] https://orbital.amp.cisco.com/help/updates/
[4] https://www.kb.cert.org/vuls/id/506989
