How IPv6 helps routers break

Foreword

I woke up today with the thought that a huge number of instructions for configuring NAT are advised to use a line like this:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 

Many understand the problems of this design, and advise adding:

 iptables -A FORWARD -i ppp0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT 

But, often, they forget to set the FORWARD table with the default DROP action, or add the REJECT rule to the end of the table.
At first glance, it seems, everything seems normal. However, this is not the case. The fact is that if you do not prohibit the routing of traffic from a WAN port to a WAN port, someone from your WAN network (suppose that the provider drives the entire entrance into one / 24) can route traffic through you simply by setting your IP as a gateway. All modern SOHO routers take this into account, but an inexperienced administrator who makes a router under normal linux may not know or forget about it. There were no such routers in the subnet of my provider, and my plan to take over the world failed. However, the article is not about that.

Magical colon

As you may know, many modern programs and services are bound to IP :: (two colons), not 0.0.0.0 , as it was before. IPv6 address :: means the same as IPv4 0.0.0.0 , i.e. "We listen to all interfaces". Many people believe that if a program listens on ::, then this socket can only accept IPv6 connections, but this is far from the case.
In IPv6, there is a so-called mapping of IPv4 addresses to the IPv6 range. If the program listens on the socket :: and it is accessed from the IPv4 address 1.2.3.4 , then the program will receive a connection from the address :: ffff: 1.2.3.4 . This can be avoided by doing:

 sysctl -w net.ipv6.bindv6only=1 

But this is not always necessary, since It is usually convenient that the program listens to one socket, and it can receive connections using two protocols at once. In almost all distributions, IPv6 sockets behave this way, i.e. bindv6only = 0.
')

fe80 and his friend ff02

If you are not stuck in the 90s, you are guaranteed to come across IPv6 without knowing it. Absolutely all modern operating systems have IPv6 support enabled by default, which means that each (except for rare exceptions) interface is automatically assigned an IPv6 Link-Local address that starts with fe80 :: . Moreover, in some cases, this address is obtained simply by encoding the MAC address.
It would seem that finding Link-Local addresses should be problematic, they are still long and scary, but here we come to the aid of a multicast range ff02 :: .

There is such a cool address: ff02 :: 1 . If you ping it (necessarily with the indication of the interface, because this is the Link Local address), then all the computers on the network will respond:

 % ping6 ff02::1%enp4s0 PING ff02::1%enp4s0(ff02::1) 56 data bytes 64 bytes from fe80::21f:d0ff:fea2:46a3: icmp_seq=1 ttl=64 time=0.056 ms 64 bytes from fe80::fe8b:97ff:fe66:9100: icmp_seq=1 ttl=64 time=1.60 ms (DUP!) 64 bytes from fe80::226:9eff:fe6d:22a0: icmp_seq=1 ttl=64 time=1.62 ms (DUP!) 64 bytes from fe80::f2de:f1ff:fe27:3685: icmp_seq=1 ttl=64 time=1.70 ms (DUP!) 64 bytes from fe80::62a4:4cff:fe7b:1c90: icmp_seq=1 ttl=64 time=2.95 ms (DUP!) 64 bytes from fe80::fac0:91ff:fe32:5bbe: icmp_seq=1 ttl=64 time=3.02 ms (DUP!) 64 bytes from fe80::226:18ff:fe9e:4b3a: icmp_seq=1 ttl=64 time=3.09 ms (DUP!) 64 bytes from fe80::ba70:f4ff:fe8b:8dda: icmp_seq=1 ttl=64 time=3.14 ms (DUP!) 64 bytes from fe80::62a4:4cff:fea2:aee0: icmp_seq=1 ttl=64 time=3.27 ms (DUP!) 64 bytes from fe80::224:54ff:fedb:d17d: icmp_seq=1 ttl=64 time=3.93 ms (DUP!) 64 bytes from fe80::2a1:b0ff:fe40:904: icmp_seq=1 ttl=64 time=4.21 ms (DUP!) 64 bytes from fe80::76d0:2bff:fe69:31d8: icmp_seq=1 ttl=64 time=6.09 ms (DUP!) 

As we can see, 11 devices responded. By the way, this address is very convenient to use if you, for example, have a server configured to receive an address via DHCP, and DHCP has dropped, or if you have directly connected to the server port, and you don’t want to raise DHCP. You just have to go to fe80-address via ssh.

If you ping the address ff02 :: 2 , then all IPv6 routers on the network will respond. Unfortunately, in my case there were none.

We scan routers

I decided to scan these addresses via nmap, and this is what happened:

 % nmap -6 -T4 --open -n -iL list.txt 

For IPv4, all these ports are closed.
As we can see, many routers have Telnet, a web interface and DNS from outside on IPv6.
What does this mean? It's simple - the developers of the router firmware simply forgot IPv6.

Open telnet routers:

• ASUS RT-N10 (2.0.3.2)
• ASUS RT-G32
• ASUS RT-G32.C1 (2.0.2.6)
• Upvel UR-312N4G

Open web routers:

• D-Link DIR-615 (E4, 5.11NV)
• D-Link DIR-615 (E4, 5.11RU)

Many of them had standard admin / admin passwords.
On most of these routers, ip6tables (iptables for IPv6) was simply missing. The developers had to either disable the IPv6 support in the kernel altogether, or make sure that the http and telnet demons are listening to 0.0.0.0 , but not :: but, for some reason, they did not do that.

What if…?

If IPv6 was somehow configured on the router, and, accordingly, IPv6 packet routing was enabled (net.ipv6.conf.all.forwarding = 1), and ip6tables was either not configured at all or configured incorrectly, then just as in the case of IPv4, route packets through this router.

Conclusion

I have already sent emails to some companies about these vulnerabilities, but I have not had time to some. In any case, the letters will be sent to all.
Use IPv6, do not forget about it.

PS

For me it was a surprise that browsers do not know how to open addresses with an indication of the interface. I didn’t manage to open the link like http: // [fe80 :: a: b: c: d% enp4s0] in all browsers. They say that the percent sign needs to be escaped, i.e. http: // [fe80 :: a: b: c: d% 25enp4s0], but it didn't work out for me. I had to use port forwarding.