New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 693991: Security: Chrome Information Leakage - Prediction Service & Preload

Reported by, Feb 19 2017

Issue description

Chrome Information Leakage - Prediction Service & Preload

In some cases a default Chrome installation makes an
unintended LLMNR broadcast in the internal network. An
internal attacker can use this behavior to steal windows

Google Chrome helps to resolve navigation errors and offers
a service to load pages more quickly. Per default these two
options are active after an installation. If an user types
a word in the chrome address bar, sometimes Chrome askes to
resolve this word as a hostname, e.g.: http://SEARCHWORD/.
Without user interaction Chrome tries to resolve this
hostname. If the DNS server has no match, an LLMNR broadcast
will be sent out over the internal network. Most of these
mistyped words are not a valid hostname. An attacker in the
internal network can use this misbehavoir from Chrome to
steal valid windows credentials (username and hash). An
famous tool to make a poisoned answer to the victim is
the software Responder.

Chrome Version:  56.0.2924.87 (64-bit) + stable
Operating System: Windows 7 Enterprise 7601 Service Pack 1

Attacker Machine: 
	Command to start Responder: python -I eth0 -wrf
	Operating System: Kali 2016.2

Victim Machine:
	Chrome Version:  56.0.2924.87 (64-bit) + stable
	Operating System: Windows 7 Enterprise 7601 Service Pack 1
143 KB View Download
135 KB View Download
110 KB View Download

Comment 1 by, Feb 19 2017

Components: Internals>Network Internals>Preload
Labels: Security_Severity-Low Security_Impact-Stable Pri-2
Status: Assigned (was: Unconfirmed)
Thanks for the report.

rsleevi: could you please help triage this? 

Assigning low severity for now because this doesn't seem more dangerous than a user navigating to a hostname directly, which could happen in any number of ways. But I don't know enough of the nuances :)

Comment 2 by, Feb 19 2017

Labels: OS-Windows

Comment 3 by, Feb 19 2017

Similar to Issue 479620 with the well-known NTLM shortcoming on top.

Comment 4 by, Feb 21 2017

Owner: ----
I'm in meetings all day today/tomorrow, so roping in asanka@ and pkasting@. My recollection of the code is it does not allow the vector described because we don't allow transparent auth for the DNS hijacking detection, but asanka@ and pkasting@ would know precisely.

Comment 5 by, Feb 21 2017

 Issue 606216  cleaned up the sending of credentials in the IntranetRedirectDetector code used for DNS hijacking detection.

I think in this report, the attacker isn't targeting those IntranetRedirectDetector requests; he instead just generates a phony DNS response for a single word query (e.g. he pretends there's an intranet server named "BASEBALL" and if your browser tries to connect to that, the authentication dance happens).

Comment 6 by, Feb 21 2017

If Windows considers the target server as being part of the intranet, when Chrome will respond to authentication using ambient credentials. This unfortunately makes this a realistic attack.

A mitigation would be to use DO_NOT_SEND_AUTH_DATA load flag when making this kind of speculative requests. If the user actively visits a rogue server that the local machine is configured to treat as part of the intranet, then it won't help.

Comment 7 by, Feb 21 2017

The concern here would be if setting DO_NOT_SEND_AUTH_DATA causes target servers to respond differently.  For example, if a server without auth data replies with 401 and with auth data 200.  In this case, setting this bit will cause us to not detect such servers as valid intranet navigations, which is intensely frustrating to users.

If this isn't possible (even with badly configured servers), or if the possible set of replies is such that we can say "401 means the server exists and we should prompt to navigate" or similar, then we could set this bit.

Comment 8 by, Mar 31 2017

Is anything done on this issue? When will there be a fix?

Comment 9 by, May 9 2017

Issue 719473 has been merged into this issue.

Comment 10 by, May 22 2017

Looking at, looks like it's already considering 401 as meaning the host exists. I'll upload a CL to prevent these requests from performing an auth handshake.

Comment 11 by, Jun 16 2017


Comment 12 by, Feb 1 2018

Comment 13 by, Feb 1 2018

Labels: -Restrict-View-SecurityTeam allpublic
Removing view restrictions as this issue is public.

Comment 14 Deleted

Comment 15 by, Jun 7 2018 has a workaround for disabling NetBIOS over TCP/IP on Windows, which should prevent NBNS leaks.

It also says "Because NetBIOS over TCP/IP is so insecure, (in case of those NetBIOS broadcast requests) literally anyone on your local network can reply to the NetBIOS message and claim to resolve the queried name. They can return an IP address they control and where they run for example a web-server with an exploit pack on it, or display a website which tries social engineering (“please enter your credentials here..” or “please download this update or install this plugin”)."

Sign in to add a comment