3 ms·

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 concerne

by nullc 6y ago

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!

zamadatix 6y ago
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.
- nullc 6y ago
  Any idea if RA Guard will block unicast RAs? -- it wouldn't need to for the ordinary purpose of blocking misconfigured devices.
  - zamadatix 6y ago
    I can't speak for every implementation in the world but at least most block both as it actually takes more work to create a filter that only blocks multicast RAs. The filter to block all is an automatic ACL saying "ICMP Type 136, direction ingress, action drop" and a multicast only version would take additional checks to do less.
Pick-A-Hill2019 6y ago
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. [1] https://github.com/advanced-threat-research/CVE-2020-16898 https://github.com/advanced-threat-research/CVE-2020-16898 (HTH)

by nullc 6y ago

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!

zamadatix 6y ago

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.

nullc 6y ago
Any idea if RA Guard will block unicast RAs? -- it wouldn't need to for the ordinary purpose of blocking misconfigured devices.
- zamadatix 6y ago
  I can't speak for every implementation in the world but at least most block both as it actually takes more work to create a filter that only blocks multicast RAs. The filter to block all is an automatic ACL saying "ICMP Type 136, direction ingress, action drop" and a multicast only version would take additional checks to do less.

Pick-A-Hill2019 6y ago

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. [1] https://github.com/advanced-threat-research/CVE-2020-16898 https://github.com/advanced-threat-research/CVE-2020-16898 (HTH)