We at PowerDNS have been getting questions about ‘DNS server cache snooping remote information disclosure’ attacks lately, mostly coming from reports generated by one very popular security scanner:
DNS Server Cache Snooping Remote Information Disclosure
Synopsis:
The remote DNS server is vulnerable to cache snooping attacks.
Description:
The remote DNS server responds to queries for third-party domains that do not have the recursion bit set.
This may allow a remote attacker to determine which domains have recently been resolved via this name server, and therefore which hosts have been recently visited.
For instance, if an attacker was interested in whether your company utilizes the online services of a particular financial institution, they would be able to use this attack to build a statistical model regarding company usage of that financial institution.
Of course, the attack can also be used to find B2B partners, web-surfing patterns, external mail servers, and more.
Note: If this is an internal DNS server not accessible to outside networks, attacks would be limited to the internal network.
This may include employees, consultants and potentially users on a guest network or WiFi connection if supported.
Risk factor:
Medium
CVSS Base Score:
5.0
CVSS2#AV:
N/AC:L/Au:N/C:P/I:N/A:N
See also:
http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf
Solution:
Contact the vendor of the DNS software for a fix.What is this about?
The idea behind this ‘attack’ is to find out whether a given recursive DNS server has been recently asked to resolve a given domain name. In theory, this might be used by an authorized user to know which domains would be worth targeting for mistyping attacks.
However, it cannot be used to get the whole content of the cache, since one needs to know which domains to query. Of course, it can’t be used to know who requested that domain either.
How does it work?
The attacks work by exploiting the fact that DNS resolvers do not perform actual resolution for every query they get, instead they all rely on one or several caches, allowing them to remember the responses they have recently received for a certain time, up to the Time to Live (TTL) value of the response. So, if we can determine that a given domain is in the cache, we know that it was queried, at most, TTL seconds ago.
The easiest way to determine if a recursive server has a given domain in cache is to ask. Sending a DNS query with the recursion desired bit cleared (RD=0) will only return results from the resolver cache, as per RFC 1034. If information is available about the requested name and type, it is returned, otherwise an empty ‘No Error’ answer is sent.
If the server refuses to answer these queries, it is still possible to know whether an answer comes from the cache by looking at the TTL returned for a RD=1 request and comparing it to the original TTL returned by a name server authoritative for that domain. If the TTL returned by the recursor is equal to the one returned by the authoritative server, it was likely not in cache, or was cached less than a second ago. Otherwise, it comes from the recursor cache.
We could also precisely measure the time taken by the server to respond. In the absence of a cached answer, the recursive server would have to contact an authoritative server over the network, likely increasing the response time by several milliseconds.
Why does the RD feature exist in the first place?
The recursion desired feature is an integral part of the DNS protocol, as described in RFC 1034, for communication between a recursive server and an authoritative server, where recursion is not desired. As some servers historically provided both authoritative and recursive services, it still makes sense today to be able to distinguish the client’s expectations and to advertise the server capabilities.
It should also be noted that it is extremely useful to be able to use RD=0 queries to remotely inspect the content of the cache for a given name when troubleshooting operational issues in production. The alternative would require connecting to the running recursor process using rec_control and dumping the whole cache.
Mitigations
The first method might be mitigated by refusing RD=0 queries, for example, using dnsdist:
addAction(NotRule(RDRule()), RCodeAction(DNSRCode.REFUSED))It might however break existing clients and setups since the RD=0 behaviour has been relied on for decades. Moreover, there is no way to mitigate the second and third ones without violating fundamental DNS specifications and impacting performance.
Therefore, our recommendation is to simply ignore this ‘issue’, since there is no clear threat-model where it is actually relevant. This is also the conclusion that the fine folk of ISC reached regarding their BIND DNS server.
This post was orginally published on PowerDNS Blog.
Remi Gacogne is Senior Engineer at PowerDNS, working on dnsdist, PowerDNS Authoritative and PowerDNS Recursor. He is also a member of the Arch Linux team, focusing on security.
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.