Critical Remote Code Execution Vulnerabilities in Windows RPC Runtime
Three critical vulnerabilities were found and patched in Windows Remote Procedure Call (RPC) runtime:
CVE-2022-24492 and CVE-2022-24528 (discovered by Yuki Chen with Cyber KunLun)
CVE-2022-26809 (discovered by BugHunter010 with Kunlun)
In this blog post, we will provide information about these three vulnerabilities, the implications of their exploitation, the scope of effect and how they can be mitigated.
We recently wrote a guide about RPC filters, a tool for limiting and blocking RPC traffic on and among Windows machines. Although we have not yet determined whether RPC filters are an applicable solution for the discussed vulnerabilities, we recommend reading the blog to better understand the mechanism.
The vulnerabilities and their implications
By exploiting these vulnerabilities, a remote unauthenticated attacker can execute code on the vulnerable machine with the privileges of the RPC service, which depends on the process hosting the RPC runtime. The vulnerability can be exploited both from outside the network in order to breach it, as well as among machines in the network to move laterally.
As shown in the table, CVE-2022-26809 is a zero-click bug which requires no interaction to be exploited. For this reason, it scored the highest on the Common Vulnerability Scoring System (CVSS) — 9.8 out of 10 — indicating the high severity of the vulnerability, as well as the likeliness of attackers rushing to exploit it.
Who is vulnerable?
Any Windows machine where port 445 is exposed and the RPC runtime library is not patched is vulnerable. According to Shodan, more than 700,000 Windows machines expose this port to the internet. According to Microsoft, servers that listen on this TCP port are potentially vulnerable.
Locating and understanding the vulnerabilities
The CVE stated that the vulnerabilities lie within the Windows RPC runtime, which is implemented in a library named rpcrt4.dll. This runtime library is loaded into both client and server processes utilizing the RPC protocol for communication.
We compared versions 10.0.22000.434 (unpatched, from March 2022) and 10.0.22000.613 (patched, from April 2022) and produced the following list of changes in various functions:
The functions OSF_CCALL::ProcessResponse and OSF_SCALL::ProcessReceivedPDU caught our eye. The two functions are similar in nature; both process RPC packets, but one runs on the client side and the other on the server side (CCALL and SCALL stand for client call and server call, respectively). We went on to diff OSF_SCALL::ProcessReceivedPDU, and noticed two code blocks that were added to the new version.
Looking at the fixed code, we saw that a new function was called after QUEUE::PutOnQueue. Zooming in on the new function and inspecting its code, we figured out it checks for integer overflows. Namely, the new function was added to verify that an integer variable remained within an expected value range.
Diving deeper into the vulnerable code in OSF_SCALL:GetCoalescedBuffer, we noticed that the integer overflow bug could lead to a heap buffer overflow, where data is copied onto a buffer that is too small to populate it. This, in turn, allows data to be written out of the buffer’s bounds, on the heap. When exploited properly, this primitive could lead to remote code execution.
A similar call to check for integer overflow was added in other functions as well:
The integer overflow vulnerability and the function that prevents it exist in both client-side and server-side execution flows.
Although RPC uses several security controls and mechanisms (security callbacks,
We recommend the following mitigations, based also on Microsoft’s official advisories:
Apply the latest security updates that mitigate these vulnerabilities
Although RPC is necessary for services used by the system, it is recommended to block traffic to TCP port 445 for devices outside of the enterprise perimeter
Limit lateral movement by allowing incoming TCP port 445 only on machines where it is needed (i.e., domain controllers, print servers, file servers, etc)
Akamai Guardicore segmentation rule
Akamai Guardicore segmentation is meant to protect you from exploitation of these vulnerabilities. As previously mentioned, CVE-2022-26809 was given such a high CVSS score because it is zero-click. This means it can go unnoticed by the user and, potentially, by the security team as well. By segmenting your network with explicit access controls, you will prevent the breach or lateral movement an attacker would leverage here.
In order to apply the second mitigation and block SMB traffic from outside the network, create the following segmentation rule:
Learn more: https://www.akamai.com/blog/security/critical-remote-code-execution-vulnerabilities-windows-rpc-runtime