April 2022 Windows Updates included a fix for a critical remotely exploitable vulnerability in Windows Remote Procedure Call Runtime (CVE-2022-26809). The vulnerability was found and reported by company Cyber-Kunlun founded by security researcher mj0011, but no proof-of-concept was published at the time.
As is often the case, the research community "diffed" Microsoft's patch (see Ben Barnea and Ophir Harpaz of Akamai and MalwareTech) and quickly found that the vulnerability must have been an integer overflow: if a special kind of RPC packets were sent to the RPC server, and very many of them, a buffer size on the server side would grow and grow until it would have to exceed 4 GB (the highest number one can represent with 32 bits), at which point said buffer size would "overflow" and become very small again. Should the buffer then get allocated, it would be too small, incoming packets overwriting data and possibly code beyond it. By carefully selecting the size and content of packets, at least in theory, a remote attacker could cause arbitrary code to get executed in the process of the targeted RPC serve.
In practice, it would not be that easy. First of all, packets have a maximum size of about 5,000 bytes and sending enough of them over the network to cause the overflow takes hours. Moreover, several researchers have mentioned - and we can confirm - that attempting to send so much data to an RPC server often results in a timeout in communication, which means going back to square one. In addition, it became apparent that not all RPC servers would be vulnerable, as the affected code was only reachable on certain types of servers (see here). Finally, what exactly would be overwritten by malicious data, and how/if that could lead to execution of attacker's code, remains unexplored. Nevertheless, the history teaches us to assume that possible.
For a few weeks attackers and defenders alike were looking for more data and either searching for, or trying to create a POC. On May 1st, a GitHub repository from user yuanLink appeared with what looked like a POC for this issue, along with a detailed analysis of the vulnerability seemingly from the same user. We took the POC and after some modifications we were able to reach the vulnerable code and see the buffer size growing with each received packet.
While analyzing the vulnerability and comparing fixed and vulnerable code, our team noticed another integer overflow issue nearby that wasn't addressed by the April Windows Updates. Before we could report it to Microsoft it turned out Akamai researchers had already done that, and May updates brought a fix for this additional vulnerability, assigned CVE-2022-22019.
This allowed us to fix two birds with one stone, so to speak, and we created a single micropatch to address both CVE-2022-26809 and CVE-2022-22019.
mov r13d, [rsi+24Ch] cmp r13d, edi ; check if r13 > 0 jz PIT_0xb4661 ; jmp to exit block
cmp ebx, edi ; is flag RPC_BUFFER_EXTRA set? jz PIT_0xb4647 ; jmp to TransGetBuffer block
; overflow check mov edx, [rbp+18h] ; acc buffer length lea eax, [r13d+edx] ; sum of len(new_data) + len(acc_buffer) cmp eax, r13d ; check for overflow (if the result is smaller ; than r13) jb SET_ERROR ; if so, jump to error
mov edx, eax ; take the above sum add edx, 18h ; because of instruction: lea r8, [r13+18h] cmp edx, 18h ; check for overflow (if the result is smaller ; than 18h) jb SET_ERROR ; if so, jump to error
mov r13d, eax ; save len(new_data) + len(acc_buffer) to r13 jmp PIT_0xb4647 ; jmp to TransGetBuffer block, continuing original code
SET_ERROR: mov edi, 6C6h ; error code jmp PIT_0xb4661 ; jmp to exit block
code_end
patchlet_end
Our micropatch was written for the following Windows versions that don't receive official patches from Microsoft:
Windows 10 v1803 updated to May 2021
Windows 10 v1809 updated to May 2021
Windows 10 v1903 updated to December 2020
Windows 10 v2004 updated to December 2021
Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020
This
micropatch has already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center.
We'd like to thank yuanLink for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch, and Antonio Cocomazzi for providing valuable assistance in reproducing the issue. We also
encourage security researchers to privately share their analyses with us
for micropatching.
March 2022 Windows Updates brought a fix for a logical vulnerability in Remote Desktop Client for Windows that was found and reported by Abdelhamid Naceri. The vulnerability allowed a malicious RDP server to gain write access to any local drive on the computer running the connected RDP client, as long as at least one local drive was shared through the RDP session.
The trick Abdelhamid used in their POC was, as it so often happens, a symbolic link: Suppose you connected to a malicious RDP server and shared a locally plugged-in USB drive E:, the server could create a symbolic link from E:\temp to C:\ (which would mean your local C: drive, not server's) whereby the entire content of drive C:\ would become accessible to the server under E:\temp with permissions of the connecting user.
Microsoft assigned this issue CVE-2022-21990 and fixed it by preventing the server from creating symbolic links on drives that were shared with the server pointing to drives that were not shared with the server. This fix, however, was not delivered to Windows systems that no longer receive Windows Updates; such systems can now use our micropatches instead.
We decided to make our micropatches simpler than Microsoft's fix to avoid changing lots of code: our approach was to simply prevent creating symbolic links on drives that were shared with the server (regardless where these links would point to). We think it is very unlikely that our approach would break any reasonable use case - but just in case it does, the user can always temporarily disable our patch and then re-enable it - of course without restarting the computer, or even re-establishing the RDP connection.
Our micropatch was written for the following Windows versions that don't receive official patches from Microsoft:
Windows 10 v1803 updated to May 2021
Windows 10 v1809 updated to May 2021
Windows 10 v2004 updated to December 2021
Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020
This
micropatch has already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center.
We'd like to thank Abdelhamid Naceri for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
Twice Bypassed and Twice Micropatched, Will Third Time be a Charm?
by Mitja Kolsek, the 0patch Team
In November we issued a micropatch for a local privilege escalation in User Profile Service .This vulnerability was found and reported to Microsoft by security researcher Abdelhamid Naceri and assigned CVE-2021-34484 when initially fixed. Abdelhamid subsequently noticed that Microsoft's patch was incomplete and wrote a POC to bypass it. Based on that information, we were able to create a micropatch for what was then considered a 0day (a known vulnerability without an official vendor fix).
Microsoft then provided a fix for Abdelhamid's bypass with January 2022 Windows Updates (assigning the "new" vulnerability CVE-2022-21919), but Abdelhamid took a closer look and found another way around it (the linked article is not available at the time of this writing).
We could easily reproduce this second bypass on fully updated Windows computers, except on Windows Server 2016. While our own micropatch was not bypassable using Abdelhamid's new trick, Microsoft modified the DLL we wrote the micropatch for (profext.dll), which meant we had to port our patch to the new version of this DLL to protect users who diligently apply Windows updates.
In short, CVE-2021-34484 is again a 0day on supported Windows versions. Somewhat ironically, affected Windows computers whose official support had already ended (Windows 10 v1803, v1809, and v2004) and have 0patch, did not have this vulnerability reopened.
We ported our micropatch to the latest profext.dll on the following Windows versions:
Windows 10 v21H2 (32 & 64 bit) updated with March 2022 Updates
Windows 10 v21H1 (32 & 64 bit) updated with March 2022 Updates
Windows 10 v20H2 (32 & 64 bit)updated with March 2022 Updates
Windows 10 v1909 (32 & 64 bit)updated with March 2022 Updates
Windows Server 2019 64 bitupdated with March 2022 Updates
Since this vulnerability is again a 0day, our micropatches for it became free again and will remain free until Microsoft has
issued a correct official fix. To use these micropatches, create a free account
in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.
Users who already have 0patch installed do not have to do anything: new micropatches will get applied automatically.
We'd like to thank Abdelhamid Nacerifor finding this issue and sharing details, which allowed us to create a micropatch and protect our users.
To learn more about 0patch, please visit our Help Center.
As time goes on, additional Windows 10 versions go out of official support - we have previously security-adoptedWindows 10 v1803 and v1809, and now we're happy to report that we're adding two versions to the list:
Windows 10 v2004: This version stopped receiving security updates from Microsoft in December 2021, but we've since been delivering critical security micropatches for it to keep it running securely. If you're running Windows 10 v2004 in your organization, all you need to do is install 0patch Agent on these computers and register it to an account with PRO or Enterprise subscription.
Windows 10 v1909: Enterprise, Education and IoT Enterprise releases of this Windows 10 version will receive its last security update from Microsoft in May this year (two months from now). At that time we will security-adopt it and start providing critical security micropatches to keep it running securely.
These micropatches will be included in 0patch PRO and Enterprise
licenses along with all other micropatches we're issuing - which means
that users protecting their Windows 10 v1909/v2004 with 0patch will also
receive our occasional micropatches for "0day" vulnerabilities in
various products.
In order to have our micropatches applied, users will have to have their computers fully
updated with the latest official Windows Updates provided by
Microsoft: December 2021 updates for v2004, and May 2022 updates for v1909.
We welcome all interested organizations to contact sales@0patch.com
for information about pricing, deployment, or setting up a trial.
To learn more about 0patch, please visit our Help Center.
Twelve days ago, security researcher Axel Souchet published detailed analyses with associated proofs-of-concept for two remotely exploitable vulnerabilities in Windows that were fixed by Microsoft with February Windows Updates. Both vulnerabilities are similar and are caused by an uninitialized pointer that a malicious RTF file can get freed while having an illegal value.
Exploitability of such issues depends on whether the attacker can get the uninitialized value to point to a chosen address and thus control the resulting memory corruption. We don't know if this is possible but following the worst-case assumption principle (and historical track record showing that to be generally possible with sufficient motivation), unexplored memory corruption issues are assumed to allow for a remote code execution.
While Axel found these vulnerabilities, he was not the only one; both issues were reported to Microsoft by Zesen Ye and Zhiniang Peng with Sangfor, and CVE-2022-21971 also by Jinquan with DBAPPSecurity Lieying Lab. There was some initial uncertainty on whether these CVE IDs really matched Axel's findings, but Zhiniang has confirmed the match.
It was trivial to reproduce both issues by simply enabling Page Heap for WordPad.exe and opening Axel's RTF documents with WordPad. While WordPad requires the user to unblock content in a security warning, opening the same document in Microsoft Word produces no warnings. We preferred using WordPad for our analysis, however, as it is present on Windows by default.
Our analysis of Microsoft's fixes for these issues revealed that, unsurprisingly, they just added pointer initialization to constructor code. The image below shows a diff between vulnerable (left) and fixed constructor (right) in RMSRoamingSecurity.dll., and something similar was done in prauthproviders.dll as well.
Our micropatches are logically equivalent to Microsoft's. They were written for the following Windows versions that don't receive official patches from Microsoft:
Windows 10 v1803 updated to May 2021
Windows 10 v1809 updated to May 2021
Windows 10 v2004 updated to December 2021
Note that Windows 7 and Server 2008 R2 are not affected as the vulnerable functionalities do not exist there.
Here is a video showing how 0patch blocks exploitation of these vulnerabilities:
These
micropatches have already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain them and have them applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center.
We'd like to thank Axel Souchet for publishing their analyses and providing proofs-of-concept that allowed us to reproduce these vulnerabilities and
create micropatches for them. We also
encourage security researchers to privately share their analyses with us
for micropatching.
Vulnerability CVE-2022-21999, nicknamed "SpoolFool", complements numerous previously found issues in Windows Print Spooler, and like many of those, uses symbolic links to trick the Print Spooler service running with System privileges into doing something with file system that benefits the local attacker.
In this case (see proof-of-concept), the attacker makes the Print Spooler service change permissions of an attacker-chosen folder on the computer such that everyone can create files in it. It does so by creating a printer (any user can do that by default on a Windows workstation) with its own dedicated spooler folder. When Print Spooler service is restarted, it checks every printer's spooler folder to make sure it's there and properly set up - if the folder doesn't exist, the service creates it, and if the folder doesn't allow all users to write to it, it sets everyone-write permissions on it.
Oliver noticed that creating a symbolic link from a printer's spooler folder to some system folder results in Print Spooler service setting such permissions to said system folder, thus allowing the attacker to create arbitrary files there. Having this capability, the attacker can get their own executable launched by some system process.
Microsoft's patch changed the behavior of Print Spooler service such that upon restart, it no longer creates a spooler folder or change its permissions, thus redirecting printers with misconfigured spooler folders to the default spooler folder. Our micropatch does effectively the same.
The micropatch was written for the following Windows versions that don't receive official patches from Microsoft:
Windows 10 v1803 updated to May 2021
Windows 10 v1809 updated to May 2021
Windows 10 v2004 updated to December 2021
Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020
This
micropatch has already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center.
We'd like to thank Oliver Lyak for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
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.
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
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.
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
exploitable.
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.)
push r12 ; store registry values push r13 push r9 sub rsp, 8 ; align stack
mov r13, [rbp-68h] ; this - contains current session token mov rcx, [r13+48h] ; get current session token sub rsp, 20h ; home space call PIT_0xec38 ; call GetSessionId2, returns session id add rsp, 20h ; restore stack pointer mov r12, rax ; store session id
mov rcx, [rbp-58h] ; target session token sub rsp, 20h ; home space call PIT_0xec38 ; call GetSessionId2, returns session id add rsp, 20h ; restore stack pointer cmp rax, r12 ; compare both session ids ; equal -> continue normal code flow ; not equal -> check if current session has elevated privileges je CONTINUE
mov rcx, [r13+48h] ; current session token sub rsp, 20h ; home space call PIT_ImpersonateLoggedOnUser ; the user is represented by token handle ; If the function succeeds, the return value is nonzero add rsp, 20h ; restore stack pointer cmp eax, 0 ; check return value je CONTINUE
mov r12, 0 ; r12 stores a value that decides if requestor has ; elevated privileges ; 0 - not elevated ; 1 - elevated mov rcx, 0FFFFFFFF80000002h ; handle to HKLM registry, hKey call VAR dw __utf16__('SOFTWARE'), 0 VAR: pop rdx ; rdx points to string "SOFTWARE", lpSubKey mov r8, 0 ; ulOptions - must be 0 mov r9, 4 ; samDesired - write access desired sub rsp, 30h ; home space + 10h to store vars on stack mov qword[rsp+28h], 0 ; resulting handle is at rsp+28h lea rax, [rsp+28h] ; get address of handle mov [rsp+20h], rax ; phkResult call PIT_RegOpenKeyExW ; Opens the specified registry key mov r13, [rsp+28h] ; store return value add rsp, 30h ; restore stack pointer cmp eax, 0 ; If the call succeeded, return value is ERROR_SUCCESS(0). jne REVERT ; jmp if function fails
mov rcx, r13 ; hKey sub rsp, 20h ; home space call PIT_RegCloseKey ; Close the handle of registry key add rsp, 20h ; restore stack pointer mov r12, 1 ; elevated privileges
REVERT: sub rsp, 20h ; home space call PIT_RevertToSelf ; RevertToSelf terminates previous impersonation add rsp, 20h ; restore stack pointer cmp r12, 1 ; check if current user has elevated privileges je CONTINUE ; jmp if yes
add rsp, 8 ; restore stack to original state before patch pop r9 pop r13 pop r12 jmp PIT_0x11560 ; skip to end of the function, blocking the attack
CONTINUE: add rsp, 8 ; restore stack to original state before patch pop r9 pop r13 pop r12
code_end
patchlet_end
Here is a video showing how the micropatch blocks exploitation of this vulnerability:
Micropatch Availability
This micropatch was written for:
Windows 10 v21H1 32&64 bit updated with December 2021 or January 2022 Updates
Windows 10 v20H2 32&64 bitupdated with December 2021 or January 2022 Updates
Windows 10 v2004 32&64 bitupdated with December 2021 or January 2022 Updates
Windows 10 v1909 32&64 bitupdated with December 2021 or January 2022 Updates
Windows 10 v1903 32&64 bitupdated with December 2021 or January 2022 Updates
Windows 10 v1809 32&64 bitupdated with May 2021 Updates
Windows 10 v1803 32&64 bitupdated with May 2021 Updates
Windows 7 32&64 bitupdated with January 2020 Updates (no ESU)
Windows 7 32&64 bitupdated with January 2021 Updates (year 1 of ESU)
Windows 7 32&64 bitupdated with December 2021 or January 2022 Updates (year 2 of ESU)
Windows Server 2019 64 bitupdated with December 2021 or January 2022 Updates
Windows Server 2016 64 bitupdated with December 2021 or January 2022 Updates
Windows Server 2012 R2 64 bitupdated with December 2021 or January 2022 Updates
Windows Server 2012 64 bitupdated with December 2021 or January 2022 Updates
Windows Server 2008 R2 64 bitupdated with January 2020 Updates (no ESU)
Windows Server 2008 R2 64 bitupdated with January 2021 Updates (year 1 of ESU)
Windows Server 2008 R2 64 bitupdated with January 2022 Updates (year 2 of ESU)
Windows Server 2008 64 bitupdated with January 2020 Updates
Micropatches for this vulnerability will be free until Microsoft has
issued an official fix. If you want to use them, create a free account
in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.
We'd like to thank Antonio Cocomazzi and Andrea Pierinifor finding this issue and sharing details, which allowed us to create a micropatch and protect our users.
0patch and Microsoft Extended Security Updates
If you're using Windows 7 or Windows Server 2008 R2 with Extended Security Updates (ESU), you have just received the last Windows Updates for the year and are facing paying twice as much as last year to continue receiving Microsoft's official security fixes.
0patch is a much less expensive and less intrusive alternative to ESU. We started by security-adopting Windows 7 and Server 2008 R2 in 2020 when official support for these platforms ended, and many users installed 0patch to keep their systems running securely. Almost all of them are still running today, and you can join them by using 0patch on top of ESU updates you've received up to this point.
