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 5 users

Issue metadata

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



Sign in to add a comment

Security: Chrome Information Leakage - Prediction Service & Preload

Reported by martinst...@gmx.de, Feb 19 2017

Issue description

VULNERABILITY DETAILS
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
credentials.

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.

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

SETTINGS
Attacker Machine: 
	IP-Address: 192.168.56.103
	Software: https://github.com/SpiderLabs/Responder
	Command to start Responder: python Responder.py -I eth0 -wrf
	Operating System: Kali 2016.2

Victim Machine:
	IP-Address: 192.168.56.1
	Chrome Version:  56.0.2924.87 (64-bit) + stable
	Operating System: Windows 7 Enterprise 7601 Service Pack 1
 
Responder1.png
143 KB View Download
Chrome1.png
135 KB View Download
Settings.PNG
110 KB View Download

Comment 1 by raymes@chromium.org, Feb 19 2017

Cc: elawrence@chromium.org est...@chromium.org
Components: Internals>Network Internals>Preload
Labels: Security_Severity-Low Security_Impact-Stable Pri-2
Owner: rsleevi@chromium.org
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 raymes@chromium.org, Feb 19 2017

Labels: OS-Windows
Similar to Issue 479620 with the well-known NTLM shortcoming on top.
Cc: asanka@chromium.org pkasting@chromium.org rsleevi@chromium.org
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.
 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 asanka@chromium.org, 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.


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 martinst...@gmx.de, Mar 31 2017

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

Comment 9 by aarya@google.com, May 9 2017

Cc: cbentzel@chromium.org jsc...@chromium.org
Issue 719473 has been merged into this issue.
Owner: asanka@chromium.org
Looking at chrome_omnibox_navigation_observer.cc, 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.

Cc: zentaro@chromium.org
https://twitter.com/zerosum0x0/status/958890437837692928
Now i think this bug is public...
Labels: -Restrict-View-SecurityTeam allpublic
Removing view restrictions as this issue is public.

Comment 14 Deleted

http://blog.kleissner.org/?p=842 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