Dear Readers of Insinuator,
tldr;This blogpost presents a measurement study of a current security state regarding to open ports on a direct comparison of IPv4 and IPv6. The study analyses almost 58,000 dual-stacked domains in order to find discrepancies in applied security policies. We further discuss the potential reasons and, more importantly, the implications of the identified differences. \tldr;
For those of you who couldn’t participate at Troopers Conference 2016 in Heidelberg or watch my talk at the IPv6 Security Summit, I want to recap some of the most important parts of my research in this blogpost.
During the last months I was evaluating the security of dual-stack systems as a part of my Thesis at HFU Furtwangen. A Dual-stack system is basically a server or a host which can be accessed both via IPv4 address and IPv6, so both IP Protocols on the same stack concurrently. Since this sounds like a very straight forward way to do it, there are several things to consider before operating dual-stack connections. One of the most important RFC regarding to this topic is RFC7381 (Enterprise IPv6 Deployment Guidelines), which describes needed measures while deploying dual-stack servers. In my profession as a security researcher I was focusing on finding potential security threats that could occur in performing dual-stack connections while reading the RFC. One of the first things that the RFC mentions due to security is that “running a dual-stack network doubles the attack exposure as a malevolent person has now two attack vectors: IPv4 and IPv6”. What surprised me to see in this RFC was that there were actually already security guidelines described such as the following phrase:
“It should be noted that in a dual-stack network, the security implementation
for both IPv4 and IPv6 needs to be considered, in addition to security
considerations related to the interaction of (and transition between) the
two, while they coexist[CCH+14].”
Sounds interesting doesn’t it? While continuing reading the RFC i stumbled over the following part which immediately attracted my attention:
„[…] This simply means that all routers and hosts operating in a
dual-stack environment with both protocol families enabled
(even if by default) must have a congruent security policy for
both protocol versions.”
This sentence basically says that you have to implement security measures for every service running on your dual-stack system independently of the protocol version. For example, if your server acts as a webserver and you only want port 80 (HTTP) and port 443 (HTTPS) to be visible to the public you have to implement the security measurements for IPv4 and IPV6 congruent. In this case it would be the firewall rules for allowing traffic on port 80 and 443. As you can already see from this example performing a dual-stack hosts is also an operational overhead prone to mistakes. My hypothesis in the beginning of my thesis was that at the time administrators enabled dual-stack on their systems, they simply forgot (or didn’t knew) about the security mechanisms of IPv6 and therefore left their systems open to an unpredictable risk. In the following scenario, I want to briefly explain the risk I saw in operating dual-stack connections. As you can see in the following picture several ports along with different services are running on the dual-stack system. Most of these services are only used internally by the server and the administrator decided to filter every out- and incoming traffic to these services using a IPv4 (only) firewall. This situation worked perfectly until the day the administrator decided to implement IPv6 connectivity to the system. Once the IPv6 address is activated on the interface every service running and capable of IPv6 is now binding to the systems IPv6 address and from now on accessible via IPv6. If you are interested which services are automatically (out of the box) speaking IPv6, there will be a dedicated blogpost about that here. While there is no security implementations for IPv6 in this scenario (e.g a firewall capable of IPv6) nothing is preventing the ports and the services from being exposed to the public. If a hacker is now performing a Port scan to identify the available ports and services on both protocol he/she will see that there will be a wider range of available ports on IPv6 than on IPv4, simply because the security implementations of IPv6 haven’t been considered. From this point on the attacker could perform attacks on the (maybe outdated) services he was able to identify over IPv6, which weren’t there on IPv4.
With this scenario in mind I thought about how to prove or -disprove my assumption that there could be a massive discrepancies in available ports on IPv4 and IPv6 due to the reason that security implementations were left out on IPv6. So my task was to identify dual-stack systems, perform a port scan on the returned IPv4 and IPv6 address and combine the found ports on each protocol. If there is a congruent amount of ports found this likely means that security implementations have been considered. If there is a discrepancy in the amount of ports found this likely leads to the conclusion that mistakes during the dual-stack migration have been made.
For the research I have decided to scan the dual-stack servers of the Alexa Top 1 Million most visited websites worldwide. The Alexa list has been used as a reference for the current security state by many researches such as the most used Javascript versions or the ability to perform a AXFR transfer that could reveal internal / private considered DNS entries. As a consequence of my thoughts i wrote a script in Python which is capable of collecting the data i need to proof or disproof my hypothesis. The first event of the script is to determine the according IPv4 and IPv6 address of the provided domain list. For this the socket.getaddrinfo library of Python was used. Only if a tuple of IPv4 and IPv6 address has been found, the routine continues. The next step is to issue the Nmap scan for both addresses, which will reveal the found port and service running on it. For performance reasons, multiprocessing has been implemented. With multiprocessing, the script is now capable of scanning a theoretical infinite amount of addresses simultaneously. The final step is to insert the datasets in the database for further analysis. The Script along with the results can soon be found on Github.
