How to patch the Bad Neighbor CVE-2020-16898 Exploit

So another Patch Tuesday has come and gone, and another vulnerability that will doom your system is here! It is named Bad Neighbor aka Ping of Death Redux (CVE-2020-16898). I briefly touched on this with this month's Patch Tuesday Post, and while I pointed out it was the highest risk, I also apparently misjudged just how serious it was. Anytime it is good enough to get a name, you know you should be mitigating it ASAP. Perhaps doubly so if it's been named twice.

What is it?

Bad Neighbor attacks the way Windows handles IPv6 advertisement packets, a hacker that exploits it can use this vulnerability to execute code on the target server or client. This sounds bad as it is, but how about some real-world examples to hammer it home.

There are already several proof of concept videos showcasing its ability to cause the dreaded Blue Screen of Death on a remote machine. Here is Sophos highlighting how easy this is. This could also theoretically be used to take over a remote machine entirely, but that will take a lot more work, and you should be able to patch faster than they can create that.

Ways to Resolve

Luckily, there's already a patch for this vulnerability, so do that as soon as possible if you have not yet. If, however, your update schedule is locked in enough red tape that common sense can't beat out the process, there is a workaround.

You will need to disable the recursive DNS server option on all systems running Windows 1709 or later. You can do this with a single line command below.

netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable

That should keep you safe until you can get your systems updated. If you do ultimately end up doing this, make sure you re-enable this feature after you can patch. Same line, just set to enable instead of disable.

netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=enable

Neither of these commands will require a reboot. I can not stress enough that this is a temporary solution, and you really need to be patching as soon as you are able.

Disable for each IPv6 Interface

You may have noticed that the script line is incomplete, asking for *interfacenumber*, which I will assume you don’t have the IDX of each IPv6 of each machine. Let's take a look at how we can get them all with PowerShell and how we can run that against every machine using PDQ Deploy.

First, we are going to need each index; in Powershell, we can get that with:

Get-NetIPInterface -AddressFamily ipv6

Once we have those, we are going to need to look for RFC 6106. Unfortunately, I am unable to find this with the PowerShell built-in commands. Still, we can find them without issue using netsh; we need to filter out the information with the -match parameter.

(& netsh int ipv6 show int $_.ifIndex) -match '(RFC 6106)'

Finally, if the line returns and is listed as enabled, we would want to run the command up top to disable it. So all put together, it will look like this:

Get-NetIPInterface -AddressFamily ipv6 | foreach{
   $rfc = (& netsh int ipv6 show int $_.ifIndex) -match '(RFC 6106)'
   if($rfc -like "*enabled"){
        netsh int ipv6 set int $_.ifIndex rabaseddnsconfig=disable
   }
}

This will grab every IPv6 interface, and if the setting we need is enabled, disable it for us. Now that we have the code, we can add it as a PowerShell step in Deploy and run against all Win10 1709 and above.

You can easily send this out to your entire environment and have this workaround in place in no time at all.

There is a time and place for a more targeted deployment, but it might be best to send this everywhere, as it impacts both workstations and servers. Knowing which Indexes are enabled is valuable information to look up, however.

If you create a new PowerShell scanner in PDQ Inventory, you can gather this information with six lines. (See Out-String)

Get-NetIPInterface -AddressFamily ipv6 | foreach{
   [PSCustomObject]@{
        "IfIndex"   = (& netsh int ipv6 show int $_.ifIndex) -match 'IfIndex' -replace "ifindex\s*:","" | Out-String
        "RFC"   = (& netsh int ipv6 show int $_.ifIndex) -match '(RFC 6106)' -replace "RA Based DNS Config \(RFC 6106\)\s*:","" | Out-String
    }
}

This will scan each computer, grab every IPv6 index, and let you know if it is vulnerable(enabled) or secure(disabled).

After scanning, click on New Dynamic Collection to build a collection of machines that you know are not secure.

Alright! Patching is finally complete, and it is time to undo the temporary fix we have in place for Bad Neighbor. We can help with that.

Deploying to the Right Machines

We want to be sure that we are deploying to the right machines. To be sure means we want to make sure that we are deploying to computers 1709 or later, and we want to make sure that they have had the latest patch installed.

Instead of building this from scratch, let’s use some of the work that has been done for us. Click on new dynamic collection in Inventory and add a filter checking that each version of the Windows 10 is up to date.

That is all we need from inventory. Let’s move on to Deploy so we can undo our update.

Deploying the Fix

The PowerShell to uninstall will be very similar to the disable script we wrote in the initial Bad Neighbor blog. The main changes are we are not testing if they are Enabled/Disabled. We are just enabling them since they are secure through the October Patch. It looks like this:

Get-NetIPInterface -AddressFamily ipv6 | foreach{
        netsh int ipv6 set int $_.ifIndex rabaseddnsconfig=enable
}

Pretty straight forward, right? Let’s get this added to a new package and set it to only run against our newly created collection.

This deployment will go very fast, and your IPv6 is restored.

Conclusion

It is never great to have a massive exploit, and even worse if you need to do a temporary workaround instead of the permanent patch. Hopefully, this shows it will be easy to return your environment to the best version after patching everything.