Introduction
All too often when we conduct pen tests against organizations we find a robust security posture against their Iv4 infrastructure. They lock down services, use a host-based firewall and generally follow best practice security guidelines. However, these same organizations are often unaware of IPv6. While they may not explicitly use IPv6, it is nonetheless enabled by default on almost all modern systems and can provide an interesting attack vector.
The purpose of this blog is to highlight, through a real-life example, the dangers and impact of not testing all end-points. Testing everything is something we routinely do and would encourage others to do to ensure a robust security posture.
An Example:
Here we have port scan results from a Linux system on address 192.168.9.19 that was scanned from a host on the same physical network:
Nmap scan report for 192.168.9.19
Host is up, received arp-response (0.0021s latency).
Scanned at 2018-04-04 10:28:36 +0630 for 105s
Not shown: 65532 filtered ports
Reason: 65532 no-responses
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 64 OpenSSH 7.5p1 (protocol 2.0; HPN-SSH patch 14v12)
25/tcp open smtp syn-ack ttl 64 Postfix smtpd
5666/tcp open tcpwrapped syn-ack ttl 64
MAC Address: 00:80:10:22:38:66 (Commodore International)
However, by default, modern operating systems usually enable IPv6 with automatically configured addresses. In contrast to IPv4, IPv6 actually operates IP at layer 2 in the OSI model instead of using a separate protocol like ARP in the case of IPv4. Therefore when an IPv6-enabled system is connected to a network, it will configure itself with a layer 2 address in the fe80::10 address range based on its MAC address and will listen to the default IPv6 multicast addresses (ff02::/10) for routers that advertise their presence.
One special multicast address is ff02::1, which is for all IPv6 capable nodes connected to the local network segment. If you send ICMP echo requests to this address, in theory every IPv6 machine on the local network should respond to it, even if IPv6 has not been explicitly configured:
# ping6 ff02::1%eth0
PING ff02::1%eth0(ff02::1%eth0) 56 data bytes
64 bytes from fe80::280:10ff:fe22:3866%eth0: icmp_seq=1 ttl=64 time=0.031 ms
64 bytes from fe80::250:56ff:fe8c:3172%eth0: icmp_seq=1 ttl=64 time=1.82 ms (DUP!)
64 bytes from fe80::250:56ff:fe8c:478c%eth0: icmp_seq=1 ttl=64 time=3.03 ms (DUP!)
64 bytes from fe80::80b1:c330:51b8:5a22%eth0: icmp_seq=1 ttl=64 time=3.08 ms (DUP!)
64 bytes from fe80::ec4:7aff:fe42:2b90%eth0: icmp_seq=1 ttl=64 time=3.63 ms (DUP!)
So based on the ping6 output, there are 5 IPv6-capable devices on the local network, including the device from which we are pinging. We can also see a device with IPv6 address fe80::280:10ff:fe22:3866. This corresponds to MAC address 00:80:10:22:38:66 which we saw associated with the IPv4 address previous scanned. We now perform a port scan of this IPv6 address to see what's listening:
Nmap scan report for fe80::280:10ff:fe22:3866
Host is up, received echo-reply ttl 64 (0.0033s latency)
Scanned at 2018-04-04 10:32:47 +0630 for 22s
Not shown: 65530 closed ports
Reason: 65530 resets
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 64 OpenSSH 7.5p1 (protocol 2.0; HPN-SSH patch 14v12)
25/tcp open smtp syn-ack ttl 64 Postfix smtpd
5666/tcp open tcpwrapped syn-ack ttl 64
3128/tcp open http-proxy syn-ack ttl 64 Squid http proxy 3.4.8
6379/tcp open redis syn-ack ttl 64 Redis key-value store
MAC Address: 00:80:10:22:38:66 (Commodore International)
The same ports we saw from the IPv4 address port scan are open, 22/25/5666 and they seem to be running the exact same services. But while the IPv4 address filtered other ports, all unused ports on the IPv6 address are showing up as closed which means the system is actively rejecting connection attempts rather than ignoring them. Most operating systems will reject attempts to connect to unused ports, while most host and network based firewalls are configured to ignore such attempts. Comparing rejected connection attempts versus silently ignored connection attempts often helps in initial reconnaissance.
Another interesting result Is that the IPv6 scan has shown 2 additional ports which were not present on the IPv4 address, a Squid proxy on port 3128 and a Redis instance on port 6379. Let's take a deeper look at that Redis instance.
The Redis security documentation at https://redis.io/topics/security states that Redis is optimized for performance rather than security and that firewall rules should be used to restrict access to its network service. In this case the admin of this host had done exactly that. They IPTables rules on the host were configured to allow access from anywhere to ports 22, 25 and 5666, allow access to port 6379 from a couple of specific addresses, and to drop all other traffic. However, since this had only been done using IPTables and not its IPv6 counterpart IP6Tables, these access control rules don't extend to IPv6.
Therefore, it was possible to connect to the Redis instance over IPv6 without authentication:
# redis-cli -h fe80::280:10ff:fe22:3866%eth0 -p 6379
[fe80::280:10ff:fe22:3866%eth0]:6379> echo test
"test"
[fe80::280:10ff:fe22:3866%eth0]:6379>
Conclusion
The key take away from this blog post is that the people who configured this system were security aware. They went to the effort of configuring local firewall rules to restrict access to potentially vulnerable services such as Redis. However, they gave no consideration, possibly due to a lack of awareness, to the presence of IPv6 on the system. Many system and network administrators have no experience with IPv6 and tend to completely ignore it.
When either IPv6 or IPv4 are set up for auto configuration, but no configuration servers are present on the network, other attacks are possible by introducing rogue servers to answer these configuration requests. Modern operating systems prefer IPv6 over legacy IPv4 and will use a rogue IPv6 connection by default if one is available. This allows an attacker to hijack traffic such as DNS lookups. Tools and write ups to exploit this configuration attack are already available, for instance https://github.com/fox-it/mitm6 and thus aren't covered in greater detail in this post.
A quick fix for issues such as this would be to disable IPv6, however this is not recommended for a variety of reasons. IPv6 is the future and a lot of modern systems and software are designed with it in mind. Some applications will now fail to work correctly if IPv6 is disabled. Similarly, while your organization may not yet be using IPv6 officially, it's only a matter of time before it's required so it makes sense to prepare and gain experience at the earliest opportunity.
Instead of disabling IPv6, consider the presence of IPv6 and ensure that any security rules being used with IPv4 are also replicated to IPv6. You might also want to consider deploying and using IPv6 on the network in order to gain experience of it. IPv6 services should be monitored in the same way as IPv4, and the presence of any rogue servers should be identified and dealt with accordingly.
