Credit: Dreamstime
Among the over 100 vulnerabilities fixed by Microsoft during the past week in its monthly patch cycle is one that has the security community very worried. It's a critical remote code execution (RCE) vulnerability located in the Windows Remote Procedure Call (RPC) runtime.
The flaw, tracked as CVE-2022-26809, can be exploited over the network with no user interaction, possibly using multiple protocols as a trigger. It's the kind of vulnerability that gave life to major botnets in the past as some Windows processes use RPC to communicate with each other over networks.
"Patching is your only real fix for this vulnerability," Johannes Ullrich, founder of the SANS Internet Storm Center, said in an advisory.
"Don't delay it. Patch now and apply the entire April update. It fixes several other critical flaws that may have a similar impact inside your network (e.g., the NFS [Network File System] flaw). You can't 'turn off' RPC on Windows if you are wondering. It will break stuff. RPC does more than SMB [Server Message Block]."
Why is dealing with CVE-2022-26809 tricky?
The CVE-2022-26809 flaw is one of three RPC remote code execution flaws Microsoft patched this month. The other two are tracked as CVE-2022-24492 and CVE-2022-24528. However, the attack vector for the latter two flaws is client-side, with an attacker needing to trick users into executing a specially crafted script that would then make a call to a RPC host and execute code with the same permissions as the RPC service.
By comparison, exploiting CVE-2022-26809 is completely server-side and requires no user interaction. An attacker only needs to identify a system that has an RPC service listening for connections and then send the exploit.
There has been a debate in the security community since the flaw was announced regarding which protocols can be used to reach the vulnerability. To understand why that is, it's important to understand how RPC works.
How RPC works
RPC is a standardised method for creating client-server applications where a client application can call a procedure exposed by a server application without caring about the underlying network. The two applications can even be on the same machine and many Windows services and features rely on RPC locally. Microsoft even has a support article that warns against disabling RPC.
The standard communications port used by MSRPC is TCP 135. However, RPC traffic can be tunnelled over other protocols such as SMB/CIFS, HTTP or TCP on different ports.
That's why in its advisory Microsoft notes that TCP port 445, which is normally used by the SMB protocol, can be used to initiate a connection with the affected component and recommends that organisations block port 445 at their network perimeters.
Meanwhile other organisations, such as Trend Micro's Zero Day Initiative (ZDI), mention TCP port 135 in its advisory, causing some confusion.
Others wondered if TCP port 139, also associated with SMB and NetBIOS, might also be an avenue of attack, as well as other technologies such as SMB over QUIC, which tunnels SMB traffic over TLS-encrypted UDP port 443. Blocking that port at the network perimeter wouldn't be feasible since it would essentially block all HTTPS traffic.
There is currently no publicly available proof-of-concept exploit, but it's likely only a matter of time until someone develops one. Researchers are already reverse-engineering the patch to understand the vulnerability better and identify all the attack paths that could be used to reach the vulnerable code.
Even if only ports 135 and 445 can be used for such an exploit, the exposure would still be large. According to an analysis of the vulnerability by researchers from Akamai, almost 800,000 systems currently accept connections over port 445 from the internet.
This is based on data from the Shodan search engine, which has limited visibility, so the real number is actually larger. Adding all systems that advertise a "Microsoft RPC Endpoint Mapper" service publicly, the number jumps to over 2.1 million.
That's only systems that are reachable directly from the internet, but this exploit poses a major risk to local networks, too, because it can be used for lateral movement.
Gaining a foothold inside local networks is not hard for attackers and can be achieved in a variety of ways, from compromised credentials to employees clicking on malicious attachment or unpatched flaws in publicly exposed services or devices. We're in an age when security policies shouldn't be built on the premise that attackers can't get access to a local network as this is a common occurrence.
Why blocking ports might not work
Even Microsoft warns in its advisory for this vulnerability that "systems could still be vulnerable to attacks from within their enterprise perimeter" even if traffic over port 445 is blocked at the network perimeter.
The problem is that filtering such traffic inside local networks is much more complex because SMB is widely used across enterprise environments. The Akamai researchers recommend "limiting lateral movement by allowing incoming TCP port 445 only on machines where it is needed -- domain controllers, print servers, file servers, etc." Microsoft has a guide for securing SMB traffic on Windows servers.
However, it's worth keeping in mind that SMB is only one of the known attack vectors for this vulnerability and that additional ones might also be found as researchers keep digging into the flaw.
Because of this, the best course of action is to deploy Microsoft's April patches as soon as possible, especially since they also fix many other serious vulnerabilities, including a privilege escalation one that's already actively exploited in the wild.
