MS-DEFCON 3: Blocking a potential wormable event

By Susan Bradley

It’s been a long time since we’ve had a Microsoft worm event.

Last week’s patches contained a fix for the Windows TCP/IP Remote Code Execution Vulnerability identified as CVE-2024-38063. This one affects all supported Windows versions and extends back to Windows 7 and Windows 8, including older servers.

This CVE has a very high danger rating. Because of that, I am lowering the MS-DEFCON level earlier than I normally would, setting it to 3. That sounds backward, but this advisory is conditional, based upon the type of user you are and how you decide to deal with the update.

Although the danger is real, I believe the risk is somewhat less. In this alert, I’ll explain why.

Over the years, we’ve changed our systems and networks so that they are not as exposed to Web-based exploits as they were in the past. That’s the main reason I think this risk is manageable. Still, there are ways that attackers can get inside our networks, particularly by phishing. In this case, specially crafted packets must be created that can pass undetected through our edge defenses. (The nature of those packets has been withheld by the researcher because of the danger of the vulnerability.) The purpose of the patch is to add a final layer of detection so that if the dangerous packets get past the edge, they’ll still be picked up.

This vulnerability is directly connected to IPv6. Disable that, and you are protected, even without the patch. But disabling IPv6 does not apply to every situation and in some cases may not be advisable — or even possible.

Therefore, my basic recommendations are threefold: patch immediately, disable IPv6 on all PCs on your network, or configure your edge devices to block IPv6. Now for the details.

There are two options.

Install updates: I have tested updates on my home test-bed computers. No issues were found in that peer-to-peer network. Microsoft has fixed the side effect from last month’s patch installs that would trigger the BitLocker recovery key in instances where drive encryption is enabled on a Windows 10 or 11 Home SKU, or if BitLocker is enabled in Windows 10 or 11 Professional. Thus updating now should be safe.

Disable IPv6 for your network connections: You must do this for each network adapter in your system. For example, if you switch between wireless and wired, each connection must be addressed. Press the Windows key and type view network connections. The Network Connections control panel will appear. Right-click each connection and click Properties. Scroll down the list to find the entry  Internet Protocol Version 6 (TCP/IPv6) and uncheck the box (see Figure 1). You can leave this unchecked after the update is installed.

Figure 1. Disable IPv6 for wired or wireless network connections.

If you want to see whether your computer is using the IPv6 setting, go to this IPv6 site.

I do not recommend disabling IPv6 in your network connections without thorough testing, followed by examination of the consequences. For example, Microsoft Exchange doesn’t like IPv6 disabled. Direct access, in particular, requires IPv6. Servers typically want it enabled. This is more of a risk inside the network rather than outside, because your firewall and endpoint protection should assist you in protection. But it may be used with phishing lures to get inside.

You might consider disabling IPv6 using the PowerShell script CVE-2024-38063.ps1, found on GitHub. However, check and test carefully.

I’ve already seen conflicting information from Microsoft. Its official documentation indicates that the specially crafted packets could lead to remote code execution. A security-threat document available to E5 subscribers indicates that an unauthenticated threat actor could enable remote code execution (RCE) on a Windows device by repeatedly sending IPv6 messages that include specially crafted packets. This could result in a denial of service (DoS) condition. That’s a huge difference in risk, so I’ll be looking for more information to ensure we all know the true risk from this vulnerability.

The most important fact that emerges from current research is that the bug is triggered before the Windows firewall! That means Windows won’t protect you from this bug unless the August updates are applied.

Businesses have other options, such as reviewing network firewall rules, utilizing PVLANs (for DMZ/PAZ Windows IPv6 hosts), and employing existing edge devices to filter packets before they get inside your firm.

Despite my warnings above regarding the potential severity of this bug, as I write this there is no working proof of concept nor a working exploit. Please use my recommendations above as you see fit and as they best apply to your situation.

With respect to patching earlier than I would usually suggest, August updates are generally benign. That means I consider it safe to patch now. Ordinarily, I would have lowered the MS-DEFCON level to 4 by the end of the month, but setting it to 3 is my way of telling you to check carefully now — and, by all means, don’t ignore the bug.

Resources

Source