Community discussions

 
User avatar
maznu
Member Candidate
Member Candidate
Posts: 149
Joined: Tue May 05, 2015 11:12 am
Location: Manchester, UK
Contact:

Re: Security announcement blog

Fri Oct 12, 2018 10:36 am

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:

atk6-ndpexhaust26 -T eth0 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.
Marek
 
pe1chl
Forum Guru
Forum Guru
Posts: 4798
Joined: Mon Jun 08, 2015 12:09 pm

Re: Security announcement blog

Fri Oct 12, 2018 11:14 am

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.
 
User avatar
maznu
Member Candidate
Member Candidate
Posts: 149
Joined: Tue May 05, 2015 11:12 am
Location: Manchester, UK
Contact:

Re: Security announcement blog

Fri Oct 12, 2018 11:27 am

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.
Happens with IPv6 set to NOTRACK. It's not tracking causing this.
Marek
 
pe1chl
Forum Guru
Forum Guru
Posts: 4798
Joined: Mon Jun 08, 2015 12:09 pm

Re: Security announcement blog

Fri Oct 12, 2018 12:19 pm

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.
Happens with IPv6 set to NOTRACK. It's not tracking causing this.
So it is ND (also indicated by the name of the tool).
You will not be affected when you block the incoming traffic on your internet interface so it is not routed towards the interface where ND is happening.
ND is like ARP. It is used to find the hardware address corresponding to the IPv6 address. Transit routers to not use it. (but they could use tracking)
 
User avatar
maznu
Member Candidate
Member Candidate
Posts: 149
Joined: Tue May 05, 2015 11:12 am
Location: Manchester, UK
Contact:

Re: Security announcement blog

Fri Oct 12, 2018 12:55 pm

So it is ND (also indicated by the name of the tool).
No, you're doing exactly the same thing MikroTik support did — that is, not reading the addresses that are being targetted. Despite using a tool for ND crashing, it is not ND which is causing the problem — it's just an easy to find tool which will send ICMPv6 packets to lots of different destination addresses.

MikroTik Support eventually read my emails properly, after a week of back-and-forth, and acknowledged this problem:
I can confirm the problem, in one case forwarding of ipv6 traffic eats all the memory. There is also another case when kernel is crashing, but also can be related to low memory.
We will look into this problem.
Last edited by maznu on Fri Oct 12, 2018 2:37 pm, edited 1 time in total.
Marek
 
User avatar
maznu
Member Candidate
Member Candidate
Posts: 149
Joined: Tue May 05, 2015 11:12 am
Location: Manchester, UK
Contact:

Re: Security announcement blog

Fri Oct 12, 2018 1:23 pm

ND is like ARP. It is used to find the hardware address corresponding to the IPv6 address. Transit routers to not use it. (but they could use tracking)
To refer you back to my post, and why ND is not to blame (despite using an "ND exhaustion tool"):
RaspberryPi ---- hAP ac2 ---- hEX

If I run this on the Raspberry Pi:

atk6-ndpexhaust26 -T eth0 2a01:9e02:0:666::/64

Then the hAPac2 crashes.
The question I had for MikroTik was: why is the hAP ac2 crashing? The target subnet is connected to the hEX. The hEX is doing ND, the hAP ac2 is not doing ND. Yes, the hEX crashes (it should not — the IPv6 neighbor table should not grow without bound!). But the hAP ac2 also crashes, and for a different reason to ND exhaustion. Guess what? CCRs used for transit also crash. That means a customer of an ISP running MikroTik routers as their BGP edge can use the ND exhaustion tool (targeting a subnet "out on the Internet") and crash their own ISP's MikroTiks.
Marek
 
GregC
just joined
Posts: 4
Joined: Fri Oct 18, 2013 6:53 pm

Re: Security announcement blog

Fri Oct 12, 2018 3:28 pm

While we are on the topic of security and forgive me if this has been addressed before.
Someone hacks the router as it happened in the resent past or perhaps they find another hole in the future. Why is it that if we forget the username and/or password there is no way to see it or export it? This is good, and is very secure and that is the way it should be.
This takes me to the real question of this post. If I have VPN enabled and someone access the router, export the configuration, they can see the /ppp secret information and ipsec-secret.
For example:
/ppp secret
add name=myusername password=mypassword profile=VPN
Is there are reason why this has to be this way? If there is a better way please let me know. Thank you!
 
pe1chl
Forum Guru
Forum Guru
Posts: 4798
Joined: Mon Jun 08, 2015 12:09 pm

Re: Security announcement blog

Fri Oct 12, 2018 4:47 pm

Not "someone access the router". When "some user" logs in to the router they cannot see this info. They have to be an administrator to see it.
The reason why this data is stored in plaintext is that it has to be available in plaintext for the protocols it is used for (IPsec, xCHAPx).
So you cannot store a hash value of those values.
 
pe1chl
Forum Guru
Forum Guru
Posts: 4798
Joined: Mon Jun 08, 2015 12:09 pm

Re: Security announcement blog

Fri Oct 12, 2018 4:50 pm

I have never seen increasing memory usage due to IPv6 forwarding. But apparently your use case or configuration is different.
 
GregC
just joined
Posts: 4
Joined: Fri Oct 18, 2013 6:53 pm

Re: Security announcement blog

Sat Oct 13, 2018 12:49 am

Not "someone access the router". When "some user" logs in to the router they cannot see this info. They have to be an administrator to see it.
The reason why this data is stored in plaintext is that it has to be available in plaintext for the protocols it is used for (IPsec, xCHAPx).
So you cannot store a hash value of those values.
@pe1chl thank you for your response.
 
User avatar
maznu
Member Candidate
Member Candidate
Posts: 149
Joined: Tue May 05, 2015 11:12 am
Location: Manchester, UK
Contact:

Re: Security announcement blog

Sat Oct 13, 2018 10:27 am

I have never seen increasing memory usage due to IPv6 forwarding. But apparently your use case or configuration is different.
This is an out-of-the-box configuration, plus IPv6, NOTRACK, and some static routes.

MikroTik confirmed to me back in March that they have reproduced this issue. I'm just hoping that they treat it as what it is — a remote, unauthenticated denial-of-service — and fix it soon.
Marek

Who is online

Users browsing this forum: No registered users and 4 guests