Hunting Pre-Auth RCEs in Windows Remote Access Service

TLDR: Windows Remote Access Service (RAS) is a goldmine for pre-authentication vulnerabilities due to its complex mix of kernel-mode drivers and user-mode services. By targeting protocols like PPTP, SSTP, and L2TP, researchers can trigger race conditions and memory corruption bugs without any user interaction. This post breaks down the attack surface and provides a methodology for auditing these services to find high-impact bugs.

Windows Remote Access Service (RAS) is one of those legacy components that every enterprise relies on, yet few security teams actually audit. It sits at the edge of the network, handling incoming VPN connections, and it is riddled with complex, multi-threaded code that is perfect for finding pre-authentication remote code execution (RCE) bugs. If you are a bug bounty hunter or a pentester, you should be looking here. The attack surface is massive, the code quality is often questionable, and the payout for a successful exploit is significant.

The Anatomy of the Attack Surface

The core issue with Windows RAS is its architecture. It relies on a combination of kernel-mode drivers like raspptp.sys and rasl2tp.sys, and user-mode services like raspp.dll. These components communicate via IOCTLs and shared memory structures. When you have multiple threads accessing the same data structures without proper locking, you get race conditions. When you have complex packet parsing logic without strict bounds checking, you get memory corruption.

The research presented at Black Hat 2023 by Yuki Chen highlights exactly how to exploit this. The focus is on pre-authentication bugs, meaning you do not need valid credentials to trigger them. You just need to send a malformed packet to the VPN service.

Exploiting Race Conditions and Memory Corruption

The most effective way to find these bugs is through a combination of mutation-based fuzzing and manual auditing. You do not need a sophisticated fuzzer to start. A simple fuzzer that sends random, mutated packets to the VPN service can trigger crashes in minutes.

For example, consider the LcpMakeConfigResult function in the LCP protocol. It parses incoming configuration requests. If the length field in the packet is smaller than the minimum size of an LCP option, the code will still attempt to copy the data. This leads to an out-of-bounds read or write, depending on how the memory is laid out.

// Vulnerable code pattern in LCP parsing
if (psrcOption->length < 2) {
    // If length is too small, the copy will be uninitialized or out-of-bounds
    memcpy(pDstOption, psrcOption, psrcOption->length);
    pDstOption += psrcOption->length;
    psrcOption += psrcOption->length;
}

This is a classic bug. The developer assumes the input is well-formed, but it never is when you are fuzzing. Once you have a crash, you need to use a debugger like WinDbg to analyze the memory state and determine if it is exploitable.

The Power of Manual Auditing

While fuzzing is great for finding low-hanging fruit, manual auditing is where you find the really interesting bugs. You need to look for patterns where a resource is accessed in one thread and freed in another without proper synchronization.

The NdisVcHandle in the L2TP driver is a perfect example. It is used to track the state of a VPN connection. If a client sends a disconnect request, the service will free the NdisVcHandle. However, if another thread is still processing a packet that references that same handle, you get a use-after-free (UAF).

// UAF pattern in NdisVcHandle usage
// Thread 1: Processes incoming packet
NdisCmDispatchIncomingCall(..., pCall->NdisVcHandle);

// Thread 2: Closes connection
NdisCmDeleteVc(pCall->NdisVcHandle);

This is a race condition. If Thread 2 executes between the time Thread 1 retrieves the handle and the time it uses it, the system will crash or, if you are lucky, execute arbitrary code.

Real-World Applicability for Pentesters

If you are on a red team engagement, you will encounter these services constantly. Every Windows Server with the Remote Access role enabled is a potential target. The impact of a successful exploit is total system compromise. You are running code in the context of the kernel or a high-privilege service, which is exactly what you want.

When testing, focus on the pre-authentication phase. Send packets that violate the protocol specifications. Try to trigger state machine transitions that shouldn't happen. Use the NVD database to look for past vulnerabilities in these components to understand the types of bugs that have been found before.

Defensive Measures

Defending against these types of bugs is difficult because they are often deep in the kernel. The best defense is to minimize the attack surface. If you do not need a specific VPN protocol, disable it. If you must use a VPN, ensure that the server is patched and that you are using the most secure protocol available. For example, IKEv2 is generally more secure than PPTP or L2TP.

Also, consider using Network Policy Server (NPS) to restrict access to the VPN service. By implementing strict authentication policies, you can reduce the risk of an attacker reaching the vulnerable code paths.

The key takeaway here is that legacy network services are not as secure as they might seem. They are complex, they are rarely updated, and they are perfect targets for anyone willing to put in the time to audit them. Keep looking for those race conditions and memory corruption bugs, because they are definitely still there.