Researchers from Brigham Young University, led by Casey Deccio, surveyed a large set of known DNS servers worldwide, using various spoofed-source addresses, and found that roughly half of all Autonomous Systems (ASes) fail to filter for spoofed traffic as it enters their network border.
While this might not be a ‘stop-everything-right-away-and-patch’ type vulnerability, this oversight does allow remote attackers to infiltrate the network and impersonate internal resources. This, in turn, facilitates attacks that could otherwise be prevented, such as DNS cache poisoning or the NXNS attack, a powerful new denial of service technique.
Fortunately, the solution to this — unlike some spoofing prevention techniques — directly protects the network employing it.
Long story short
The solution to IP address spoofing is broadly referred to as source address validation (SAV). There are two separate dimensions to this: origin-side source address validation (OSAV) and destination-side source address validation (DSAV).
OSAV refers to blocking spoofed packets from the source, preventing them from even leaving their network of origin (see BCP 38). The focus here is DSAV, which refers to preventing spoofed traffic from entering the destination network.
How you deploy DSAV depends on your network architecture. BCP 84 has a good introduction and some starting places for different architectures. The important thing is a configuration that disallows packets, whose source address originates from your network, from entering your network.
If your network was found to be vulnerable during the initial experiment, the team took every effort to notify you directly. However, due to the difficulty of properly notifying more than 25,000 ASes, it’s possible that your network is affected even if you weren’t notified.
To help with this, we, the above mentioned researchers, have developed a self-test tool. The tool works by initiating benign spoofed traffic into your network, allowing you to check your logs and get immediate feedback as to whether there is a problem with your network, as far as we can observe.
The full story
We tested for this vulnerability in December 2019. Our methodology relied on sending DNS queries with spoofed source addresses to known DNS resolvers. The queries were for domains under our control; as such, if we observed a corresponding query at our authoritative server, we were able to determine that our spoofed queries successfully infiltrated the network. This is illustrated in Figure 1.
The line shown in red is the critical piece that ultimately allows us to infer the lack of DSAV. If we receive this query at our authoritative server, we can be confident that DSAV is not present, otherwise our spoofed traffic would not have reached the target DNS resolver. It should be emphasized that although DNS was used as the vehicle for testing, this is not a DNS-specific vulnerability as DSAV is configured on border routers, not DNS servers.
In total, spoofed queries were sent to a set of approximately 12 million IP addresses that we observed contacting the root servers earlier that year during the DITL data collection. Each address received several queries, each exploring the potential for a different spoofed source that should be blocked at the network border. These included:
- Sources from within the destination network itself. This is loosely analogous to a postal service delivering a letter to an address, with the letter claiming to be from that address. We tested three different variations of this: the target address itself as the source, a randomly selected address from the same /24 (or /64 for IPv6) as the target address, and a randomly selected address from outside the /24 (or /64) but within the same ASN.
- Sources from reserved, private address space.
- Sources reserved for the loopback interface.
The pervasive lack of DSAV exceeded our expectations. 26,000 (49%) of the IPv4 ASes and 4,000 (50%) of the IPv6 ASes were vulnerable to infiltration via spoofed-source packets. Each category of spoofed source independently contributed to the overall effectiveness of our experiment. Every category resulted in reaching a target that would not otherwise have been reached (even considering all other categories combined). Thus, if we had excluded any category of spoofed addresses from our experiment, our total number of reachable targets would have been lower — both by IP address and ASN.
Though this is beyond the scope of this post, in our full publication, to demonstrate the dangers associated with the lack of DSAV, we show how remote attackers could fingerprint internal systems and discover vulnerabilities with otherwise unreachable systems. For example, we find a significant number of recursive resolvers vulnerable to cache poisoning attacks due to the lack of source port randomization, a best practice that has been known for over 12 years now. While cache poisoning is a DNS specific vulnerability, the ASes of the resolvers can instantly provide blanket security for at least half of these vulnerable resolvers simply by deploying DSAV, as half were correctly configured as closed resolvers.
Test it yourself
As mentioned earlier, we have developed a self-test tool that allows administrators to test their own network in real time. This allows those interested to see if they are vulnerable and at the same time serves as a way to immediately validate any adjustments made to network configurations.
The self-test tool is now available and can be accessed here.
Casey Deccio and Michael Howe contributed to this article.
Alden Hilton is a computer science master’s student at Brigham Young University. His research centres on network security, with a focus on the 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.