Finding the source of a dns rebind attack via dns.msftncsi.com?

Help Community Help
27

I didn't explain my hybrid setup overly clearly :slight_smile:

pihole runs on .135 and my main resolver (which talks to piHole) runs on .136 - and listens to 53, DoT and DoH - it also listens on 9001 and passes anything there over a DNSCrypt proxy to OpenDNS. PiHole is set to only use that for resolving (as said, front end listener -> piHole -> OpenDNS)
It's set that way so that piHole uses it, and if piHole fails (or I stop/restart it for any reason) my front end just gracefully fails and uses OpenDNS instead.

The grep only returns:

root@piholedns:/# grep -n dns.msftncsi.com /var/log/pihole.log*

/var/log/pihole.log:52:Feb 11 05:42:39 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com
/var/log/pihole.log:53:Feb 11 05:42:39 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com
/var/log/pihole.log.1:219:Feb 10 22:28:19 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com

The two new lines from today have also shown in the GUI.

The only other lines around the 22:28 are DHCP Requests, ACKS and OFFERs for other devices on LAN.

The curious thing is that (as typing) I've just done nslookup/ping from the original machine and this desktop, and both get the same IP BUT I now have new rebind errors in the log, and only on that host.

/var/log/pihole.log:52:Feb 11 05:42:39 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com
/var/log/pihole.log:53:Feb 11 05:42:39 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com
/var/log/pihole.log:80:Feb 11 08:16:50 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com
/var/log/pihole.log:81:Feb 11 08:16:54 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com
/var/log/pihole.log:82:Feb 11 08:17:13 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com
/var/log/pihole.log.1:219:Feb 10 22:28:19 dnsmasq[416]: possible DNS-rebind attack detected: dns.msftncsi.com

I've then checking my dns front end log and the VPN machine is querying with suffixes appended - this is the query on the VPN machine (corporate domain redacted):

# DIAB : LOG     : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.dev.[CORP DOMAIN].net.) - Allowing.,
2022-02-11T08:16:50.629526116Z # DIAB : LOG     : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.[CORP DOMAIN].dmzdev.) - Allowing.,
2022-02-11T08:16:50.656480971Z # DIAB : LOG     : INTERNAL query from (10.74.50.14) for (dns.msftncsi.com.[CORP DOMAIN].dmzdev.) - Allowing.

nslookup for those doesn't respond (on or off it's VPN) as expected.

2022-02-11T08:17:13.427079035Z # DIAB : LOG     : INTERNAL query from (10.74.10.1) for (dns.msftncsi.com.) - Allowing.,
2022-02-11T08:17:13.431008981Z # DIAB : LOG     : INTERNAL query from (10.74.10.1) for (dns.msftncsi.com.) - Allowing.

...but it also got a rebind from this machine (above). I'll see if I can mod my resolver to show the returned IP - it's possible OpenDNS might be doing something but I'd find that somewhat odd...

28

That's strange, since I see the lines preceeding the warning when I try to recreate your observation within my setup.
I'd expected yours to show similar lines as:

Feb 10 22:28:18 dnsmasq[]: query[A] dns.msftncsi.com from sss.sss.sss.sss
Feb 10 22:28:18 dnsmasq[]: forwarded dns.msftncsi.com to uuu.uuu.uuu.uuu#pp
Feb 10 22:28:19 dnsmasq[]: possible DNS-rebind attack detected: dns.msftncsi.com

And those lines would also have provided the answer to your original question for the source of the possible rebind as Pi-hole's upstream (uuu.uuu.uuu.uuu#pp).

Did you perhaps disable Pi-hole's file-based query logging?

OpenDNS may ultimately receive your network's non-filtered DNS traffic, but your Pi-hole has no relationship with OpenDNS. It is configured to talk a local resolver at 10.74.90.136#9001 exclusively.

You may well be hunting a ghost here.
A local DNS resolver that is talking to another local DNS resolver exclusively could quite probably be expected to return private IPs (though not for an allowed public domain).
Your resolver at the edge of your network is the one that can be expected to never return any private IPs and thus the one that should guard against dns rebinds.

What is indeed strange about your observation is that not all queries seem to be affected equally.
As your 10.74.90.136#9001 sees all requests as orginating from your Pi-hole, I wonder what would trigger your .136 to answer a DNS request for dns.msftncsi.com correctly for some and somehow block it for other DNS queries.

Of course, the "somehow block" part is just my guess.
Being able to see the actual IP returned by your 10.74.90.136#9001 may help to confirm that, as firewalls or DNS blockers may inject 127.0.0.1 or their own IP for blocked requests.

29

It was disabled, I've enabled it now.

The local resolver only talks to OpenDNS - unless something else has managed to sneak out :slight_smile:

With dnstap on dnsdist, I can see:

EDE: 15 (Blocked): ()

My network doesn't have IPv6 enabled, but it seems that dns.msftncsi.com returns a non-routable IPv6 address (fd3e:4f5a:5b81::1) which is likely what is causing the fun...

So, I'll allow that via :

rebind-domain-ok=/domain/

Bit of a learning curve there (as I don't see ipv6 responses typically) but hopefully this helps someone else :slight_smile: Thanks for assisting :slight_smile:

30

Judging by the structure, that is likely a router's (yours?) IPv6 ULA address.

While setting rebind-domain-ok will address the immediate issue, you should probably consider to further investigate the actual cause.
A public DNS server typically won't return a private ULA address.

If your router has the ability to inject DNS replies into an encrypted upstream connection, then something is definitely off here.

Another possible less alarming explanation would be some kind of DPI firewall on your .136 that inspects and alters DNS packets on leaving that machine.

If that would be the case, I'd personally prefer to adopt the firewall rules instead of rebind exemptions.

Your finding also doesn't fully explain why only certain clients or requests would trigger the dns rebind warning, unless the triggering ones would exactly match those that request an AAAA record, and those that don't would match A record only requests.

32

It's designated internal:

That is what is configured as the response address :

https://www.ip-lookup.org/dns-lookup/dns.msftncsi.com

It was reported "broken" in 2013 (!) but is "by design" just to test resolution:

I don't have (or route) IPv6 but nothing stops an IPv4 lookup requesting and getting an IPv6 response. The primary machine doing the queries on my LAN is a corporate machine (typically on a VPN) and has IPv6 enabled. I think the other queries (when I see them) are hitting the (then) cached result.

33

That's an interesting find, thank you. :slight_smile:
My upstream unbound does return an empty AAAA record for dns.msftncsi.com , so this completely escaped me. Virtually every other DNS server I tried (including all of Pi-hole's tickable upstreams) returned that ULA address - which seems outright wrong to me.

Now, if you exempt that domain via rebind-domain-ok, you would half-way open the door for a successful DNS rebind attack via dns.msftncsi.com.

Instead of allowing that, blocking those misconfigured AAAA records for dns.msftncsi.com would seem the better choice.
Add the following regex to your blocked domains

dns.msftncsi.com;querytype=aaaa

Note that doing so may or may not confuse Windows connectivity checks for IPv6, although connection attempts to the original fd3e:4f5a:5b81::1 would fail anyway (unless your router by chance happens to use that very ULA prefix and interface identifier for itself).
Your network does not have IPv6 connectivity anyway, so that may be irrelevant in your specific case.

So all in all, to find the cause for a possible DNS-rebind attack detected: name.domain warning, you should run the following command sequentially against all your configured upstreams (including any Conditional Forwarding target IPs):

nslookup name.domain dns.ser.ver.ip

in your case e.g.

nslookup -p=9001 dns.msftncsi.com 10.74.90.136

(where -p=9001 is additionally necessary for your custom port).

If you spot any private range IP addresses in the results, you've found the trigger for the rebind warning.

You then have a choice of switching to a DNS server that does not supply a private IP address result, blocking that specific domain or record, or defining an exemption via rebind-domain-ok=name.domain.
I'd recommend the latter strictly to be used for local hostnames only, and resort to one of the former two for public domains.

(EDIT: I took the freedom to change your topic's title to include dns.msftncsi.com, so other users stumbling over that same warning may find your post more easily.)

34

I'll do the regex - and thanks for bearing with :slight_smile:

35

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.