In any case, it was exciting to work extensively with PowerBI. The data warehouse function and the excellent documentation of the data warehouse schemas were extremely helpful. This was one of the reasons why we decided to implement Rapid7
Sorry for the off topic
1 Like
I’m glad to hear our data warehouse schema documentation was helpful for you @david_altanian! I’ll make sure to pass that information along to our Engineers who originally wrote this, I’m sure they’ll be happy to hear this <3
1 Like
All - I am happy to report that the current ETA on the workaround fix for this issue to ship with our product release is on 7/21/21! We have added an additional check to our Google Enterprise Chrome fingerprinting to attempt to work around Chrome issues where deployment via SCCM or similar software deployment technologies has the potential to report an incorrect version. 
Looking forward to hearing your feedback!
1 Like
Hi Gina, great news. Thanks for the update. At my last scan on 13.07. google Chrome was only detected incorrectly on 53 Windows 10 1909 clients out of a total of 5500 checked clients. The next scan will take place on 27.07. I will report again as soon as I have the results.
1 Like
One day away from this shipping, I wanted to share more details about how this workaround is functioning for you all:
We are now collecting an additional registry location, specifically the: HKEY_LOCAL_MACHINE\\SOFTWARE\\Google\\Update\\ClientState\\ key, we are then checking every subkey of this key and linking it to the uninstaller keys we already gather via the EnterpriseProduct key as this key and the uninstaller key share the same UID, if we get a link between the Clientstate key and the Uninstaller key we will fingerprint from the Clientstate keys information as from the customer data we have received it has not been affected by the same bug. One caveat of this fix is that the Update keys don’t exist until an update is taken and applied on the system.
Just in case anyone was interested in the solution details, we figured it would be better to have the information available! I just wanted to thank @david_altanian & @gabe_verrault for your help and to our moose Sam D for all of your due diligence and partnership throughout this issue - I am so fortunate I get to work with so many amazing folks every day! 
1 Like
Thanks for sharing the details and keeping us up to date! This will help us greatly to better understand the results after the next scan on our site. I consider the exchange here on this platform to be incredibly valuable. 
2 Likes
hey folks, I just wanted to check in after this shipped to ask how things were looking now? Are we seeing significant improvement? 
Hi Gina
I forgot to give you a short feedback before I went on vacation. On the last scan of 24/07/2021, I can confirm that no more false positives were reported. all Chrome installations were detected correctly. Thanks for the quick solution.
Best regards
David
2 Likes
@gina_seiber We are still being affected by this issue. I have another suggestion. Is it possible for R7 Agent to interrogate the current running process list, and if the Google Chrome updater (Chrome Enterprise Edition msi) is running, then skip the check for Google Chrome version as an indicator for vulnerabilities. It seems that relying on side effect artifacts like registry keys or files present don’t work. However, if the installer is running, then checking for the install process running is a guaranteed artifact that will show up.
It also makes sense that when a system is being updated with Chrome, it is in a transitory state, and thus using data sources like the registry can lead to false positives. Interrogating the process list for chrome install should help detect this transitory state and allow the agent to bypass checking for Chrome during that install period.
1 Like
Hello everyone,
I know it is an old topic, but the issue regarding incorrect Google Chrome fingerprinting reappeared this week. So far, only eight devices have shown up in our results with an unusually high number of vulnerabilities originating from Google Chrome. According to the proof data, version 70.158.xxx is installed.
However, checking the devices on Microsoft Defender the result looks like this:
We still don’t use the Insight Agent on all of our endpoints. We use the agents only on remote locations were we are not able to setup a dedicated scan engine.
Are we the only customer with this issue right now? Should I open up a new support case?
Best regards
David
Update: I have opened a support case.
1 Like
We are seeing the exact same issue that you are seeing David. We’ve actually been tracking this for the last year believing it was an issue with our SCCM. I finally did some research here and found this thread.
We have agents on most of our assets impacted and scan engines covering the rest. Currently we’re seeing over 200 assets with ‘ghost’ installs of old Chrome and the number climbs every month.
We have noticed that with every major revision of Chrome a ‘new’ set of ‘old’ Chrome shows up. For instance, when Chrome version 130.x was out Rapid7 was identifying assets as having Chrome version 69.x installed. Now version 131.x is out and we’re seeing assets with version 70.x installed.
The only solution we’ve found from our end, is to completely reimage the system. This is impractical at best.
If Rapid7 had a solution before I’d like to hope they can push another update to fix the issue now.
1 Like
Hi @dweatherby,
Thank you for providing valuable information on this issue. Upon review, I can confirm your observations. I looked into a similar case from last year, and it aligns with your findings.
Fortunately, only five Windows 10 clients are affected. I will advise our IT team to uninstall and reinstall Google Chrome, as this seems to be the only way to eliminate these false-positive findings. IT management has already been knocking on our door, questioning why these clients have over 1,500 vulnerabilities.
I hope Rapid7 finds a way to resolve this issue soon.
@dweatherby Here’s a quick update from my side. For one asset, we uninstalled and reinstalled Google Chrome, and the re-scan delivered correct results. For another asset, I deleted it from the Rapid7 console and re-scanned it, which also led to correct results.
Going forward, I will first delete the affected assets and re-scan them. If this doesn’t resolve the issue, I will raise a ticket for our IT support to uninstall and reinstall Google Chrome. It’s a cumbersome task, but I want to avoid false positives in our management reporting. Answering the same questions repeatedly from management is not something I enjoy 
.
Just thought I’d share that I’ve been told by my rep that there is a fix for this in QA. It had to do with MSI vs EXE installers I believe.