Anyone have lists of suggested filters for L3 switches and access points to block this traffic?
If I had a campus network of windows hosts I'd be very concerned about this!
CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
11–20 of 21 posts
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#12Anyone have lists of suggested filters for L3 switches and access points to block this traffic? If I had a campus network of windows hosts I'd be very concerned about this!
Most gear should have a feature called RA Guard which will block this put of the box and you should run it regardless of this vuln because your clients shouldn't be advertising as routers on your network.
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#13Anyone have lists of suggested filters for L3 switches and access points to block this traffic? If I had a campus network of windows hosts I'd be very concerned about this!
Most gear should have a feature called RA Guard which will block this put of the box and you should run it regardless of this vuln because your clients shouldn't be advertising as routers on your network.
Any idea if RA Guard will block unicast RAs? -- it wouldn't need to for the ordinary purpose of blocking misconfigured devices.
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#14"While Shodan.io shouldn’t be counted on as a definitive source, our best queries put the number of Windows Server 2019 machines with IPv6 addresses is in the hundreds, not exceeding approximately 1000. This is likely because most servers are behind firewalls or hosted by Cloud Service Providers (CSPs) and not reachable directly via Shodan scans." High priority issue, but I dont think we will see some massive wave of…
Shodan (or anyone else) can't really get an authoritative count of live IPv6 devices of any kind, because the address space is too big to scan using brute force. They had (have?) a clever semi-workaround for this, by getting themselves into one or more of the public NTP pools, and then port-scanning any IPv6 address that queried their NTP service, but I wouldn't consider that count anything like definitive. Regardles…
I read they got kicked off the NTP pool, but it's not the only way to enumerate IPv6 sources. There are many different ways to significantly reduce the search space including looking only at announced prefixes, searching common IPv6 addresses (i.e. the first few, last few, plus common mac address ranges for EUI-64) etc.
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#15Sophos says achieving RCE is extremely difficult: https://news.sophos.com/en-us/2020/10/13/top-reason-to-apply... I also assume that routers won't pass ICMPv6 RAs, so limited to a single network segment. And, only affects Windows 10.
Microsofts own CVSS score says 'attack complexity' is low. https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=...
Both can be true; BSOD is trivial, RCE can be very hard.
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#16It would be nice to know if this vulnerability is avoided by simply disabling IPv6, since almost no one uses v6 on LANs anyway.
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#17While true that it is extremely difficult to exploit (especially given the uptake of IPv6) there are some POC samples out there but I disagree with the severity rating awarded.
The 'juicy details' are as follows -
The validity of DNS options is checked with the Length field; that is, the value of the Length field in the RDNSS option is greater than or equal to the minimum value (3) and satisfies the requirement that (Length - 1) % 2 == 0. When an even length value is provided, the Windows TCP/IP stack incorrectly advances the network buffer by an amount that is 8 bytes too few.
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#18Anyone have lists of suggested filters for L3 switches and access points to block this traffic? If I had a campus network of windows hosts I'd be very concerned about this!
From [1]
Signature -
The Suricata signature for this vulnerability is located in cve-2020-16898.rules and contains the following logic:
alert icmp any any -> any any (msg:"Potential CVE-2020-16898 Exploit"; lua:cve-2020-16898.lua; sid:202016898; rev:1;)
The corresponding Lua script may be found in cve-2020-16898.lua. It contains the logic necessary to properly parse the ICMPv6 layer and identify potential exploitation of Bad Neighbor, as follows:
Once we've located the start of the ICMPv6 layer, we test the first byte of the layer to ensure that it's a Router Advertisement ICMPv6 packet (Type = 134) - if it isn't, we exit.
Since Suricata primitives have not been updated to parse the ICMPv6 options, we simply jump to the 17th byte of the ICMPv6 layer, since that's where the Options should start, if present (the first 16 bytes are static-length fields, per RFC 4443). From there, we loop over every Option until we run out of bytes in the packet. For each Option, we're only interested in the first two bytes: the Option Type and Length fields, respectively. While we ignore all Options that aren't RDNSS, for Option Type = 25 (RDNSS), we check to see if the Length (second byte in the Option) is an even number. If it is, we flag it. If not, we continue. Since the Length is counted in increments of 8 bytes, we multiply the Length by 8 and jump ahead that many bytes to get to the start of the next Option (subtracting 1 to account for the length byte we've already consumed).
With this rule, we also check to make sure that the Length is at least 3, since RFC 8106 requires it, but ultimately this check may be superfluous, since we're only concerned with whether the Length is even or not.
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#19Earlier quoted context omitted.
Shodan (or anyone else) can't really get an authoritative count of live IPv6 devices of any kind, because the address space is too big to scan using brute force. They had (have?) a clever semi-workaround for this, by getting themselves into one or more of the public NTP pools, and then port-scanning any IPv6 address that queried their NTP service, but I wouldn't consider that count anything like definitive. Regardles…
I read they got kicked off the NTP pool, but it's not the only way to enumerate IPv6 sources. There are many different ways to significantly reduce the search space including looking only at announced prefixes, searching common IPv6 addresses (i.e. the first few, last few, plus common mac address ranges for EUI-64) etc.
Correct. Shodan got kicked out for the following
"Hi Luca (and everyone),
I removed those servers yesterday. Brad had been helping look to see if others were doing something similar.
I think the behavior was falling well outside what's reasonably expected from a server operator participating in the pool."
https://seclists.org/oss-sec/2016/q1/239 "
Discussed on HN (2015) https://news.ycombinator.com/item?id=10979720 https://news.ycombinator.com/item?id=11058531
Pretty sucky behaviour from Shodan imo.
Re: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability
#20It would be nice to know if this vulnerability is avoided by simply disabling IPv6, since almost no one uses v6 on LANs anyway.
Then have a 'Nice To Know' free of charge. Yes, it only impacts IPv6 so if you don't handle IPv6 RA (or any IPv6 traffic) you are unaffected.