New issue
Advanced search Search tips

Issue 677700 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: Strange Chrome behaviour in Google Search (Malnet Code injection?)

Reported by br0d...@gmail.com, Dec 31 2016

Issue description


VULNERABILITY DETAILS

I may have stumbled upon what seems like a Google Chrome code injection flaw that is being exploited by a malnet site owner (cocaine.ninja.)

I first noticed it because WebMPS was triggering my machine as "infected" when I was just googling the IP of a user's site infection.

So then I ran a simultaneous PCAP while Googling the IP, and noticed that my Google Search was actually REACHING OUT on 443 and 80 to the remote site when I only searched it!

The query is as follows (this is a malicious IP, do not go to it, and if you are using Chrome, your IP may connect to it.)

https://www.google.com/search?safe=off&q=163.172.151.248&oq=163.172.151.248&gs_l=serp.12...0.0.0.30016.0.0.0.0.0.0.0.0..0.0....0...1c..64.serp..0.0.0.qwe2h_t-4pY
or just
https://www.google.com/search?safe=off&q=163.172.151.248

This is the PCAP output: http://i.imgur.com/HdQ8Kpt.png

To try and figure out what was going on, I did a view-src on the results of this same query in both Firefox and Chrome, and then pasted both into Notepad++ and did a file compare/diff. 

There was an entire code layer seen in Chrome that is not even there in Firefox. The most suspicious block is this:

				try {
					google.jsc.x(ctx);
				} catch (e) {}
			})();
		})();
		(function () {
			(function () {
				var ctx = ["botstuff", [["t-orNZyHXTT74", "iAZ8KviZeMD8", "r-iAZ8KviZeMD8", [["use_light_trigger", , , , , [, , , , 0]
								], ["use_safari_tracker", , , , , [, , , , 0]
								], ["safari_tracker_start_time", , , , , [, , , 0.0]
								], ["geolocation_api_timeout_ms", , , , , [, , , 30000.0]
								], ["js_config", , , , , [, "[,,,30000]\n"]
				

I even tested this with other random IP addresses in the search, and no connections showed up in Wireshark. I tested in incognito mode, still happened. I even disabled all Chrome plugins, unless one of them had a security fail, and it still happened. And I tested it on a completely different machine, to rule out some sort of Chrome-specific local infection. 

Thanks!

VERSION
Version 55.0.2883.87 m
Windows 7 Version 6.1.7601 Service Pack 1 Build 7601


 
Labels: Needs-Feedback
Can you share the full PCAP instead of just the screenshot?

The most likely explanation is that the search results page is doing a pre-connect to the target for performance reasons-- this wouldn't actually result in execution of any of the site's content, even if it were malicious. 

Comment 2 by br0d...@gmail.com, Jan 3 2017

I did trace this back to Chrome's prefetch settings. So not really a bug, but a bad feature to have enabled by default if the expectation is that people should want to use Chrome for security research, as pingbacks are a bad idea.
Components: Internals>Network UI>Browser>Search
I'd like to hear more comments on that. For me, it doesn't sound good if I'm googling for some server and that server receives connections from me...

br0dely@gmail.com, would you mind attaching a PCAP file with those connections?

Comment 4 by br0d...@gmail.com, Jan 9 2017

[ ] Use a prediction service to help complete searches and URLs typed in the address bar
[ ] Use a prediction service to load pages more quickly

These two settings.
prefetch.pcapng
3.2 KB Download
https://www.google.com/#q=74.125.65.91 is another case where the behavior is seen. 

As far as I understand things, everything here is working by design-- a user performing a search is very likely to want to connect to the first result in the Google results page, and as a consequence the browser works to ensure that connections to that site occur as quickly as possible. That could happen either because the browser itself has determined that a given link is likely to be the next target of navigation, or because the markup has declared via prefetch or prerender attributes that it expect a target to be useful to accelerate.
Status: WontFix (was: Unconfirmed)
Yeah, this seems like web content using a web platform feature that, by default, Chrome allows use of (but lets you turn off if you want).
Project Member

Comment 7 by sheriffbot@chromium.org, Apr 18 2017

Labels: -Restrict-View-SecurityTeam allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment