by Mitja Kolsek, the 0patch Team
Update 1/19/2022: User informed us that our initial micropatch for this issue broke Windows Hello PIN settings (not the login, but creating or editing the PIN). We analyzed the issue and found that our initial test for requestor's permissions was causing the problem in this case. We therefore revoked the initial patches and issued new ones where we check for requestor's permissions using token's TokenIsElevated value.
Update 3/17/2022: March 2022 Windows Updates modified rpcss.dll on some Windows versions, so we ported our micropatch to these new versions. This vulnerability was presented to Microsoft employees at the Microsoft BlueHat Israel conference.
Update 6/27/2022: We've ported our patches for this issue to current versions of supported Windows platforms. Given that Microsoft does not plan to patch authenticated credentials relaying issues, these patches are now available only to PRO and Enterprise accounts.
Back in April 2021, researcher Antonio Cocomazzi of Sentinel LABS and independent security researcher Andrea Pierini published an article titled Relaying Potatoes: Another Unexpected Privilege Escalation Vulnerability in Windows RPC Protocol. The article described a local privilege escalation vulnerability they had found in Windows and reported to Microsoft, who decided not to fix because "Servers must defend themselves against NTLM relay attacks."
As far as real world goes, many servers do not, in fact, defend themselves against NTLM relay attacks. Since the vulnerability is present on all supported Windows versions as of today (as well as all unsupported versions which we had security-adopted), we decided to fix it ourselves.
The vulnerability is comprehensively described in the Sentinel LABS article. It allows a logged-in low-privileged attacker to launch one of several special-purpose applications in the session of any other user who is also currently logged in to the same computer, and make that application send said user's NTLM hash to an IP address chosen by the attacker. Intercepting an NTLM hash from a domain administrator, the attacker can craft their own request for the domain controller pretending to be that administrator and perform some administrative action such as adding themselves to the Domain Administrators group.
To exploit this issue, some higher-privileged user must be logged in to the same Windows computer as the attacker at the same time. This is a relatively exotic situation on Windows workstations, although possible with the "Switch user" feature that keeps one interactive user logged in while another user logs in interactively to the same computer. One could imagine a malicious user asking the administrator to help them resolve some issue by logging in to their workstation via "Switch user", where a script running in attacker's session would autonomously perform the attack.
A much more interesting target are Windows servers, especially terminal servers where multiple users, both unprivileged and administrators, have simultaneous user sessions. There, any remotely logged-in user could attack any other user that is currently also logged in, and do so without social engineering or any assistance by the victim.
Microsoft decided not to fix this issue as their position is that NTLM relaying should be prevented through NTLM configuration or by not using NTLM anymore. Such changes have potential to break something, so companies are understandably a bit reluctant to implement them in their production environments.
Patching This Issue
To fix a vulnerability, one must first understand it, and the functionality within which it resides. This immediately brings us to the question: Why does Windows allow a low-privileged user to cause anything to get
launched at all in a session other than their own? Unfortunately, we failed to find
the answer or even come up with some hypothetical reason. A feature like this would immediately look suspect to any security researcher, and
it's not a surprise that someone had looked at it and found it to be
It would be easy for us to completely disable this strange functionality but just in case it's being used for some reason, we decided to only block it in case a non-privileged user is trying to launch a process in another session. We wanted to allow privileged users such as administrators or Local System to use this mysterious feature if they wanted, but prevent normal users from doing so.
Our patch was therefore placed in the execution flow of rpcss.dll where requestor's token, requestor's session ID and target session ID are known, and does the following:
- If requestor's session ID is the same as target session ID, we do not interfere. (If the user wants to launch processes in their own session, let them do it.)
- Else, if requestor's token allows for some privileged operation, we do not interfere. (Specifically, if requestor's token has a non-zero TokenIsElevated value, we consider the requestor as privileged, and do not interfere.)
- Else, we block the operation.
Source code of our micropatch:
Here is a video showing how the micropatch blocks exploitation of this vulnerability:
This micropatch was written for:
- Windows 10 v21H1 32&64 bit updated with December 2021 or January 2022 Updates
- Windows 10 v20H2 32&64 bit updated with December 2021 or January 2022 Updates
- Windows 10 v2004 32&64 bit updated with December 2021 or January 2022 Updates
- Windows 10 v1909 32&64 bit updated with December 2021 or January 2022 Updates
- Windows 10 v1903 32&64 bit updated with December 2021 or January 2022 Updates
- Windows 10 v1809 32&64 bit updated with May 2021 Updates
- Windows 10 v1803 32&64 bit updated with May 2021 Updates
- Windows 7 32&64 bit updated with January 2020 Updates (no ESU)
- Windows 7 32&64 bit updated with January 2021 Updates (year 1 of ESU)
- Windows 7 32&64 bit updated with December 2021 or January 2022 Updates (year 2 of ESU)
- Windows Server 2019 64 bit updated with December 2021 or January 2022 Updates
- Windows Server 2016 64 bit updated with December 2021 or January 2022 Updates
- Windows Server 2012 R2 64 bit updated with December 2021 or January 2022 Updates
- Windows Server 2012 64 bit updated with December 2021 or January 2022 Updates
- Windows Server 2008 R2 64 bit updated with January 2020 Updates (no ESU)
- Windows Server 2008 R2 64 bit updated with January 2021 Updates (year 1 of ESU)
- Windows Server 2008 R2 64 bit updated with January 2022 Updates (year 2 of ESU)
- Windows Server 2008 64 bit updated with January 2020 Updates
0patch and Microsoft Extended Security Updates