Google Chrome Version Detection

Does anyone have any insite as to how the Rapid7 agent or scanner detects the version of Google Chrome that is installed on a system? We have systems that when I open Chrome it is showing as having version 91.0.4472.77 installed but Rapid7 is reporting the system as having 68.94.77 installed. I’ve checked the entire machine and I’m not finding any other versions of the Chrome executable. I was able to find some old registry entries that showed the older version but I would think Rapid7 would have their plugins actually look for the Chrome version by checking the version of the executable installed as opposed to scanning the registry.

Any ideas on where Rapid7 is looking to get the version information for Chrome? This detection is causing us to show thousands of vulnerabilities that don’t actually exist in our environment.

Thank you.

Hi @gabe_verrault
We have detected the same problem. after the last scan 3 days ago, the number of vulnerabilities found has exploded. On many Windows 10 clients (LTSB and SAC) Google Chrome version 68.73.16498 was detected and accordingly 700+ vulnerabilities were reported per client. Interestingly, on both SCCM and Nexthink this result was confirmed. Meaning that version 68.73.16498 is installed on the clients. MDATP however says that version: 89.0.4389.114 or newer is installed. Also the direct check on the client showed that a new version is installed and not 68.73.16498. I will definitely create a support case today. We apparently have over a million Chrome vulnerabilities.
Regards
David

David,

Are you guys using PatchMyPC to deploy Google Chrome? That is what we are using and from what I understand PacthMyPC used to modify the version number in the Chrome Enterprise Edition msi file. When I open the Chrome Enterprise Edition msi file for Chrome 91.0.4472.77 the version number reported in the MSI is 68.94.77.

1 Like

Good Morning Folks - Are you assessing these assets with Agents by chance where you’re seeing this or with scan engines? Let me check to see if I’m able to provide more info on how we’re assessing but in the meanwhile this key piece of info will help me understand if what you’re hitting is a known defect (for which we’re shipping a fix this upcoming release!) or not :slight_smile:

1 Like

The systems I am seeing this issue on do have the agent installed. I am however scanning with our network scanners using a scan template that is not set to skip checks performed by the insight agent.

Could we get more information regarding what this known defect may be? I’m being asked why our Chrome vulenrability numbers are so high and when that will be fixed. I have a support case open for this issue already, case 00441846

1 Like

Gabe - the known defect regarding Chrome that I am referencing (which I am not saying is at play in your specific case as I have not had the chance to review it, but I am noting here for customers anyway for transparency): is that we’re seeing issues with chrome fingerprinting where we can identify Google Chrome plugins as installations of Google Chrome. This defect is actively being worked by our Engineers and is slated to be fixed in our release this upcoming Wednesday!

1 Like

Ok, we have seen that as well. We have one user with a Chrome plugin that is version 2.0.0.0 so the system is being identified as running Google Chrome 2.0.0.0.

David could you check one of your systems that is reporting in SCCM as having an old version of Chrome installed and see what is in place for this registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{B6E20433-9CA8-39D7-93CD-7191D79C0A6C}\DisplayVersion

Our systems are reporting a value in that DisplayVersion key as 68.94.77

Hello everyone
Thank you for your answers. Very helpful. In the meantime, support has also responded to my case (00449353) and confirmed the fingerprinting problem as Gina already wrote. @gina_seiber We don’t have any agents in usage, because we use Nexpose and don’t have InsightVM enabled. Interestingly, I do not have false / positives on all Windows 10 clients. Of the 5600 Windows 10 clients tested, 1400 have exactly 712 vulnerabilities, which points to the fingerprinting issue.
@Gabe I will contact our client engineer to check the registry entry on the system where we did the spot check.

Update:
Auf MDATP wird die Software Evidence anhand des Installationspfads gemacht:
2021-06-11_08-26-38

And here is a screenshot from the registry:
2021-06-11_08-41-59