if you follow infosec news sources at all, by now you've probably heard about the claim made by an anonymous pair of ex-kaspersky employees that kaspersky labs weaponized false positives.
more specifically, the claim is that engineers at kaspersky labs were directed to reverse engineer competing products and use that knowledge to alter legitimate system files by inserting malicious looking code into them so that they would both seem like files that should be detected and be similar enough to the original file that the competing product will also act on the legitimate file and in so doing cause problems for users of those competing products.
i've heard this described as fake malware, but for the life of me i can't see why it should be called fake. the altered files may not do anything malicious when executed, but they're clearly designed to exploit those competing products. furthermore, there is clearly a damaging payload. this isn't fake malware, it's real malware. it may launch it's malicious payload in an unorthodox and admittedly indirect manner, but this is essentially an exploit.
some consider the detection of these altered files to be false positives because the files don't actually do anything themselves, but since they have malicious intent and indirectly harmful consequences, i think the only real false positives in play here are the original system files that are being mistaken for these modified files.
by all accounts, this type of attack on anti-malware products actually happened. what's new here is the claim that kaspersky labs was responsible at the direction of eugene kaspersky himself. there's a lot of room for doubt. the only data we have to go by so far, besides the historical fact of the attack's existence, is the word of anonymous sources (who potentially have an ax to grind) and some emails that, quite frankly, are easily forged. circumstantially there's also an experiment kaspersky participated in around the same time frame that has similar earmarks to what is being claimed except for the part about tricking competing products into detecting legitimate files as malware.
i don't expect we'll ever know for sure if kaspersky was behind the attacks. doubts have been expressed by members of the industry, but frankly i've seen too many things whitewashed or completely ignored (like partnerships with government malware writers) to take their publicly expressed statements at face value. there are certainly vendors i'd have a harder time believing capable of this but there just doesn't seem to be sufficient evidence that the claims are true. the problem is that i can't imagine any kind of evidence the anonymous sources are likely to have that isn't easy to repudiate. had they taken a stand at the time (like someone with actual scruples would have done) they would have been able to put their names behind their claims - they may have lost their jobs but they surely would have been able to find employment with a different vendor because hiring a whistle-blower would have been good PR.
however, as it stands now, the anonymous sources have to remain anonymous. if they're telling the truth then they are complicit in kaspersky's wrong-doing, and if they're lying they are throwing the entire industry under the bus for no good reason (because this claim fans the fires of that old conspiracy theory about AV vendors being the ones who write the viruses). Either way, to have this claim linked to their real identities now would make them radioactive in the industry. no one would touch them, and for good reason.
long ago it used to be that the industry only employed the highest calibre of researchers. people who were beyond reproach. naturally, in order to grow, the industry has had to hire ever increasing numbers of people and old safeguards against undesirable individuals joining the ranks don't scale very well. increasingly people who aren't beyond reproach are being found amongst the industry's ranks and there appears to be no scenario where these two anonymous sources don't fall into that category. the inclusivity that the general security community embraces (and that the anti-malware industry is increasingly mimicking) has the consequence that blackhats are included. the anti-malware industry is going to have to either figure out if they're ok with that or figure out a way to avoid what the general security community could not.
devising a framework for thinking about malware and related issues such as viruses, spyware, worms, rootkits, drm, trojans, botnets, keyloggers, droppers, downloaders, rats, adware, spam, stealth, fud, snake oil, and hype...
Showing posts with label false positive. Show all posts
Showing posts with label false positive. Show all posts
Tuesday, September 01, 2015
Thursday, April 22, 2010
mcafee's catastrophic false alarm
mcafee recently published a signature update which, when applied, caused their anti-malware software to falsely identify a critical windows component as malware and quarantine it. hilarity did not ensue. boot failure, on the other hand did.
what the hell, mcafee? i thought you folks knew better. this is not the first time a catastrophic false alarm has happened - i don't think it's even the first time it's happened to you. this is a problem that was identified years and years ago and i would have thought that every major AV vendor would have figured out how to avoid this.
i guess i was wrong, so i'll spell it out:
i'm not sure what kind of QA you're doing on your signature updates, but if you're not including this test (or worse if you are and this still happened) then you're doing it wrong.
EDITED 2010/04/22 19:59: it occurred to me after posting the above that there was in fact another way this problem could have been avoided that is perhaps a little more sophisticated.
for years now spam filters have been using whitelisting as a means of avoiding falsely classifying correspondence from important contacts as spam. if mcafee's known malware scanner were outfitted with a small whitelist of critical OS components that must not be false alarmed on under any circumstances then svchost.exe wouldn't have gotten quarantined and mcafee customers would have been saved a great deal of hassle.
this is a perfect example of how blacklists and whitelists can complement each other. i've been saying for a couple years that blacklists, whitelists, and sandboxing were complementary technologies and i've felt that anti-malware products would be even better if they incorporated all 3 of those preventative paradigms. to date the only vendor i'm aware of who actually does that is kaspersky (apparently they introduced sandboxing into their internet security suite this year), but as i haven't tried the product i can't comment on the efficacy of their execution. i'm also not so sure any of their whitelisting is integrated into their blacklist in the manner described above.
what the hell, mcafee? i thought you folks knew better. this is not the first time a catastrophic false alarm has happened - i don't think it's even the first time it's happened to you. this is a problem that was identified years and years ago and i would have thought that every major AV vendor would have figured out how to avoid this.
i guess i was wrong, so i'll spell it out:
- maintain a library of every version of every critical operating system component
- before you release a new signature update, use a system with that update applied to scan the aforementioned library of critical operating system components
- if there are any alerts, DO NOT RELEASE
i'm not sure what kind of QA you're doing on your signature updates, but if you're not including this test (or worse if you are and this still happened) then you're doing it wrong.
EDITED 2010/04/22 19:59: it occurred to me after posting the above that there was in fact another way this problem could have been avoided that is perhaps a little more sophisticated.
for years now spam filters have been using whitelisting as a means of avoiding falsely classifying correspondence from important contacts as spam. if mcafee's known malware scanner were outfitted with a small whitelist of critical OS components that must not be false alarmed on under any circumstances then svchost.exe wouldn't have gotten quarantined and mcafee customers would have been saved a great deal of hassle.
this is a perfect example of how blacklists and whitelists can complement each other. i've been saying for a couple years that blacklists, whitelists, and sandboxing were complementary technologies and i've felt that anti-malware products would be even better if they incorporated all 3 of those preventative paradigms. to date the only vendor i'm aware of who actually does that is kaspersky (apparently they introduced sandboxing into their internet security suite this year), but as i haven't tried the product i can't comment on the efficacy of their execution. i'm also not so sure any of their whitelisting is integrated into their blacklist in the manner described above.
Tags:
false positive,
mcafee
Subscribe to:
Posts (Atom)