Just a month went by since our last blog post on a zero-day vulnerability (CVE-2024-43451), and once again a Microsoft Patch Tuesday brings to light new critical CVEs. This time dubbed LDAPNightmare (or LDAPBleed), the two vulnerabilities (CVE-2024-49112 & CVE-2024-49113) are categorized as remote code execution and denial of service and were found in the Lightweight Directory Access Protocol (LDAP).
As with CVE-2024-43451, these vulnerabilities are based on forcing a host to perform outbound communication towards the attacker’s machine. They can both be preemptively prevented by using Zero Networks’ network segmentation platform. Let’s dive into the details.
Technical Details
The attack flow can be summarized to the following steps:
- The attacker sends an RPC request to the victim’s machine.
- The RPC function causes the victim to perform a DNS query, which resolves to the attacker machine’s hostname.
- The victim broadcasts a NBNS request to find the attacker machine’s IP address.
- The victim sends a LDAP request to the attacker’s machine, and the attacker replies with a malicious LDAP reply that triggers the exploit.
For a more in depth explanation of how the attack works, see SafeBreach’s blog post on their PoC exploit code.
Using the LDAPNightmare PoC to exploit our lab DC
If we want to preemptively defend against such scenarios (without passively waiting for similar vulnerabilities to be discovered and patched), we need to look at the different components of the attack and identify which stages can be blocked in the first place. In the case of LDAPNightmare, the stages are:
- The RPC call cannot be blocked with a classic Firewall, as RPC services must be available for the domain to function correctly (especially on DCs). However, we can use the RPC Firewall to block specific RPC operations.
- DNS traffic cannot be easily blocked, as the attacker makes use of the network’s legitimate DNS infrastructure.
- NBNS would be challenging to block and could break things in the network.
- LDAP traffic should only be performed towards specific legitimate destinations (usually Domain Controllers). This means we can block this stage with microsegmentation.
Outbound Block to the Rescue
When looking at the last stage of the attack, we can see that for the exploit to function, the victim needs to send a LDAP request towards the attacker. We have 2 options for blocking this behavior:
- Using a Firewall to block inbound LDAP traffic on the malicious server. This is not ideal, as we can assume the attacker might disable such firewall rules, change the port used for the LDAP request, or use an unmanaged asset where we don’t have full control over the Firewall rules.
- Using a Firewall to block outbound LDAP traffic on the victim machine. This is a better approach, as it protects managed sensitive assets.
To set up such a rule, all we need to do is define an outbound block from our assets towards any destination over LDAP, excluding our legitimate LDAP servers (usually Domain Controllers).
LDAPNightmare PoC fails to run due to network segmentation
In the following image, we can see how the LDAP query from our victim (in this case, our Domain Controller) is blocked at the source, and not reaching the malicious server. No matter how the attacker sets his Firewall policy, the request will never reach his host, and the exploit would not trigger.
The LDAP operation fails due to the outbound block rule
Protection with the RPC Firewall
Another option we have is to block the initial RPC call and prevent the LDAP operation from ever occurring. We can use the RPC Firewall for this, by either using an allow list (only accepting RPC calls from approved sources and/or safe RPC operations), or by blocking specific RPC calls that are known to be malicious.
In the case of LDAPNightmare, we can block the specific operation used in the exploit scenario - DsrGetDcNameEx2 (part of the netlogon interface).
Setting an RPC Block rule to prevent the DsrGetDcNameEx2 operation
Using this RPC Firewall configuration, the LDAPNightmare PoC will now fail with an access denied error, preventing the exploit from ever triggering.
LDAPNightmare PoC fails with access denied
The blocked RPC operation in the Zero Networks portal
Get Proactive Defense with Zero Networks
The LDAPNightmare vulnerabilities (CVE-2024-49112 & CVE-2024-49113) represent a critical security threat to Windows servers, particularly those running Active Directory services. Zero Networks offers a proactive defense through network segmentation, implementing outbound LDAP traffic blocks and RPC operation controls that effectively disrupt the attack chain before exploitation can occur. By blocking specific RPC operations and controlling network traffic, organizations can prevent these sophisticated attacks from reaching their targets, demonstrating the power of a zero trust approach in modern cybersecurity strategies.