Google Safe Browsing flags this package as malware on RubyGems.org

[indirect]

Hi! I help maintain RubyGems.org, where the metasploit gems (including this one) are published. The Google Safe Browsing project has started to flag the metasploit-payload gem as malware, which you can (probably) see by visiting https://rubygems.org/gems/metasploit-payloads in Safari, Chrome, or Firefox, and getting a giant red modal warning you that the site might harm your computer.

We have appealed this flag based on metasploit.com and this very GitHub repo not being flagged as malware, but had our review requests denied with no explanation or ability to contact a human or follow up.

Since the metasploit team seems able to keep metasploit.com or this very GitHub repo from being flagged as malware, are there any tips or contacts you can share? Feel free to email me privately if you prefer. Thanks!

[ccondon-r7]

Hey @indirect, yeah this is at least the second time someone has flagged that to us, I'm sorry this keeps happening. When you say "We have appealed this flag based on metasploit.com and this very GitHub repo not being flagged as malware, but had our review requests denied," what was the review request process you used?

I ask because the "report error" page that's currently open to the public is this one, which is for reporting incorrect phishing warnings, not incorrect malware warnings. There used to be an option to request review of a site flagged for malware distribution (which is the warning I'm seeing on https://rubygems.org/gems/metasploit-payloads), but now I believe the only way to appeal a "harmful programs" warning is for the site owners to go into their Google webmaster console and check the "security issues" section. If y'all haven't done this already, that's the thing to try (more general info here, which you may have already seen).

Unless something has radically changed in the last decade, the Safe Browsing blocklist mostly comes from automated scanning, so this probably isn't intentional. Google typically sends webmasters an example of the code that's been deemed harmful, so if there's something more specific they've sent beyond just "hey this site has Metasploit payloads," we'd be interested in what it is that keeps getting flagged. Feel free to reach out to msfdev rapid7.com if there's anything we can do to help.

[indirect]

Thanks for the reply! I'll take this to email, and I appreciate the help.

[indirect]

Re-opening this for public discussion with a timeline of what we've experienced so far at RubyGems:

Thursday, May 11: Around 9am PT, the entire domain rubygems.org is blocked. We use the web console to “Request Review”, and mention that metasploit.com is not flagged, rapid7.com is not flagged, and https://github.com/rapid7/metasploit-payloads is not flagged. There is no communication from Google, but the malware flag and all security issues are removed around 5pm PT.

Sunday May 14: Google issues a generic form rejection for our review request, with no information or comments other than “your review was rejected, you still have malware”. Mysteriously, the web console lists no security issues at this time.

Tuesday, May 23: A new version of metasploit-payloads is released (2.0.133.gem), and the .gem file itself is flagged as malware. We request a review again.

Friday, May 26: Our review request is rejected, again, with no comment or explanation, again.

Saturday, May 27: Older versions of metasploit-payloads are newly flagged as malware, triggering 11 separate automated notifications that "malicious or unwanted software has been detected on rubygems.org".

Thursday, June 1: Another version of metasploit-payloads is flagged as malware, triggering an automated "Malicious or unwanted software detected on rubygems.org" email.

Friday, June 9: Another version of metasploit-payloads is flagged as malware, triggering an automated "Malicious or unwanted software detected on rubygems.org" email.

Wednesday, June 9: Additional versions of metasploit-payloads are flagged as malware, triggering 4 additional automated "Malicious or unwanted software detected on rubygems.org" emails.

Tuesday, June 20: Additional versions of metasploit-payloads are flagged as malware, triggering 2 additional automated "Malicious or unwanted software detected on rubygems.org" emails.

That brings us up to date, with a total of:

• 21 automated "malicious or unwanted software detected" emails
• 2 rejected reviews pointing out the same content on GitHub.com and Metasploit.com is not flagged
• 18 versions of metasploit-payloads currently flagged as malware
• 27 different pages on rubygems.org flagged as "linking to harmful downloads"

So far all our attempts to reach a human at Google have failed, and we haven't heard from anyone who works there. If you know how to reach the Google Search Console or Google Safe Browsing teams to try to resolve this, we'd love to hear about it. Thanks!

[ccondon-r7]

Thanks, @indirect. We've gotten feedback from users across several platforms now, and we understand the community's frustration. Unfortunately it sounds like my earlier assumption was incorrect, and this actually is an intentional decision on Google's part, which is surprising and disappointing.

Metasploit payloads are pretty much the textbook definition of security research. There's nothing on the RubyGems page or in the payloads repo that would execute on its own — Meterpreter payloads won't do anything unless they're instructed to do something by a server, which would almost certainly be a running an instance of Metasploit. In the past, we've had export control development partners or EDR technologies take umbrage with tools that get bundled with Metasploit, like Mimikatz or password crackers. We hear where that comes from, but again, no payload or bundled tool is executing from the RubyGems page in question.

For readers more broadly, the Safe Browsing blocklist is, in general, a hugely effective security mechanism, and we'd never suggest that the community circumvent browser warnings, particularly since we have so many novice users and students who learn about security and hacking from Metasploit. That actually makes this doubly unfortunate, since instances like this can be interpreted as the Google Safe Browsing team intentionally making good-faith security research more difficult.

The Metasploit and RubyGems teams will continue to reach out through our open-source and commercial partners to appeal this decision on Google's part. We thank everyone for their patience in the meantime and respectfully request that folks not disable the Safe Browsing feature!

[postmodern]

Have we determined what exactly keeps flagging new versions of the metasploit-payloads gem? On VirusTotal there is still one vendor (CRDF) which is still flagging rubygems.org as malicious. This could be because CRDF consumes Google's Safe Browsing list, or they could be the origin of the flags, or some other automated system is flagging the metasploit-payloads gem.

[indirect]

I believe CRDF flags some gems that are not currently flagged by the Safe Browsing list, so I expect they are independent.

[indirect]

Adding a couple of additional timeline entries:

Friday, June 23: Another version of metasploit-payloads is flagged as malware, triggering an automated "Malicious or unwanted software detected on rubygems.org" email.

Wednesday, June 28: Another version of metasploit-payloads is flagged as malware, triggering an automated "Malicious or unwanted software detected on rubygems.org" email.

[indirect]

Tuesday, July 11: Another version of metasploit-payloads is flagged as malware, triggering an automated "Malicious or unwanted software detected on rubygems.org" email. The list of flagged versions is now:

2.0.105
2.0.109
2.0.112
2.0.113
2.0.114
2.0.118
2.0.121
2.0.122
2.0.124
2.0.130
2.0.133
2.0.134
2.0.136
2.0.137
2.0.138
2.0.139
2.0.140
2.0.142
2.0.143
2.0.145
2.0.146
2.0.149

[indirect]

Since the Safe Browsing team seems dead-set on continuing to flag this gem as malware, we have opened a PR to allow us to remove direct download links for gems that have been flagged as malware on RubyGems at rubygems/rubygems.org#3947.

[indirect]

Somewhat related good news: thanks to the efforts of @duckinator, CRDF threat center (and thus also VirusTotal) no longer flags rubygems.org as malware. In addition to the domain root, the individual .gem files that Google continues to flag are also no longer flagged by VirusTotal, like metasploit-payloads-2.0.149.gem. Hopefully VirusTotal agreeing that none of this is malware will motivate the Google Safe Browsing team to stop flagging the gems as well.

[ccondon-r7]

Thanks for the update, @indirect! I'm sorry again this has been such a colossal pain.

[indirect]

I was hoping that VirusTotal removing the malware claim would resolve this, but it seems like it did not. Today, the Search Console added version 2.0.150 to the list of "Harmful downloads", despite VirusTotal giving that version a completely clean score.

Confusingly, VirusTotal has an entry for Google SafeBrowsing, and it claims that Safe Browsing finds this URL safe, while the Search Console claims that the URL is harmful. I don't really understand how that's possible, but that's how it's showing up today.

[ccondon-r7]

Thanks for the update, @indirect — this continues to be an unusual and disappointing choice on Google's part. Please let us know if there's anything we can do directly!

[indirect]

Just to keep the timeline completely updated:

Thursday, Sept 28: Version 2.0.152 of metasploit-payloads is flagged, triggering an additional automated "Malicious or unwanted software detected on rubygems.org" email.

For no particularly apparent reason, version 2.0.151 was not flagged, even though 2.0.150 and 2.0.152 were both flagged.

[indirect]

Wednesday, Oct 4: Version 2.0.155 is flagged, sending one more "Malicious or unwanted" email. As far as I can tell, 2.0.153 and 2.0.154 were not flagged.

[indirect]

Looks like the CRDF is back to flagging the gem as malware, based on this VirusTotal scan. @ccondon-r7 is there any chance you can work with CRDF to proactively stop them from flagging this gem in the future? If Google records the flag and then doesn't remove the flag even when CRDF does, that might explain the current situation.