Hacker News Reader

Comment by Randor | Hacker News Reader

As the blog correctly identifies, the WPAD specification is still in draft:

https://datatracker.ietf.org/doc/html/draft-ietf-wrec-wpad-0...

In other words there really isn't a standard to follow. You can't add features to operating systems if there isn't a formal specification.

I'm not sure who's to blame here.

View on HN

"Expires: December 1999". It was in draft in the last millennium but it died.

It's also a terrible idea. For example now anyone running a evil DHCP server in a WLAN you joincan get your browser to follow a malicious PAC script which lets them MITM even HTTPS traffic... see eg https://www.pcworld.com/article/415991/disable-wpad-now-or-h...

(This was of course back when Windows users were getting regularly pwned by a windows worm of the week so wasn't anything out of the ordinary)

How do you MITM HTTPS without control over the cert store on the client, or access to private keys that let you generate certs that are trusted? You don't, and the threat of this is nation-state-level stuff.

The article you link to posits a malicious PAC file which leaks the contents of request URIs. This is NOT the same as MITMing all HTTPS.

This is also an illustration why, on devices such as this, it's good to layer security with things such as always-on VPN.

EDIT: The root of that article is decent, but it has so many problems... And it starts tacking on the caveats about how it's wrong near the bottom. Like:

"The two researchers showed that some widely used VPN clients, like OpenVPN, do not clear the Internet proxy settings set via WPAD. This means that if attackers have already managed to poison a computer’s proxy settings through a malicious PAC before that computer connects to a VPN, its traffic will still be routed through the malicious proxy after going through the VPN."

This only works if the VPN client doesn't rewrite the routing table to send everything through the tunnel. And if they keep the OS' network state detection from noticing a state change, which in turn triggers a proxy setting refresh. (WinHttpWebProxyAutoSvc specifically does this.)

I suppose you're right that the HTTPS content MITM vulnerabilities wrt PAC have been fixed. But still the URI leaks are bad enough since they leak a lot of info about you.

Re VPNs .. quoting from the pcworld article:

> The two researchers showed that some widely used VPN clients, like OpenVPN, do not clear the Internet proxy settings set via WPAD. This means that if attackers have already managed to poison a computer’s proxy settings through a malicious PAC before that computer connects to a VPN, its traffic will still be routed through the malicious proxy after going through the VPN.

I maintain that that WPAD is terrible from a security POV, an OS has no business executing untrusted configuration javascript in my web browser. You can just exploit browser bugs there without user navigating anyhere untrusted, like shown here: https://googleprojectzero.blogspot.com/2017/12/apacolypse-no...

At least on Windows 10 for the last few years, the JS is not executed in your browser. There is specifically an isolated, limited environment called pacjsworker.exe that executes PAC files and does not support nearly the same amount of JS needed by a brower. Check this out for a list of the functions in a PAC file: http://findproxyforurl.com/pac-functions/

WinHTTP then uses this to determine if the traffic should be routed through a proxy or not.

It is not, or at least is not now, jscript.dll as the article mentions.

> I'm not sure who's to blame here.

I would venture to say perhaps AzureAD?

When a OS receives an instruction from the router/DHCP server that no proxy should be used on this network, and the OS adheres to that…

And that alone just breaks AzureAD, that’s clearly a point where AzureAD needs to be made more resilient.

Hey there, OP here. Azure AD is a cloud service.

The bug was in WinHttpAutoProxySvc, but at some point ASUS (et al) must have noticed it and chose to send the blank Option 252 to take advantage of the result, without realizing that the result is poor behavior and reporting it to Microsoft.

EDIT: More specifically, it was that a service running on the client was told, in a weird way, that there was no proxy to use. This weird way triggered a bug, so it kept using that setting even after it no longer received that signal (different DHCP on a different network) and a there-is-now-a-proxy setting was available (via DNS).

EDIT 2: To be more clear, Azure AD needs access to the internet, uses WinHTTP (because this is Windows' standard HTTP libraries), and when a bug in one part of this stack was exposed, AAD didn't work. There were no problems with AAD here, even though that's where the user saw the error.

> You can't add features

And you can't add features to browsers if there isn't a formal specification, right? Right?

Reply on news.ycombinator.com