There’s a Severe Privilege Escalation Vulnerability in Windows RPC Protocol That Microsoft Won’t Fix

• SentinelOne researchers have found what they call a “permanent zero-day” privilege escalation on Windows RPC.
• The discovery and initial report happened back in November 2020, but Microsoft decided not to address this.
• There are some mitigations that can be applied to harden your server, which will do the trick even without a patch.

Researchers at SentinelOne warn about a severe privilege escalation flaw affecting all Windows systems, which is reportedly not in Microsoft’s patching plans. According to the detailed write-up of the Italian researchers who have made the discovery, it is practically possible to trigger an authenticated RPC/DCOM call and relay the NTLM authentication to other protocols, launching a man-in-the-middle (MITM) attack and capture everything that flies back and forth. For this to work, it would be enough for the attacker to be a low-privileged user with limited rights on the target machine.

The eight steps to exploit the capability to launch the cross-protocol mayhem are given below:

1. An attacker has a shell in Session 0 on the “victim” machine with a low privileged account;
2. On this machine, a privileged user, like a Domain Admin, is logged on interactively;
3. The attacker triggers the DCOM activation service by unmarshalling an IStorage object, calling CoGetInstanceFromIstorage with one of the CLSIDs that impersonate the user logged on interactively and setting the IP of the attacker machine for Oxid resolution requests;
4. The attacker implements a MITM by just listening on port 135 on his machine, which will receive the IObjectExporter::ResolveOxid2 authenticated call and be forwarded to the “fake” Oxid resolver. Even if this call is authenticated, the NTLM “Sign flag” is set so it will be skipped;
5. The fake Oxid resolver returns a string binding for an RPC endpoint under the attacker’s control;
6. The victim machine/user will make an authenticated call IRemUnknown2::RemRelease contacting the RPC server (without the Sign flag set);
7. Authentication will be relayed to a privileged resource such as LDAP, SMB, HTTP, or other.
8. Implemented the whole logic of the MITM and HTTP encapsulator in a POC (RemotePotato0). Then forward everything to ntlmrelayx and let it do the job by targeting the LDAP server running on the Domain Controller and adding a new domain admin (or elevate user privileges).

The researchers have even released a short demonstration of a proof of concept, as shown below. Source code for the PoC is also available on this GitHub repository.

If you’re wondering why Microsoft isn’t planning to fix this, the official explanation is that “Servers must defend themselves against NTLM relay attacks,” so the software giant finds this to be outside the scope of its responsibility. The researchers note that simply setting the sign flag in the NTLM provider as well as SPNEGO would have inhibited this exploit, so it appears that Microsoft simply wants to avoid creating a burdening precedent here.

If you’re worried about this flaw and its interaction-less exploitation potential, there are some things you can do to mitigate it. SentinelOne suggests the following:

• For HTTP(S), you should remove all non-TLS-protected HTTP bindings (prefer SSL everywhere, particularly where NTLM is used) and configure Channel Binding Tokens validation by setting the tokenChecking attribute to a minimum of Allow (if not Require).
• For LDAP, you should set the Domain controller: LDAP server signing requirements Group Policy to Require signature for non-LDAPS LDAP connections.
• Set the Domain controller: LDAP server channel binding token requirements Group Policy to a minimum of When Supported (if not Always).
• For SMB, you should configure SMB Signing by setting the Group Policy Digitally sign server communication (always).

This flaw was discovered in November 2020, so it’s been a while already. The researchers hadn’t disclosed it on February 2021, when the 90-day disclosure was reached, as Microsoft initially asked them to wait until April 13, 2021, which would be when the promised fix would land. SentinelOne agreed with this, but Microsoft changed its mind when its engineers looked deeper into this, and so the disclosure came.