I just live with Windows Defender (heavily modified via GPO to disable sample submission and auto-remediation) these days as there is no such thing as a pure third-party antivirus product anymore. Avast (and basically all others) want to do things like install their own "safe" browser, MITM https connections by installing certificates in the root CA store, screw with firewall settings, etc which I absolutely do not want happening on my system.
All I really need is something that will hook into the filesystem layer and scan files as they are accessed/written/executed and gives me a clear UI that allows me to choose what happens if it detects something.
Some antiviruses are better than others, some are faster than others,
prices are different (some are free), support is different.
See virustotal.com when sending a file, how many engines will find
something, how many will miss, and how many will tell you that malware
has been detected on a clean file.
Part of the gap that still exists is cost. A cloud service that isn't constrained by your local resources can do more as far as password cracking or applying AI to the password protected document/container problem, but we're not at a point where they're going to apply that to every hotmail or gmail account for free.
Some of the third party EDRs do things than even the top tier Microsoft Defender
XDR with Vulnerability Management can't do yet, and there is no "built-in" EDR for Linux.
Third party security tools have always been monkey patches for gaps in the OS. Eventually the OS gets the features that the third parties have, but then new threats create new requirements.
Whether you need it or not is a question for your threat model, but for me personally it's been years since I felt it was worth it on Windows. I still use a commercial EDR system on Linux due to the OSS solutions being quite lacking.
“A current trend in cookie theft malware distribution is packaging malicious software in an encrypted archive—a .zip, .7z, or .rar file, protected by a password—which hides file contents from Safe Browsing and other antivirus detection scans. […]
Attackers often make the passwords to encrypted archives available in places like the page from which the file was downloaded, or in the download file name. For Enhanced Protection users, downloads of suspicious encrypted archives will now prompt the user to enter the file's password and send it along with the file to Safe Browsing so that the file can be opened and a deep scan may be performed”
So, what group of users will actually do that? They’d have to a) know they got a suspicious file, b) know how to find its password, and then c) upload it to Google.
I think b) definitely is too hard for most users. Chances are quite a few will send their own password instead.
Also, if Chrome can prompt the user for the password, and it is “available in places like the page from which the file was downloaded, or in the download file name”, why can’t Chrome look there for that password? I bet Google’s engineers can write something that’s better at that than the average user.
Edit: There’s a slight security risk there, but Chrome could also decrypt the file locally and keep the password on the local system, couldn’t it?
> They'd have to a) know they got a suspicious file, b) know how to find its password, and then c) upload it to Google.
One scenario might be:
1. Some dodgy website A hosts a file on a different file uploader website B.
2. File is encrypted with some password that's visible on website A, but not visible to any other website that hotlinks to the file on website B.
3. User visiting website A has some idea of what they might find in the file that they just downloaded, but because website A has a dodgy reputation, and Chrome offered to check the downloaded file on their behalf, they then willingly submit the password that was found on website A.
Users do #3 because it's convenient. Also, they would be protected from whatever bug that might have been triggered on extraction.
Though personally what I would do is download the file, extract it locally, and scan it locally. Assuming that I trusted the website in the first place.
> I think b) definitely is too hard for most users.
Since the person downloading the file can't unpack it without knowing that password themselves, if finding the password is too difficult for them then they're already protected from the archive's contents.
14 comments
[ 0.14 ms ] story [ 59.7 ms ] threadAll I really need is something that will hook into the filesystem layer and scan files as they are accessed/written/executed and gives me a clear UI that allows me to choose what happens if it detects something.
Thus as OSes have improved, and created bad incentives for those products to stay in business.
See virustotal.com when sending a file, how many engines will find something, how many will miss, and how many will tell you that malware has been detected on a clean file.
Third party security tools have always been monkey patches for gaps in the OS. Eventually the OS gets the features that the third parties have, but then new threats create new requirements.
Whether you need it or not is a question for your threat model, but for me personally it's been years since I felt it was worth it on Windows. I still use a commercial EDR system on Linux due to the OSS solutions being quite lacking.
How long before someone recreates this "prompt" in a page or addon and cons people out of their passwords?
Attackers often make the passwords to encrypted archives available in places like the page from which the file was downloaded, or in the download file name. For Enhanced Protection users, downloads of suspicious encrypted archives will now prompt the user to enter the file's password and send it along with the file to Safe Browsing so that the file can be opened and a deep scan may be performed”
So, what group of users will actually do that? They’d have to a) know they got a suspicious file, b) know how to find its password, and then c) upload it to Google.
I think b) definitely is too hard for most users. Chances are quite a few will send their own password instead.
Also, if Chrome can prompt the user for the password, and it is “available in places like the page from which the file was downloaded, or in the download file name”, why can’t Chrome look there for that password? I bet Google’s engineers can write something that’s better at that than the average user.
Edit: There’s a slight security risk there, but Chrome could also decrypt the file locally and keep the password on the local system, couldn’t it?
One scenario might be:
1. Some dodgy website A hosts a file on a different file uploader website B.
2. File is encrypted with some password that's visible on website A, but not visible to any other website that hotlinks to the file on website B.
3. User visiting website A has some idea of what they might find in the file that they just downloaded, but because website A has a dodgy reputation, and Chrome offered to check the downloaded file on their behalf, they then willingly submit the password that was found on website A.
Users do #3 because it's convenient. Also, they would be protected from whatever bug that might have been triggered on extraction.
Though personally what I would do is download the file, extract it locally, and scan it locally. Assuming that I trusted the website in the first place.
Since the person downloading the file can't unpack it without knowing that password themselves, if finding the password is too difficult for them then they're already protected from the archive's contents.