DNS-based reflection has played a major role in empowering Distributed Denial-of-Service (DDoS) attacks for a long time. Traditionally, the catalysts of these attacks are open DNS resolvers, and partially, authoritative nameservers. In an earlier post, my colleagues and I from the University of Twente, discussed that not all open resolvers are equally powerful if we consider the maximum amplification factor that each can provide. In collaboration with Brigham Young University, we now look at this inequality from a different angle, aiming to prioritize efforts to patch resolvers with a high link capacity.
Findings in recent research literature on source address validation motivated us to study whether the list of reflectors could be extended with closed DNS resolvers. The short answer is yes. Our experiments proved that the preconfigured recursive DNS resolvers of third-party networks can also be misused in DNS reflection-based attacks if source address validation is not properly deployed.
In this post, we focus on the potential of clouds to contribute to DDoS attacks. The question is why are cloud networks more important?
Our intuition is that cloud networks are, by design, well-provisioned. In case they are exposed to misuse in attacks, the harm that they can reflect is not comparable to consumer-grade devices such as home gateways. If we look at how the botnet infrastructures of attackers have evolved over time, from resource-constrained Internet of Things (IoT) devices (as was the case with the Mirai botnet in 2016) towards servers in data centres (as was the case with the Mantis botnet in 2022), we argue that the same can happen with misused DNS reflectors of choice, sooner or later.
Cloud-based open resolvers
We’ll focus first on open resolvers that are hosted in cloud networks. These resolvers are not functionally any different than typical CPE-based reflectors. However, their link capacity is typically higher than CPE devices. Thus, when cloud-based reflectors participate in DDoS attacks, they can send traffic towards a victim at higher rates. Of course, cloud networks are not the only well-provisioned networks (for example, educational networks also provide a high link capacity), but they are arguably the most-known ones.
In order to explore cloud-based open resolvers, we fused our open DNS resolver scan results with IP metadata from IP2Location. By doing so, we found out that roughly 12% of all open resolvers are located in cloud/data centre networks (see Figure 1). In absolute numbers this is multiple orders of magnitude more than what is typically misused in DDoS attacks, meaning that DDoS attacks could get way more powerful in practice than what they look like currently.
Additionally, we studied economy-level contribution diversity to the open resolver’s swarm. We observed that despite the fact that economies such as China and Brazil account for a large portion of open resolvers, their open resolvers mostly reside in eyeball Internet Service Providers (ISPs). On the other hand, the majority of the open resolvers in Hong Kong are hosted in data centre networks. Therefore, we argue that efforts to patch open resolvers need per-economy-oriented policies.
Preconfigured resolvers of clouds
Cloud network operators, similar to the majority of other networks, provide preconfigured DNS resolvers for their customers. These resolvers are typically access-controlled to only serve the clients in the specific network. However, basic access control (only checking whether the source IP address is within the range of client IP range) supposes that the source IP address in the queries is legitimate. This is, however, not necessarily the case. An attacker can spoof a query with the source IP address belonging to the clients of a network and get the query to pass the firewall. This can, for example, result in a reflection towards the client whose IP address was misused in the spoofed query of network-external origin.
The reflection-based Denial-of-Service (DoS) attack scenario here is somewhat different than traditional DDoS attacks. The victim is not necessarily a single host whose IP address is misused in the spoofed queries but can be the recursive resolvers of the cloud or the authoritative nameserver of the domain name used in the queries. To formalize these scenarios, we have identified multiple attack models that you can find in our paper.
We studied the top 19 public cloud providers to see whether such a reflection is possible in practice. The good news is that the majority of the providers properly deploy source address validation at the edge of their networks, dropping our spoofed queries. The bad news is that we found networks (three out of 19) that do not do this and, as a matter of fact, our queries made it to their destination. As a side finding of our study, we also noticed that six out of 19 providers expose their back-end resolver pool (the resolvers responsible to contact authoritative nameservers) to their clients.
Is this a big problem though? The numbers sound as if the potential threat is limited. However, don’t forget that our study concerns only a limited selection of top providers and we already expected that these networks would adhere to best practices. Our intuition is that the smaller providers would be more vulnerable. Therefore, we suggest operators test and, if necessary, further harden their core cloud infrastructure.
As a final note, we conducted a coordinated disclosure process and gave the operators in question enough time to deploy countermeasures in their networks, which was received positively.
Ramin Yazdani is a PhD student at DACS research group (Design and Analysis of Communication Systems) at the University of Twente, the Netherlands. His main research interests are network measurements, DDoS, and DNS.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.