Issue metadata
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 descriptionVULNERABILITY 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
,
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.
,
Jan 9 2017
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?
,
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.
,
Jan 9 2017
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.
,
Jan 9 2017
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).
,
Apr 18 2017
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 |
|||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Jan 1 2017