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 
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:
And here is a screenshot from the registry:
Hello everyone
Support has confirmed to me that this Wednesday a fix will be implemented which will fix the problem with GoogleChrome Vulns. Wanted to note this here briefly.
Best regards
David
Thank you all for your very helpful pieces of clues which have helped make this investigation easier! I think in total we potentially have two separate issues at play here:
-
The issue I stated earlier last week in regards to a known defect for which we will ship a release this week, on Wednesday June, 16th which will resolve the issue where we are inadvertently fingerprinting Google Chrome plugins as installations of Google Chrome thus causing False Positives in your environments.
-
Dave A’s call out with Nexpose-Only and no Agents at play helped, as did some of the cases you all opened (thank you!!) which led our Support team to open a Sustaining investigation with one of our Content Engineers (shout out to Sam D!) which is actively in progress. This active Sustaining investigation is promising right now in that it looks like we may be identifying an issue specific to Enterprise Chrome however nothing is yet qualified as a defect. As soon as I have more information I will try my best to update it here
I think it would be helpful to go over a general “how does Google Chrome Fingerprinting Work?” From our release notes you can see that Chrome fingerprinting has gone through some changes recently. So, let’s start with first… what’s changed?
Previously, the scan-engine and agent-based assessments only relied on the version of Chrome that was seen in the Windows Registry to make determinations about vulnerabilities. This was unreliable, as updates to (or removals of) Chrome could potentially not be reflected in the Registry and many customers reported back False Positives as a result and so we worked to change this fingerprinting methodology.
On June 2, we released a change such that instead of relying on versions in the Registry, the product now looks at the file path referenced in the Registry, and confirms the Chrome executable exists there, and uses that version instead when comparing to known affected versions of vulnerabilities. If the file does not exist we included the fall back method to still fingerprint from registry.
Now that we have that as a foundation, how does this differ for Enterprise Chrome?
When it comes to Enterprise chrome installs we have to rely on the registry as an authority as the registry key itself provides no information on where the executable is located; we would have to search the entire file system to attempt to find the executable to confirm the version (why is there no yikes emoji here? 
) In other words, the most notable difference for us is the complete absence of an install location field, this means that we are not able to confirm the presence of the executable on disk as the registry key contains no information to point us towards its location. In a case like this we have to refer to the registry as an authority as if we do not we simply would have to assert that there is nothing present, entirely removing all fingerprinting for Enterprise Chrome.
I hope this information is helpful!
2 Likes
Appreciate the information David! Wondering when myself. 
Hey folks, sorry it’s been a while since I’ve updated but I did want to let those using SCCM + Enterprise Chrome know that we were able to identify an open ticket in Chromium which appears to be contributing towards the issues you’ve been seeing in product 
We’ve qualified a “defect” internally to try to work around this issue since that Chromium bug has been open since 2019 and we’re not sure when it may be addressed. I’ve tried my best to bring attention to the Chromium bug through the folks I know at Google but I can’t make any promises there so I’m working with our PM team to see how we might be able to address this one on our side instead. As soon as I have better news to share, I’ll update this thread!
1 Like
Hi Gina,
From what I can see the last section of the 3 and 4 section version numbers do correspond with each other so I don’t know if there is a way for Rapid7 to update the detection to recognize this
Example being
Google 4 section version number 91.0.4472.114
Three section version number is 68.94.114
Google 4 section version number 91.0.4472.77
Three section version number is 68.94.77
Not sure if that helps at all but thought I would pass that along.
1 Like
Thank you Gabe - I’ll be sure to pass that along to our Content Engineers so that they have that as part of their Research notes, just in case!
@david_altanian Is that a custom report you have written ? Doesnt look like my install of Rapid7! Looks incredibly useful though
1 Like
Hi @andy_taylor
Thanks for the compliment. Since Rapid7 Nexpose does not offer any possibilities to create dashboards and the available reports are rather generic and cannot be optimally customized, I created a vulnerability dashboard using PowerBI.
The whole development took me quite a lot of time last year, but now all the effort has paid off. We in the SOC inform the system and application owners about the latest scan results, which they can then view in detail on the dashboard. For various reasons, we do not want to use insightVM at the moment.
Best regards
David
2 Likes
@gina_seiber Hire this guy! lol
Or show this to your devs and say WE WANT THIS
2 Likes
Andy - I love your positivity! Are you also a Nexpose only user? We have a ton of functionality with our dashboards in InsightVM that add a lot these visuals like David displayed using PowerBI because he doesn’t have InsightVM, curious if you’re in a similar boat.
