Hi. I looked into some of our routers log… and found some strange activity.
aug/25 17:52:12 system,info verified routeros-mipsbe-6.42.7.npk
aug/25 17:52:12 system,info installed routeros-mipsbe-6.42.7
aug/25 17:52:12 system,info router rebooted
[...]
aug/25 18:16:47 system,info script removed by admin
aug/25 18:17:07 system,info script removed from scheduler by admin
[...]
(passwords changed here)
[...]
sep/01 22:07:44 firewall,info ---WinBox port--- input: in:ether1 out:(unknown 0), src-mac 6c:9c:ed:34:bb:71, proto TCP (SYN), 5.101.6.170:56680-> xxx.xxx.xxx.xxx:8291, len 40
[...]
sep/10 00:36:04 firewall,info ---WinBox port--- input: in:ether1 out:(unknown 0), src-mac 6c:9c:ed:34:bb:71, proto TCP (SYN), 5.101.6.170:53804->xxx.xxx.xxx.xxx:8291, len 40
[...]
sep/10 01:53:20 firewall,info ---WinBox port--- input: in:ether1 out:(unknown 0), src-mac 6c:9c:ed:34:bb:71, proto TCP (SYN), 5.101.6.170:50515->xxx.xxx.xxx.xxx:8291, len 40
[...]
sep/10 10:53:08 firewall,info ---WinBox port--- input: in:ether1 out:(unknown 0), src-mac 6c:9c:ed:34:bb:71, proto TCP (SYN), 5.101.6.170:50832->xxx.xxx.xxx.xxx:8291, len 60
[...]
sep/11 07:02:10 system,info,account user test logged in from 5.101.6.170 via api
sep/11 07:02:10 system,error,critical login failure for user admin from 5.101.6.170 via api
sep/11 07:02:11 system,info,account user test logged out from 5.101.6.170 via api
[...]
sep/11 15:42:48 system,info,account user test logged in from 5.101.6.170 via api
sep/11 15:42:49 system,error,critical login failure for user admin from 5.101.6.170 via api
sep/11 15:42:50 system,info,account user test logged out from 5.101.6.170 via api
I logged only the NEW connections.
So, what did I forgot ? Or have we another backdoor in 6.42.7 somewhere to steal passwords (which is looong and hard to bruteforce I think).
6.43 for Stable and 6.44beta6 for Testing. I’m on the stable channel because I got automatically inserted into it. Don’t you see the flaw? Aren’t those releases as well? Or are we Stable and Testing users not special enough, like those fancy Long-term ones?
7 devices are on Stable because I never changed their setting. The last one if it i bought this year.
Why would you put every beta release on a security announcement blog?
Please subscribe to the releases RSS or Email list, those exists for 10 years or more.
The blog is for long-term stable releases and security announcements or other monumenally important things, not every nightly build release.
Now we’re talking. I was subscribed to it until it stopped sending me emails, without me unsubscribing. Where can I find that list? That solves the complete issue. I just thought they’ve dropped the list.
I can’t find any “official” link to the URL I mentioned above. It appears to be part of the “Account” section, but I have no account on the mikrotik.com website (only on the forum).
Oh jesus christ. It’s in big red at the bottom of the page… I’m a genius… as in stable genius…
Thankfully those CVEs appear to be fixed in 6.40.9 and 6.42.7.
Good to see that MikroTik is taking RouterOS security seriously with those CVEs. Meanwhile, I’m still waiting for MikroTik to confirm when Ticket#2018041622003823 (unauthenticated remote crash, does not require any management interface to be open to the attacker) will be fixed.
I have no idea what vulnerability is it about and to be honest, I don’t want to know. However, if what you say is true, then there is such issue for almost half year? Sounds almost unbelievable.
Did you get any reply since you reported it?
Can it be prevented with firewall?
Maybe you need to publish it to generate some pressure…
Thats why I asked Maznu to give bit clearer description. I may not be a blind fanboy but I still believe you guys are doing your best and I find it hard to believe you would leave real reported vulnerability without reaction.
If it is just flood attack which overwhelms router and cause restart due to for example watchdog timer which can’t get ping reply, then I wouldn’t call it vulnerability.
He does not need to share detailed info if he is concerned that it is real threat. However if he blame you for missing reponse, he might share a bit…
Yes, it is exactly that. Denial of service from some type of IPv6 packet flood, where router runs out of resources. It was answered, that we accept this as a bug, but we would not call it a vulnerability, because there are many ways how to exhaust resources of any device.
Talking about IPv6 attacks. Get https://github.com/vanhauser-thc/thc-ipv6 and try it in your subnet with different options while some clients will immediately have 100% of cpu usage. And you cannot block all of those attacks on even modern switching hardware.
If I send IPv6 packets at a gigabit across a gigabit-capable router with the same src+dst addresses, everything is fine. Your routers route packets just fine.
But if I send IPv6 packets at a gigabit across the same router — but the packets have DIFFERENT DST addresses — then the router crashes.
NOTE: This is NOT IPv6 neighbour exhaustion — the router being “attacked” does not need to be directly connected to the DST addresses. It is caused by the router transitting those packets. It took many emails for your team to realise this, because they were deflecting this as “resource exhaustion” caused by IPv6 ND. Your team finally accepted that this is a problem for routers in between the SRC and DST subnets.
It can be firewalled by not routing any IPv6. But if you have a RouterOS device anywhere in the path between one subnet and another subnet, even if not directly connected to that router, and it is forwarding IPv6 packets, it is vulnerable to being crashed.
I'm starting to believe that this is the only way forward, sadly.
A router should be able to route packets. It should not crash just because lots of different addresses were used. The quickest way to demonstrate/test the vulnerability is to use a "flooding tool" — but we see organisations are starting to scan IPv6 address space, which if done quickly enough, will cause a crash for an IPv6 transit provider.
I don't believe IPv6 ND should crash RouterOS either — that's also a denial of service security issue in my mind. But the ticket I refer to affects all RouterOS devices between the source and destination, regardless of whether the attacker or target subnet are directly connected to the victim router.
Here is the original message I sent to support on 2018-04-16:
I have just run a trial with two MikroTik devices, all running latest release candidate.
RaspberryPi ---- hAP ac2 ---- hEX
On the raspberry pi, eth0 = 2a01:9e02:0:4242:xxxx:xxxx:xxxx:xxxx/64 (autoconf address, doesn’t matter)
On the hAPac2, bridge = 2a01:9e02:0:4242::1/64
On the hAPac2, ether2 = 2a01:9e02:0:1::2/64
On the hEX, ether2 = 2a01:9e02:0:1::1/64
On the hEX, target (a bridge) = 2a01:9e02:0:666::666/64
There are static routes on the hAPac2 and hEX so that 2a01:9e02:0:666::/64 and 2a01:9e02:0:4242::/64 can route to each other.
If I run this on the Raspberry Pi:
XXXREDACTEDXXX 2a01:9e02:0:666::/64
Then the hAPac2 crashes. This is a problem, because I have used TTL-exceeded packets (cannot be firewalled), and I have crashed a router which is transiting the packets. The target of the ICMP flood, 2a01:9e02:0:666::/64, is not directly connected to the router which crashed. A supout is attached.
This is a remote denial of service attack against RouterOS. I believe MikroTik should get a CVE, and fix this urgently.
As Normis already wrote, these are not really bugs but you are merely exhausting the capacity of the router, either for IPv6 ND or for IPv6 connection tracking.
When you are facing such attacks on the local network, you are in trouble. Especially when you have a small router which does not have gigabytes of RAM.
The issue is: when there would be some limit set that makes the router not crash, it would then be possible to claim the attack leads to denial-of-service, as
an attacker that fills up the capacity to the limit will deny further legitimate traffic from other users. So that is not really a solution, and a crash may in fact
be better as then the router starts with a clean slate after the crash so at least the normal users have service again.
It is a well-known problem which is worse in IPv6 because of the larger address space, but can be present in IPv4 as well.
It is just a fact that it is difficult to defend against all possible cases of wrongdoers.
When you get such attacks from the internet side, you can at least do firewalling that drops unwanted incoming connections, preferably in the raw table.
For example, you can use an address list with a firewall rule that adds the source address of any traffic going to internet with a timeout of say 4h, and
that address list also holds the static addresses of any systems you want to be reachable from outside. Then on the internet interface you immediately
drop all traffic not towards members of that address list (in the raw table). This makes it impossible to saturate the router by sending to many random
destination addresses local to the router or further in the network.