0

Hi I have read recently very bad things about WPAD vulnerability for example here nakedsecurity.sophos.com/2016/05/25/when-domain-names-attack-the-wpad-name-collision-vulnerability/ (article from 2016) or here blog.redteam.pl/2019/05/badwpad-dns-suffix-wpad-wpadblocking-com.html. (article from 2019) How to defend against it? If I only use wifi only from my home network, am I also at risk? Should I disable it?

Thanks in advance

2 Answers2

0

Short Answer: NO, as a home user, unless you misconfigured your DHCP network (or your ISP is doing bad things).

Long answer: You are not supposed to run your HOME/Enterprise network under an valid internet subdomain name. Depending on your ISP, your computer should have received from DHCP server parameters giving it a FQDN like mylovelyPC.ISPName.loc. or something like that.

If you are running an Enterprise network, you are either using split brain DNS (eg your contoso.com enterprise network is not using the same DNS server and zones from the inner side and the outer side), or two different domains (contoso.loc for LAN and contoso.com) for internet facing servers. All theses attacks relies on the fact that the PC is using a FQDN which is a subdomain of an REAL internet domain and that the LOCAL DNS is unable to respond to WPAD host query.

Example: You named your network contoso.org.uk, PCs will search for wpad.contoso.org.uk (should reply,) wpad.org.uk (you do not control that one,) wpad.uk (you do not control that one either.) So, if your IT mis-configured your enterprise DNS configuration, you may be at risk, IF someone manage to register wpad.uk or wpad.org.uk.

Looks like they are a lot of people in Poland (.pl) who run mis-configured DNS infrastructure. 8)

By the way, on Windows DNS Servers, the option to block has been there for 10 years, is enabled by default and is called globalQueryBlockList.

Example: dnscmd /info /enableglobalqueryblocklist

Xander
  • 35,616
  • 27
  • 114
  • 141
  • I'm safe then. Thanks you for help and time mate :) Have a good day. – Mathiew2194 Aug 09 '19 at 06:36
  • I'm a little paranoid. You said " unless you misconfigured your DHCP network" could you tell me, is it possible that I configured the dhcp incorrectly? How can I check it to be sure? – Mathiew2194 Aug 09 '19 at 07:50
  • I'm worried because I found someone post: "The default DHCP domain setting of my D-Link DIR-615 wireless router is: “domain.example” and I didn’t change it. The Proxy Automatic detection is enabled in my Windows 10/IE settings. I was not aware of the WPAD vulnerability until recently I found my proxy setting is somehow automatically set to “xxx.yy.z.qqq:8080″…Then I checked further and found someone registered wpad.domain.example and utilized it to auto set my proxy to a malicious proxy server (xxx.yy.z.qqq) in Spain" I have TP-Link router. Maybe my default DHCP domain setting is bad? – Mathiew2194 Aug 09 '19 at 11:46
  • .example is a special tld, and almost nobody is allowed to register under it. A query for wpad.example or wpad.domain.example has no result as of today. – E. Le Bihan Aug 12 '19 at 08:05
  • Thank you a lot mate, you are good and helpful :) – Mathiew2194 Aug 12 '19 at 11:13
0

You are at risk if someone in your network

(1) is running a poisoning server like "Responder"

(2) and you have your browser set to "autoconfigure", which is the default in most browsers.

For home networks, I would not worry too much about it.

For enterprise / company network situations, there is a bit more explanation needed.

First, the recommendation is to disable "Auto Configuration" in your browsers and specify internet settings manually. This may or may not be feasible in your environment. Personally I would remove LLMNR and Netbios from the clients first, because this is a prerequisite for the attack to work.

Secondly, there is a recommendation to create a fake "WPAD" entry in DNS (e.g. 127.0.0.1) to avoid LLMNR lookups. This recommendation makes sense, but in the real world the implementation is a little weird, because by default Windows DNS blocks "WPAD" queries because of it's builtin blocklist. This is counterproductive, because now the client doesn't get a valid response and uses LLMNR queries (broadcasts) instead to find the local WPAD server.

Now, if a malicious actor is running something like "Responder" in your local network, credentials are immediately lost and the blocklist on the DNS server is actually contributing to the problem.

I may misunderstand something, to me it seems the blocklist was introduced before LLMNR became a thing and this was overlooked by Microsoft. Based on my current real world tests, it would be much better to actually allow WPAD queries on your DNS server, by pointing them to a non-existent IP, like 127.0.0.1.

Here is the outpout from Responder, when WPAD is blocked on the DNS server and the client has to fallback to LLMNR:

[*] [LLMNR]  Poisoned answer sent to 10.10.66.55 for name wpad
[*] [MDNS] Poisoned answer sent to 10.10.66.55     for name wpad.local
[*] [MDNS] Poisoned answer sent to 10.10.66.55     for name wpad.local

by adding a "WPAD" entry and disabling the blocklist, this issue is mitigated entirely.

Robert R
  • 63
  • 6