Discover how dangerous a ‘Bad Neighbor’ can be - TCP/IP Vulnerability (CVE-2020-16898)
- Article tags
Patching is never easy, but doing it imperfectly can come back to bite you.
That’s why today we’re unpacking a vulnerability that can resurface when improperly mitigated.
Microsoft recently released a patch in October for the obnoxious CVE-2020-16898 within the IPv6 stack that is capable of triggering the BSOD (Blue Screen of Death). This vulnerability, dubbed Bad Neighbor, is a dedicated bug within the IPv6 Neighbor Discovery Protocol. The bug arises when it improperly handles ICMPv6 router advertisement packets.
This is a critical security flaw (8.8 severity score) as cybercriminals can use it to carry out other specific attacks such as remote code execution (RCE) that can lead to much worse outcomes than BSOD.
How CVE-2020-16898 exposes your system to remote exploitation
The most elegant yet threatening element of this bug is that the vulnerable system can be exploited remotely by an attacker residing in the same subnet. That’s why it’s extremely important to patch it up before things get out of hand. But before we dive deeper into the patching details, we must gain a strong understanding of CVE-2020-16898.
Know your Bad Neighbor – details and analysis
The vulnerability results in IPv6 stack-based buffer overflow from the improper handling of the ICMPv6 router advertisements with the RDNSS (recursive DNS server options) while the length field value is even. According to the RFC 8106, the length option for the RDNSS can be divided into eight octet units, and the minimum value should always be odd, with at least 3 units for a single IPv6 address.
With an increase in a single RDNSS address, the octet unit length increases by 2. A proper scale known as the “field” is used to determine the total number of IPv6 addresses. It has a bunch of values regarding IPv6, RDNSS, and the octet units aligned at the top of the scale.
This is what it looks like:
How attackers link vulnerable endpoints to make your network unusable
As I mentioned earlier, a malicious actor can remotely exploit the vulnerable system by using remote code execution to trigger a chain reaction, linking one vulnerable machine to another and providing the attacker with a network of compromised and unusable systems.
If the IPv6 router advertisement packet is maliciously crafted with an RDNSS option, then it can trigger a tcpip.sys file from the Windows operating system and lead to a DoS attack. The vulnerability occurs because of the tcpip.sys driver parses ICMPv6 messages incorrectly. Since the vulnerability appears within the router advertisement packet of the ICMPv6 neighbor discovery protocol, that’s why it got the Bad Neighbor name.
This vulnerability impacts the following operating systems:
Windows 10 Version 1709
Windows 10 Version 1803
Windows 10 Version 1809
Windows 10 Version 1903
Windows 10 Version 1909
Windows 10 Version 2004
Windows Server 2019 core installation
Exploiting CVE-2020-16898 / Bad Neighbor
To exploit CVE-2020-16898, the attacker must have the proper understanding and knowledge of what they’re doing.
The exploit itself materializes in the following steps:
the cybercriminal sends an RDNSS option at an even length
At the same time, they also send an IPv6 address value which is only 8 bytes or – in relative terms – 8 bytes shorter than the required 16 bytes, along with the RDNSS option streaming previously set at an even length
this causes the TCP/IP protocol to believe that it is, in fact, the start of a second option, leading to buffer overflow or a potential RCE (implementation of malware by exploiting an RCE vulnerability)
The Windows driver tcpip.sys will potentially fail to parse this type of request with an even option, thus resulting in a Denial of Service or a Blue Screen of Death. The risk is amplified because tcpip.sys is a Windows driver that communicates with various devices connected to the internet by setting the properties of TCP/IP protocol.
Attack surface – who Bad Neighbor hurts the most
The vulnerability largely impacts Windows 10 users, even if Microsoft has recently released an update that patches the vulnerability for Windows 10 users originating from different build versions.
Shodan.io, the acclaimed tool used to unveil the location of two computers connected within the same network, puts the number of Windows server machines with IPv6 addresses in the hundreds, if not in the thousands. The reason for this limited attack surface mapping is that firewalls secure many of the servers and others are operated and managed by cloud service providers, thus making them unreachable to Shodan.io scans.
How to detect the “Bad Neighbor” when your endpoint protection doesn’t
Detecting the CVE-2020-16898 vulnerability is quite simple. You can do it with a simple heuristic (aka solving problems using self-discovery and shortcuts to produce solutions).
The heuristic will parse all the incoming ICMPv6 traffic while looking for packets with an ICMPv6 type field of 134 that indicates the router advertisement. All that while an ICMPv6 option field of 25 indicates the RDNSS. The storage is a static buffer of 0x20 bytes that cannot handle the packets, causing buffer overflow that leads to BSOD.
After you narrow down the viability of the exploit or vulnerability to the two most plausible suspects used to leverage CVE-2020-16898, you can further confirm if the current RDNSS option also has a length field value that is even.
The heuristic will then drop a red flag at the end with this entry, as it’s likely part of a Bad Neighbor exploit crafted by a potential attacker who’s using remote assistance. It is also likely that the red flag you see over there has been raised by your detection tool for some other vulnerability. This can happen if your detection tool’s database is getting updated with the CVE-2020-16898. Unfortunately, not many detection tools can identify the vulnerability right now.
Top tip: if you run into some red flags when running scans but don’t know whether they’re indicators of the Bad neighbor vulnerability or not, check the IP section. If it’s remotely associated with IPv6 or shows ICMPv6 written on the side, then it is potentially CVE-2020-16898.
Up next, we dig into the mitigation steps, from Microsoft’s October patch to a workaround you can use if you can’t apply the patch for now.
Do note that the workaround is only intended to be executed if you can’t find the patch or if the patch doesn’t help you mitigate the vulnerability in the first place.
Mitigating Bad Neighbor / CVE-2020-16898 so it doesn’t make a comeback
The best course of action is to start with patching, as Microsoft has already released the patch for CVE-2020-16899 vulnerability.
But if that doesn’t seem viable in your context, you can always start disabling IPv6 either on the network interface controller or at the network perimeter by willingly dropping all ICMPv6 traffic – if it’s not essential nor required at the moment.
Additionally, you can also block or drop router advertisements the same way as with the ICMPv6 traffic on the network perimeter. The Windows Firewall and Windows Defender are unable to block the proof of concept when enabled. And so, you run the risk of not being able to confirm if the attack can become successful by tunneling ICMPv6 traffic over IPv4.
To fully confirm that the intended patch will work for you to mitigate this problem and that the vulnerability won’t come back stronger, check various nodes of actions attackers can leverage to further exploit the vulnerability in your system even with the patch applied or IPv6 traffic completely blocked.
If the malicious actor can use IPv4 to continue with the exploit, then the current patch won’t be able to fix the problem in its entirety and will likely resurface sooner than later. You might need to work with experienced developers or security engineers to find these action pathways. Until then, your best bet is to install Microsoft’s latest October patch.
If, for whatever reason, you find yourself unable to apply the patch, then you can go for the workaround and disable IPv6 traffic completely by using the following PowerShell command:
netsh int ipv6 set int INTERFACENUMBER rabaseddnsconfig=disable
The shell script above is only likely to work for Windows 10 (Version 1709) users and above and doesn’t require an immediate reboot after the command has been executed. Keep in mind that this command is only to be used if you can’t find the October patch for the problem and are looking for a workaround.
To re-enable the ICMPv6 RDNSS after you have applied the patch, run the following PowerShell command (reboot not required):
netsh int ipv6 set int INTERFACENUMBER rabaseddnsconfig=enable
A fresh vuln attracts motivated attackers
At this point, the vulnerability is still extremely new, and mitigation is still underway, so we can expect to see malicious actors trying to exploit it in creative and even unexpected ways.
The current patch will help you counteract the vulnerability that cybercriminals might try to exploit through malicious Windows Updates. The current legitimate patch from Microsoft seems to be working just fine, so, if you haven’t already installed it, then you should do that right now to mitigate it.
Because dealing with vulnerabilities sometimes feels like a whack-a-mole game, we recommend getting in the habit of continuously monitoring your systems for vulnerabilities. We constantly add and improve vulnerability scanners on Pentest-Tools.com (now at 20+!).
