Presentation

Way back in September 2017 we experienced a strange event on our hosting network: momentary periods of packet loss to a customer server. Investigation revealed the problem to be related to IPv6 neighbour discovery and the size of neighbour tables on the directly adjacent routers. A similar traffic pattern hit our network in March 2018, but this time we were able to establish contact with the security researchers behind it.

What we found was fascinating to our network engineers: there were projects scanning the IPv6 address space in the wild! One of the fringe benefits discussed when promoting IPv6 was that the massive number of possible addresses means that scanning a subnet would be pointless; and yet here we are, finding our network being scanned.

This then prompted a voyage of discovery, and that voyage culminated in two bugs in MikroTik’s RouterOS:

• IPv6 neighbour discovery exhaustion in MikroTik RouterOS v6 (later would be known as CVE-2018-19298)
• IPv6 routing kernel memory exhaustion in MikroTik RouterOS v6 (later assigned CVE-2018-19299)

Marek reported the issues to the MikroTik support team in April 2018, and would periodically chase the vendor for updates over the course of the next ten months. Several colleagues were consulted during this period, and the wider NetMcr community involved in discussions about what should happen next. The plan of action became:

• request CVE numbers despite vendor’s unwillingness to treat these as security matters
• talk to NCSC
• announce the bugs’ existence on CISP
• keep trying for responsible disclosure with the vendor
• if no response proceed to informing CERTs
• and then prepare to move towards full disclosure

By February 2019 it was clear that the vendor was not prioritising fixing the issues as though they affected security, having previously argued that remote access was a security problem while remote resource exhaustion crashes were merely a bug. Marek informed MikroTik of a disclosure to be made at UKNOF43 in March, and began to get the word out to CERTs, CISP, NCSC, and others.

At this point, with the threat of full disclosure looming, things became rather busy. Several MikroTik users had spotted the subject of Marek’s talk, and distributors began hassling the vendor for an update. Numerous CERTs and similar organisations got in touch to find out more details about the vulnerability and if there were easy mitigations. The three weeks before the disclosure date were a whirlwind of communication and further research.

In the end, MikroTik pushed out fixes — but not before surprising everyone by making full disclosure of the vulnerability themselves. The road we all travelled to this point had been long and bumpy, but at least the users could now protect themselves. Since discussing matters with staff at MikroTik it is now Marek’s personal belief that CVE-2018-19299 took so long to get fixed because of miscommunications between Marek, MikroTik’s support team, and the developers at MikroTik: different ticket handlers at MikroTik support team touched the various tickets reported but did not assess things correctly, and so CVE-2018-19299 languished in a low priority queue.

Less than a month after Marek’s UKNOF talk, MikroTik announced their new security point of contact. We expect a lot went on behind the scenes to shift MikroTik’s internal processes and procedures to this more mature approach to handling security issues. We are glad of this change as it should go a long way to improving how their support and development teams engage with security researchers in future.

Read more in the PDF presentation, or watch the video below.