Possibility of a remote cache snooping attack?

[Mathew]

I ran a nessus scan on my R-Pi running PiHole and received this warning:

DNS Server Cache Snooping Remote Information Disclosure

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.

Solution

Contact the vendor of the DNS software for a fix.

Is there a way to fix this issue? By attempting to block ads and porn at home, am I letting attackers in?

[RamSet]

Did you run it from outside of your network or locally ?

That is a legitimate functionality of Pi-hole (ot ANY DNS resolver that you host).

As long as you don't expose port 53 to the outside, you are all good.

It says right there.

@Mathew

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.

[DL6ER]

@Mathew

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.

This attack is theoretical, at most. It is based on reply time measurements, however, when done from a remote connection and with sufficiently fast connectivity to your configured upstream servers, the evidence may even be hidden in the randomness of the reply time noise.

Also note that this cannot be exploited invisible, instead, only by brute-forcing all possible domains to (hopefully) measure said delay anomaly. This will cause the attacker to stick out very prominently on the dashboard as a client requesting hundreds, if not thousands of queries in a very short time interval. Furthermore, they have only one try as a second try will always immediately hit the cache.

Last but not least, the practical feasibility of this attack is strongly degraded by possibly low TTLs (1 minute and less), often used by said services to ensure they can give you suitable IPs of servers with low load. This further limits the possibility to disclose any information through cache snooping as the test will immediately return that you have never visited the page as soon as the TTL expired.

This all makes this "vulnerability" appear somewhat unimportant and, as @RamSet said before, as your Pi-hole is anyways not reachable from the public Internet, there is no risk at all.