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.