Crims using anti-virus exclusion lists to send malware to where it can do most damage Advanced malware writers are using anti-virus exclusion lists to better target victims, researchers say. Software vendors use exclusion lists to explain the files and directories that antivirus software should ignore to avoid false positives and ensure an application's proper operations. Such lists are common: Citrix …
Which is why I've always held "Exceptions" in extreme contempt and won't put them on my system wherever possible.
Antivirus exceptions - zero - except for machines that can see the underlying VM storage folder with huge VM images, which I exclude because the machine has antivirus, and the VM's inside it have antivirus, and if you can write to the underlying VM storage folder, I have bigger problems anyway.
Web filtering exceptions - er...no. I work in a school so I might classify your site as "pupil" or "staff" instead of whatever default is chosen, but I won't "just exclude". Because every time I've been asked to do that, it includes things like the entire Amazon EC2 range. And if I say "No, honestly, it's excluded" then you always find out that the "problem" was somewhere else anyway.
Recently had this with my print vendor who have this billing tool that talks home to them. It needed all kinds of proxy exceptions and bypasses. So I just installed it. Done. They even say "it doesn't support proxies", which is weird because there's a box to put the manual proxy information, which works perfectly. The fact that the software itself falls over once a month is neither here nor there, apparently, though. But it has nothing to do with web access or proxies (because it has a "test" button that works, the logs show it has comms, and what falls over is actually the local machine's SNMP browser).
Sorry but "make an exception for us" is code to me for "lie and pretend that you've done it".
Antivirus exceptions - zero
I bet your AV tooling has built in exceptions. If you manage your windows estate with SCCM or similar, this will have shed loads of exceptions as well, simply to allow it to work without AV trying to stop patching. The way AV heuristics work, you need to effectively whitelist large amounts of a windows core OS otherwise carnage daily.
Why would you not want your AV scanning for genuine pushed software installs to genuine pushed Windows installation locations on your clients?
If you have to make an exception, you're opening a hole.
If you're pushing software over SCCM or indeed any other installation mechanism, though I can understand you might not want the AV scanning huge files that you know are clean unnecessarily, the burden is on the client, so scanning files that are being installed with admin privileges at worst gives you a false positive, at best stops you pushing a virus to every machine by accident.
Though there may be hardcoded exceptions (there is literally NOTHING showing in my exceptions list, not even system folders, hibernation files, etc.), I push software all around my networks and have AV on every client, and DO NOT have to make manual exceptions for anything.
its not the size of the files.
How does the AV know that the file change is the result of malware or SCCM? All it see is that a process is changing a file - and often a system file. The AV then tries to rely on signature based detection (woo hoo) or run heuristics on all affected files with a mix of very limited success and a lot of false confidence.
For most organisations, the end result massive processor usage being driven by overwhelming false positives. This is what leads to the idea that AV software is often more harmful to business productivity than the malware itself.
Pretty much every AV vendor has installation guides to allow it to work with enterprise tooling which basically say whitelist. This is not because the vendors are bad or lazy but because its the most effective solution for enterprise users.
If attackers have pwnd your service accounts and are using them to push malicious files across the network, your AV has already been bypassed and you've got bigger problems than the whitelisting to worry about.
What on earth makes you think malware is exclusive to Windows?
Yes, it might be more prevalent, but thinking you're in any way excluded from malware just because you run another OS is like saying that BMW's don't' crash.
And it makes *you* appear exactly like that - a BMW driver.
Affected OS: Any that use antivirus software that has exceptions.
That's Windows, Mac and Linux before you even start (I have Sophos on all three, in my workplace, it has the same options for all three).
And please don't fall into the trap that a particular instance of a specific virus with very specific characteristics (uses THIS registry key, etc.) is all you need to defend against. There will be several thousand variations within days, including on those other platforms, taking account of the same problem on them all, using slightly different code, targets and markers.
For example, it would now take but a few minutes for a skilled virus writer to take the code for a Windows instance of this virus, modify it or recreate it on Linux, and target the same weakness on the same software on another OS.
The OS just does not matter.
Even the AV doesn't matter.
Assume that, by the time you're aware of a viruses capabilities, those capabilities are available for all platforms, and all similar software.
Anything else is utter stupidity.
WTF do AV companies need an exclusion list for well known vendors like citrix, etc? Why don't they have the program checksums already so they know they are genuine?
Same question with the borking of Windows itself by AV vendors from time to time - where is MS' master list of SAH-1 or whatever checksums so every genuine Windows exe/dll is recognisable?
AV vendors still mess up and mark critical Windows files as viruses all the time. There must have been at least three of those stories in 2016 just on this website.
Whitelisting a particular filename/location/hash combination isn't actually a bad idea - it's quite specific and hard to subvert (chances of being able to replace a DLL in Windows protected folders with a malicious copy with the same hash = millions of billions to one).
But they don't even do that. Because hashing the user's Windows folder on their first run would take a long time. It would take 20-30 minutes of disk churning to do that to get even a basic MD5 out (but an SHA-1 would take almost the same time, just a bit more CPU).
They know that's too expensive, especially while also doing that on every read, so they rely on much smaller "signatures" that can be abused to create malicious files that pass muster, and on things like filesystem modification times / interception of file modifications and the like. Because they can't afford any more performance hit on their scanning as their reputations are already severely damaged by it. There was a time not so long ago when you HAD to specify dual-core just to keep the AV happy while you tried to get work done.
AV is a fraud. They don't check files properly, you can upload definite viruses to VirusTotal and watch basically every AV on the market miss it. And all you need do is change a byte or two of a detected file and suddenly it's no longer detected but still malicious. And they still drag your machine to the ground trying to intercept everything.
AV's could add hash checking along with the whitelisted process to stop the impersonation. Then vendors could supply the whitelist along with the hash for their various versions. Maybe an import via XML file so the vendor can release it and admins can easily apply it.
Hash collisions should be next to impossible to create by malware writers if the right hashing algorithm is used.
You mean like that?: http://tinyurl.com/Hahs-Whitelist
AV in general is outdated. Even the NSA points out, the only real protection is a whitelist of applications. Preferable one based on Hash Values. As they're fingerprint-like there is no way to imitate a Hash Value.
Even though a Hash Collision is possible (as a proof of concept), but that doesn't make a hash based Application Whitelist vulnerable.
Also see: https://en.wikipedia.org/wiki/Collision_attack
and
https://en.wikipedia.org/wiki/Preimage_attack
The Preimage Attack is what you want to go for when attacking a Hash Based Whitelist. If you have enough time, i.e. a few million years!
Best
SecuLution
Your friendly neighborhood Whitelister
AV in general is outdated. Even the NSA points out, the only real protection is a whitelist of applications.
AV is outdated if you are being targeted by a highly skilled nation-state type attacker. However for 80% of businesses being hit by repackaged Dridex attacks launched from either a script kiddie following the latest kali tutorial or from some fledgeling organised crime group trying to raise funds on the dark web, then AV is actually quite cost effective.
Application whitelisting is great, but it can be massively resource intensive for most organisations. Either users are constrained in the applications they can run, wasting time raising an approval because the latest patch for MS Office meant the binary has a new hash and now cant run - or massive effort from the security teams to stay on top of every executable to keep the whitelists current.
Often whitelisting falls into a lesser of two evils camp in which only some applications can do some things. This is great at stopping cryptowall from running as admin and nuking the server but it still needs AV to act as a backstop.
WTF do AV companies need an exclusion list for well known vendors like citrix, etc? Why don't they have the program checksums already so they know they are genuine?
Think how many vendors - how many products - how many files within each product - how many patches, updates, new versions.
I'd add some directories in inclusion lists that I would check anyway, thus poisoning the well.
I have always been of the opinion that you should persistently booby-trap any security information you make public in a way that will catch out abusers. A sort of honey trap, if you like.
Then again, I *am* that devious :).
You need to call your dirty programs svchost.exe as every user is used to there being millions of these buggers on there PC, no one knows what they do and they frequently use 100% of a CPU.
LOL. You remind me of the early days of IRC where every once in a while someone would drop in asking to be told how to hack, usually in caps. It's remarkable how many fell for the standard "start with flooding 127.0.0.1" answer :).
It's what I would have expected as well. It can't be beyond the ability of the AV vendors to accept, in a trusted way, a list of sha1 hashes of these files every time they are updated and build that in instead.
e.g. This file something.exe is in my exclusion list, I will calculate the hash of it and compare it to what I have in my database.
Might work for executables, as long as you can new hashes out in an AV update before new updates to the SW are released, but the only files I've added to my exclusion lists are the junk mail and trash cans for my email client. I don't need those virus scanning, that's where I put the shit. But they'll change all the time so can't have a stored hash.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
