IPv6 bug in RouterOS exposes serious DoS risk

    [edit - advice revision added April 5th 2019]


    Summary of the problem:

    A recent RouterOS release addresses several bugs with IPv6 routing engine, one of which allows a remote attacker to send specially crafted IPv6 packets to any RouterOS device with IPv6 enabled to cause increasing memory consumption to the point of complete memory depletion and subsequent lock/reboot of the device.


    The bugs have been known for some time now, but MikroTik have only recently addressed the issue after some significant public outcry via this official MikroTik Forum topic

                     https://forum.mikrotik.com/viewtopic.php?f=2&t=147048

    For those who seek to avoid reading through the complete thread of (as of time of writing this article) 175 posts, a brief summary:
    • a security researcher (https://twitter.com/maznu) discovered several IPv6 bugs in RouterOS
    • the bugs were reported to MikroTik with full reproducability steps with no public disclosure
    • the security researcher is scheduled to make a public presentation on his findings on Tuesday 9th April 2019
    • once made public, DoS attack on vulerable systems is likely to become commonplace
    To begin with, it is important to acknowledge that the security researcher who has discovered this problem has acted properly and professionally at all times. All discovered flaws in RouterOS operation were reported to MikroTik some time ago, and has offered full cooperation to determine a viable solution at all times. Presenting findings of reasearch is a staple activity for any research professional, and the scheduled presentation next week was confirmed well in advance to allow plenty of time for MikroTik to determine an effective solution and for RouterOS users to mitigate against the threat.

    FWIW, a MikroTik spokesperson handling this case has acknowledged that they made a mistake in filing the original CVE/s and should have addressed the problem/s sooner. Hopefully this event will encourage them to adjust their handling of such reports better in future :-j


    What to do about it:

    MikroTik have now released an effective patch for this issue, albeit currently only in beta chain: 6.45beta23


    Official MikroTik comment is that there is some more optimisation to be done for routers with low RAM before it will be released into long term and stable versions, and that there is some priority on releasing these updates in advance of the problem going public next week.


    For low memory capacity routers (< 100MB) or in cases where upgrade is not feasible, firewall rules to limit new connection rates will help to defeat an attack using the exploit:


    /ipv6 firewall filter
    add action=drop chain=forward connection-mark=drop connection-state=new


    /ipv6 firewall mangle
    add action=accept chain=prerouting connection-state=new dst-address=\
    [your:network::/64] limit=2,5:packet add action=mark-connection \
    chain=prerouting connection-state=new dst-address=[your:network::/64] \
    new-connection-mark=drop passthrough=yes


    It is important to note that this problem affects routing function of ipv6, so packets with final destination of any host forwarded by a router will make that router vulnerable (i.e. input chain is no use for above rules)*


    Recommended actions:
    [edit - advice revision added April 5th 2019]

    Due to the potentially serious affect of an attack via this vector, we urge you to take immediate action!
    • If you do not require IPv6 for normal operation of your network/s, disable IPv6 by disabling the relevant package under system -> packages
    • If IPv6 is an important functionality for your networks, add the recommended IPv6 firewall rules shown above.
    • If limiting IPv6 throughput to such a low number of new connections per second is not feasible for your network or specific routerOS devices, upgrade to RouterOS v 6.45beta23.
    Although the details of this issue will not be published until next week (Tuesday 9th April 2019) already several other individuals have reported that they have been able to reproduce the reported behaviours just from analysis of the public discussions thus far. Therefore, it is reasonable to presume that your routers are vulnerable to DoS attack based on this problem right now! Immediate action is imperative! :-}

    Further information:
    Keep up to date with this issue by watching our tweets and facebook page, or contact us directly for further details!

    As always, questions to our support team are most welcome!
    Edit April 5 2019:
    MikroTik have now released patch to address this issue in bugfix/long-term (6.43.14) and stable (6.44.2) release channels.

    Our recommendation now is to upgrade to RouterOS version 6.44.2 (bugfix) as soon as possible!

    *To clarify further, the particularly nasty issue (the one from this recent discussion that has caused the most angst) is related to the ipv6 routing engine. Essentially, an attack on a specific router can be made by sending 'specially crafted' IPv6 packet to any IPv6 host on any network via the target router. So such malicious packets could have destination address of another router server, host, client on your network. The structure/content of such malicious packets are not matchable by any of the available packet attributes of MikroTik firewall, and therefore, the only way to effectively limit excess dodgy packets is to limit ALL ipv6 connections to a limited rate.


    Typically, attacks that target a specific device by sending packets with destination address OF THAT device which can be mitigated using input chain of firewall. For reasons outlined above, input chain can not be used for this case.


    Therefore, until the bugfix/longterm and stable versions include this recent fix, core routers processing significant (more than 2 new connections per sec, burst of 5) we recommend to run the 6.45beta23 software release, and firewall filters for all other routers.


    Of course if you do not really *need* ipv6 right now, it is also worth considering to just temporarily turn off IPv6 in the interim (by disabling IPv6 package, disable all public ipv6 addresses, or just remove network advertisement from your BGP)


    Disable the package if you can't trust anyone - including customers - who even only have link local ipv6 access!

    Published