Windows LSA Spoofing Vulnerability **Recent assessments:** **jbaines-r7** at January 25, 2022 4:35pm UTC reported: Recently, I was attempting to combine James Forshaw’s [remote EFSRPC file write “bug”](<https://twitter.com/tiraniddo/status/1481633916507209737>) 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. ![EFS Error](https://raw.githubusercontent.com/jbaines-r7/attackerkb_images/59c51ac3e642e8a46278d0453365a79ca7fef2c5/KB5009763/efs_error.png) Which lead me to [KB5009763: EFS security hardening changes in CVE-2021-43217](<https://support.microsoft.com/en-au/topic/kb5009763-efs-security-hardening-changes-in-cve-2021-43217-719fbc9d-ad9b-4f90-a964-0afe40338002>). [CVE-2021-43217](<https://msrc.microsoft.com/update-guide/vulnerability/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: ![EFS Error](https://raw.githubusercontent.com/jbaines-r7/attackerkb_images/59c51ac3e642e8a46278d0453365a79ca7fef2c5/KB5009763/efs_warning.png) 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`](<https://docs.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-rpcbindingsetauthinfow>) 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](<https://share.vidyard.com/watch/s12ar9ni6fGLBwdnSW1ywn?>). Assessed Attacker Value: 5 Assessed Attacker Value: 5Assessed Attacker Value: 3