Community detection: CVE-2020-16898

This month’s Microsoft Patch Tuesday included a severe Remote Code Execution vulnerability in the way that Windows TCP/IP handles IPv6 “Router Advertisement” ICMP messages. Due to the severity and wide scope, we in Corelight Labs immediately set about preparing a Zeek package with the intention of releasing it to the Zeek community before the inevitable DOS/RCE PoCs emerge. You can access this package here: https://github.com/corelight/CVE-2020-16898

This blog is a brief story of a few interesting points that occurred to me during the less than 24 hours it took to turn around this package from dev to testing on real-world network traffic to release.

The vulnerability

The point of this blog isn’t to elaborate on the vulnerability itself. This material quoted from the Microsoft article paints an excellent, high-level picture:

Racing the exploit developers

Clearly any vulnerability, be it an RCE or a DOS (this case turns out to be both) that resides in the TCP/IP stack itself is bad news in that the vulnerability exists on a lot of machines and is deeply embedded. The other aspect that seemed interesting is that it related to IPv6 ICMP messages. Given this, we knew this bug would be attractive to exploit developers and hence thought it likely that a DOS PoC would emerge soon, possibly be followed by an RCE exploit. Time was of the essence, and so myself in Australia and my Corelight Labs teammate Yacin Nadji on the East coast in the U.S. followed the sun to get this out the door quickly.  

A complex packet

Now, unless you have previously had cause to delve deeply into IPv6 Router Advertisement ICMP messages (or had memorized RFC 4443 and RFC 8106) you’d perhaps be forgiven for being more than a little awestruck by the amount of data/structures contained within these messages. It was certainly news to me and I will admit to initially being doubtful that we’d be able to turn around a detection package quickly due to the complexities I thought were involved.

Thank you, Zeek developer from the past!

Straight after my initial concern, it was Zeek to the rescue and I was buoyed to find that the icmp_router_advertisement event faithfully parsed all the data from these packets, making them available in scriptland – a term commonly used to mean the data can be referenced easily by Zeek scripts. I was thankful to the developer who built this parser. They probably wouldn’t have imagined that one day in the future it would be used exactly in this way, and that it would seamlessly work with IPv6. This aspect is actually a great and simple example that shows the value of Zeek. It made creating a detection script very easy: it probably only took an hour or less in fact. It was much easier than I had first imagined, as all four elements described in this very useful blog by Mcafee were already available just waiting for someone to use them! Detection was then a simple matter of checking how to reference each data element properly and then combining all four indicators in an if conditional and raising a notice if they are all seen together. 

Developing rapid response detections

Creating detections prior to a proven PoC being available can be a challenge as you may not have pcaps to double-check if your work correctly identifies True Positives. Happily, just prior to release we came across a pcap that included all of the elements, and our package raised the detection notice as expected, which was encouraging. However, even as no PoC exploit tool existed, the choice to release our package ASAP was clear, as:

• We were able to do significant testing on real-world network traffic to ensure no False Positives;
• We successfully tested the logic end-to-end on a synthetic pcap;
• The detection logic was very simple, and low risk;
• The detection logic was also independently arrived at by other security researchers, which served as good validation (see next paragraph);
• Releasing the script has more benefit prior to a PoC being available in that organizations can protect themselves now, and not need to wait for an incident and scramble to deploy on a Friday evening.

The Zeek community activates

Anyone who has been around the Zeek community knows what a vibrant and active community it is. In fact, at the same time we were developing our package, it turns out that at least two other researchers in the community were also developing scripts independently. These packages were released around the same time and I link to these below. Given time zones and the compressed timespan, it was great to have this cross-validation.

Of note, these packages were all released on day 2 of virtual ZeekWeek 2020, so the element of community is even stronger right now. Check out the general Zeek slack here if you are interested.

1. https://github.com/initconf/CVE-2020-16898-Bad-Neighbor/blob/master/scripts/CVE-2020-16898-Bad-Neighbor.zeek
2. https://github.com/esnet-security/cve-2020-16898

And finally!

With all of the rapid response packages that Corelight develops, we appreciate that the threat environment in these early days is very fluid. New information commonly becomes available as the exploit developers work towards ultimately producing working exploits. At the same time, we respond to these developments by tuning our packages to account for newly available information. Most importantly, we also find your feedback on the use of these packages extremely valuable, so please contact us if you have any feedback or suggestions.