Google has marked my website as harmful for a file that does not exist | Hacker News Reader

Google has marked my website as harmful for a file that does not exist

26 pointsgunal229 comments

Background: Recently, I encountered an issue where Google flagged my website as potentially harmful due to the presence of malware samples. These samples were uploaded, securely encrypted within a zip file, for the purpose of facilitating malware analysis by cybersecurity experts (Like virustotal (owned by Google), malware bazaar, etc.).

Actions Taken So Far: Upon discovering the situation, I promptly removed the identified malicious files from our website. Subsequently, I initiated a thorough review request with Google, outlining the steps taken to rectify the issue and enhance our website's security measures. However, despite these efforts, Google's response indicates that traces of malicious content are still present on our site.

Google said these are the malwares: https://ibb.co/QYJ8Fhq

When you try to go these links, you get this response: https://ibb.co/DVfztTj

Do you have any idea about fixing this situation ASAP? People can not log in to our app.

To be less indenciary with the title: Google marked the website as harmful for hosting harmful content, which it was, but which has now been removed, and the recognition has not been updated.

It could be caching, or it could be a policy thing. Websites that once hosted harmful content are probably much more likely than average to host it again. I do hope this can be reverted of course, I understand that the intention was not to be harmful (not that that would prevent a bad actor from pointing people to your download).

Have you made sure your robots.txt allows Google to scan and properly identify that the files have disappeared?

Also, how long have you waited? I wouldn't be surprised if it takes a few days for these sorts of things to make it through all the relevant systems. I do realise that's not very comforting when users are unable to use a website!

As an aside, to prevent this in the future perhaps, you mention that the files were encrypted. This should have prevented this because Google shouldn't be able to decrypt the file to understand that it is malware. Did you do the encryption from scratch or did you distribute the same encrypted file that might have been previously known about publicly, where Google might be able to pattern-match to known bad files? I would imagine you should be safe zipping and then encrypting the zip with your own encryption.

Disclosure: I do work at Google, but not on anything related to this, this is all just personal opinion based on work outside of Google.

Just because it was encrypted doesn’t mean google can’t run some processing. For example encrypted zip files still can show the file names. These file names could be specific or malware or a collection of matching file names.

This is why I said zipped then encrypted, yes any pattern matching like filenames could be used to identify malware.

Plus encrypting then zipping removes any compression opportunity so that's just a bad idea.

> Plus encrypting then zipping removes any compression opportunity so that's just a bad idea.

Not always!

https://en.wikipedia.org/wiki/CRIME

As i mentioned before, i know hosting these files on our local server is not the best practice. There are other businesses doing this thing and Google is not marking them harmful. All files are zipped with a password, we provide the password to users.

Also, the filename is not a unique indicator the identify a file as malware. I can put the filename as "Google Chrome.exe" and that doesn't mean this is a malware.

The second issue is, we just changed the our domain name and when i try to add it to "Authorized redirect URIs" for Oauth getting this error: "The request has been classified as abusive and was not allowed to proceed". So, i have no idea about what is going on about my domain.

Zip password encryption is trivially broken and should not be trusted for anything more than basic obfuscation. I'd recommend:

- Using AES directly yourself with a strong password.

- Hosting behind authentication

- Using a different password per user.

This should a) make it effectively impossible to detect the malware, b) make it clear that the intention is for research and education only, and c) prevent bad actors from maliciously using your hosted repository of malware.

> when i try to add it to "Authorized redirect URIs" for Oauth getting this error: "The request has been classified as abusive and was not allowed to proceed"

Is this for Google OAuth? I don't know anything about this system, but I wouldn't be surprised if the data lags behind the up to date safe browsing database. Maybe try again tomorrow?

Yes, for Google Oauth. I'll try again, but the domain is completely new. We just moved another domain.

The fact remains is web platforms are in every way at the mercy of Google to be reachable to their clients. Chrome (which your clients most definitely will be using) has full power to decide if your website is malicious, but you don't even know the criteria of their decision, and so, have little-to-no knowledge on how to adjust your website to pass the criteria again. I have seen web development platforms being blocked out of use for weeks; because some scammers use their service to build their scamming site, causing the whole domain to be marked as spam.

However there are still two ways to look at this: The defeatists will say that the open web of the old is now fubar, there is no point in building websites now because whatever you do you are at the whim of BigTechs to dictate the term of your website.

I try to keep more optimistic viewpoint. We can see that this is more or less the standard behavior of any antivirus measure, and your browser/antivirus service is tasked with an impossible job of deciding if the data it renders is benign or malicious, and whatever heuristic/criteria it comes up with is going to be leaky and cannot cover every edge cases. Platform should structure their system so that your components are localized, so it will be less susceptible to those kind of outage. Of the top of my mind, what step you should be taking: - Separation of domains between for your own assets/web and what the clients upload. A CDN, online bucket may help you here. - If you are doing a website builder, try to enforce the client to bring their domain to publish. Your default domain should be for evaluation purpose only.

It's hard world out there, sympathy to OP for being in this shitty position.

Google is correct. The site was hosting malicious content, the site was public-facing, and Google took steps to protect its users trying to visit a site that was hosting malicious content which is more than anyone else would do. What else could you ask for?

I can go host malware on my site now, get flagged, take it down, tell Google, get my site un-flagged, and re-host the malware. Google can play cat-and-mouse with me at the expense of its users, or just keep the site flagged until enough time has passed and/or if I make enough noise about it. It's not common for a site to intentionally host malware, and especially uncommon for sites to host malware for non-nefarious purposes.

Google is doing the same business with VirusTotal.com. We're hosting malware as zipped files, and providing passwords to users. It's not possible to accidentally run the malware as user.

And the problem is not about this, we removed all the files and Google said you didnt. They're not saying you're not trustable website, they said you still have the files but we haven't.

You have to agree that verifying a website is free from a malware is not possible, while verifying that it has a malware is easy. If I play devil's advocate and say that:

1. A bad actor is publishing a malware at example.com/malware-a.zip;

2. The antivirus measure block them;

3. They move it to example.com/malware-b.zip but tell Google that the site is free from all malware, because if Google hit the old url `example.com/malware-a.zip` it is a 404;

Should Google give the bad actor the benefit of the doubt, unblock them/ or keep blocking them?

Again, I'm not downplaying the shittiness of the situation both you are in right now, but again, this is the default behavior we are all expecting from any antivirus measure.

No I agree with your point and was addressing other blind anti-Google sentiment. While middle-finger to Google for their inhumane ad-based business model, we have to admit that they are doing what they are expected to do in this exact scenario.

Safe Browsing is used by Chrome, Safari, Firefox, Vivaldi, Brave, and others.

Talk about a misleading title

They review the website and continued to marking as harmful. Why do you think this is misleading?

I guess technically Google flagged the site while the malicious files were still being hosted; it's not that they flagged the site when it wasn't hosting malicious content.

You buried the lede - the important context is that your site hosted malicious content at one point, regardless of intent. Whether the policy is correct or not, withholding that information in the title isn't doing you any favors.

Maybe a cache problem at google end. For info, your domain is hidden but a quick search on the path that is not hidden will unveil your domain. So i tried to open your website (firefox) and it works fine, only the url of the files are marked as "dangerous".

We just moved our API domain to another domain. That's why it's working well now. I have the same opinion, maybe their system is cached but it's affecting our business. And if you get declined one time, they're not responding to you quickly again.

Well I have to say, it wasn't really a good idea to put malwares files directly on your business domain, even for research purposes and with encryption. Send a link to an external host next time !

That's right. It's not the best practice, i totally agree with that. The problem is, i already removed the files but Google is not accepting that. And also they are doing the same business with VirusTotal, but its working really well.

They're just clicking the decline button, and its affecting our business.

But how is it affecting your business if only the paths 'download/.....zip' are flagged?

Does your api use theses paths as well ?

They didnt marked just the URLs, marked the domain as harmful.

No. I tested with Edge/Chrome/Firefox and your domain (and subdomain app.) are working on my end. I can acces the login page, and the main page.

Only the path '/download' seems affected. I don't understand why your api would use that though.

Yes, the reason is we changed the domain. We had to that, because people couldnt login the app they paid.

IMHO serving those malware sample directly on a website is a bit unwise. The thing is, a true bad actor can still publish an encrypted .zip file of a malware under an innocent front and manipulate the users to decrypt the file, unknowingly execute the malware. When it comes to security, we should assume bad faith.

A better way of distributing malware sample for research maybe to serve them in a readonly FTP server. Your website only provide paths to the file, not the link itself. Google (probably?) won't be able to scan this FTP server.

Did you use a standard password? Or how did google even figure out that the encrypted file contained malware?

It's "infected". Like all the other services.

I have never seen a Safe Browsing warning. I concluded it wasn't worth the traffic/privacy costs, or contributing to the normalization of a centralized arbiter of what websites are acceptable.

I disabled it.

Reply on news.ycombinator.com