Last week a new DNS vulnerability was introduced by researchers that had affected the majority of DNS resolver software as well as most major open resolvers on the internet. As of this week, most providers have taken steps to mitigate the vulnerability. As a network security solution, any threat is a top concern to us. Cache poison attacks are not new, and have existed for years. In this post we will discuss and share what we do at ScoutDNS to protect users.
What is a DNS Cache Poison Attack?
In short and overly simplified, cache poison attacks involve an attacker hijacking a DNS message between a recursive resolver and an authoritative one, and then inserting their own message response into the DNS cache, serving this message up to any downstream users of the impacted resolver. In doing so, an attacker could take a popular domain and turn it into a malware distribution point for all users on the downstream network.
What about DNSSEC?
DNSSEC is an authentication extension that uses signed keys so that authoritative servers can prove their responses are valid. While DNSSEC would certainly prevent unauthorized responses, the reality is that too few DNS servers are using it today to really make an impact.
SAD DNS
Around 2008, Dan Kaminsky discovered a DNS vulnerability that exploited how recursive and authoritative resolvers communicate with each other. This vulnerability, and subsequent follow-ons that came a few years later had been largely mitigated by major resolvers primarily by introduction of port randomization between the recursive and authoritative resolvers. Last week researchers announced a new attack called Side Channel Attacked DNS (SAD DNS). This is basically an attack that takes advantage of ICMP rate limits (controversial in itself) in order to narrow down and guess the open port being used to talk to the authoritative DNS server. It’s actually a clever technique but that being said, it’s not that simple to pull off in practice for a number of reasons we won’t go into here.
How ScoutDNS Responds
Prior to the SAD DNS attack announcement, we already had in place all recommended mitigation steps as standard operating practice.
- Using port and ID randomization between us and authoritative resolvers
- Use of connected sockets
- Native Spoof detection
- Disabling ICMP “Port Unreachable” messages
If you are using your own DNS resolver and can’t take all of these steps for whatever reason, you should at least update your Linux kernel in order to use unpredictable ICMP rate limits.
What’s next?
Who knows, but it’s only a matter of time before new attacks target the inherently problematic relationship between recursive and authoritative DNS servers. Security through obscurity is only so effective and the industry as a whole needs to step up adoption of DNSSEC and continue exploration of encryption standards between recursives and authoritives such as but not limited to ADoT.
