WPAD Flaws Leak HTTPS URLs

Sniffing HTTPS URLs with malicious PAC files gets easier with a new technique that exploits flaws in the Web Proxy AutoDiscovery protocol.

LAS VEGAS — Researchers have found flaws in the Web Proxy AutoDiscovery protocol tied to DHCP and DNS servers that allow hackers spy on HTTPS-protected URLs and launch a myriad of different malicious attacks against Linux, Windows or Mac computers.

According to the security firm SafeBreach, this vulnerability allows hackers to monitor the URLs of every request the browser makes. With that information, SafeBreach says it’s possible for a hacker to see the entire URL of every site visited even if the traffic is protected with HTTPS encryption.

Researchers on Wednesday at Black Hat USA are expected to demonstrate publicly for the first time how the attack works in a talk called Crippling HTTPS with Unholy PAC.

The technique, called a HTTPS URL leakage attack, can be used by a hacker to intercept private and one-time-use URLs that contain security tokens used for shared access to services such as Dropbox. An attacker could also obtain a password-reset URL for a specific account, and with it gain full access to the victim’s account and data.

The technique could also be used to launch a browser-based phishing attack by generating alert messages when visiting specific URLs and could be used to conduct a denial-of-a-service attack by redirecting traffic to a specific IP address, said Amit Klein, vice president of security research at SafeBreach.

The vulnerability is tied to how browsers use PAC (Proxy Auto-Configuration) to navigate HTTP and HTTPS requests. PAC files contain JavaScript that instruct what proxy a browser needs to use to get to a specific URL. If a malicious PAC is introduced to the browser, that allows an attacker to monitor the URL of every request the browser makes.

Klein, in an interview with Threatpost, said the most likely way hackers would carry out an attack would be on an insecure wireless network with decoy DHCP or DNS servers. Worse, there is no visual clue that a computer has been infected by a malicious PAC. A users URL bar would still show they are connected via HTTPS.

“If your computer is configured to use WPAD and the DHCP protocol, an attacker can respond quickly to a browser broadcast request for a PAC file and send you quickly a spoofed DHCP response containing a URL that points to an attacker’s server where a malicious PAC file can be downloaded on the target’s computer,” Klein explains.

The browser obtains the PAC file through the semi-standard protocol Web Proxy AutoDiscovery (WPAD). SafeBreach maintains the problem is the WPAD standard protocol does not securely handle the PAC file.

The fact that a low trust piece of JavaScript can be downloaded via PAC file and executed in such a high trust context of HTTPS traffic–without any certification, digital signature, or protection of any kind–this is the root cause of this problem, Klein believes.

“We would like WPAD redesigned and the specification of the PAC standard reworked so it exposes less information and reduces the attack surface,” Klein said.

This is not the first time a PAC file has been leveraged in an attack. In April, researchers at Fortinet documented the BlackMoon Trojan that attempted to phish the credentials of 100,000 South Koreans using a malicious PAC file. But where BlackMoon’s exploit relies on just the malicious PAC, SafeBreach’s discovery relies on the WPAD specification to exploit.

Some browser vendors such as Apple and Google have attempted to address this issue by truncating the URLs used by PAC so a third-party can’t see the entire URL – only the domain. Last month Google paid a $500 bounty to bug hunter Paul Stone for finding a flaw in its Chrome browser related to PAC script leakage.

Suggested articles