mcafee and malware creation

if you hadn't already heard, mcafee plans to teach a class on "malware experience" at a 4 day security conference they're holding this coming week. there were only a couple of reactions to it that i saw, notably david harley's post at threatblog and michael st. neitzel's post on the sunbelt blog. the sunbelt post in particular drew the attention of mcafee's dave marcus who clarified exactly what was going to be going on - to the extent that the controversy around the promise of showing attendees how to create new malware seems to have died a quiet death.

i could have weighed in when i first read about this but the wheels of change had already started to turn and i wanted to see where things went before i said anything. the end result, however, seems to be mcafee has placated people's concerns with hollow promises that instead of teaching people how to make malware from scratch, they'll instead be using an existing toolkit to create the malware. the implication is that since this toolkit produces malware that is already detectable (at least as far as mcafee's product goes) then they aren't really contributing to the malware problem. if you're detecting the distinct aroma of a barnyard right now, you're not alone.

there are a couple of problems here so lets go through them one at a time. the first is the simple fact that mcafee is in the anti-malware business. i've said this before and i'll say this again - if you're anti-X you shouldn't go around making X's and you sure as hell shouldn't encourage others to do so. the company's namesake reputedly got into trouble with the rest of the industry by offering such encouragement in the form of financial incentives (paying for new viruses). now in this new case it's all going to be done inside a closed environment to prevent undesirable consequences so there should be no problems, right?

wrong. the work in the classroom will take place in a closed environment, but i have no doubt that some of the attendees will subsequently play the home version of the game, running malware toolkits on their own environments and creating malware in less secured environments (you can't really believe that they'll learn everything they need to to handle malware safely in those 4 hours the class will run). a class like this encourages precisely this behaviour. it makes it seem ok for less experienced people to handle malware, and to that end even people who never attended the class will also play the home game if such behaviour is endorsed.

think that sounds far-fetched? it isn't, there are already well intentioned but ultimately unqualified people playing with malware and inadvertently contributing to the malware problem. it's been going on for years. sarah gordon covered this in her paper "The Generic Virus Writer II". that's a pill that the technologically inclined don't want to swallow, they think they understand malware well enough to prevent unintended consequences, but the reality is that most people lack the wisdom to appreciate the extent of their own ignorance.

finally, given the probable result of people playing the home game with the same malware toolkit used in the class, should they contribute to the malware problem they will do so in a way that benefit's mcafee because their product already detects all the output of the toolkit. they will be breeding demand for their product in an absolutely unethical way - by teaching people just enough to cause problems that their product can fix (others may as well, but it's impossible to know at this point).

mcafee is behaving irresponsibly and unethically, and i'm struck by how things seem to have gone full circle with them. while others seem to have let them off the hook because they're using a toolkit instead of teaching how to create malware from scratch, as far as i'm concerned the only difference is the sophistication of the malware creators they are going to produce. mcafee will be teaching a new breed of script kiddie and tarnishing the industry's reputation once again. congratulations on being part of the problem, mcafee folks.

are good spyware simulators still a bad idea

so apparently someone came up with the idea of creating spyware simulators collectively known as spycar (apparently a play on the eicar test file) for testing the effectiveness of anti-spyware applications...

the idea, basically, is that a bunch of these tiny applications could be written that each do some small spyware-like thing... supposedly this is meant to test how well an anti-spyware app can detect spyware they don't already know about - the more of these spyware simulators the anti-spyware detects the better it is (in theory)...

this idea came up before in the virus realm years ago and i'll direct you now to sarah gordon's paper are good virus simulators still a bad idea... i suggest reading the entire thing through but for now just scroll down to the conclusion and replace "virus" with "spyware" and it will be about as valid...

essentially, for testing the effectiveness of your security app, using simulators only tells you how good the app is at detecting simulations rather than the real thing... to assume that anti-spyware vendors won't simply add signatures for the simulations is naive, especially when their work starts being judged on how well it detects the simulations... there's no way this effort on it's own is ever going to force the vendors to improve their generic detection techniques, it's just not a cost effective way for the vendors to deal with the simulations...

as for using these things as test files to see if your anti-spyware app is installed correctly (as their namesake the eicar standard anti-virus test file was intended for) the anti-spyware vendors could just as easily use the eicar test file directly for that purpose... there's no need to implement any particular behaviour in the test file if all you're doing is checking if the app can detect something it already knows about; it's not like the eicar test file has any virus-like behaviours, nothing of the sort was required to test the sanity of an installation, all it does is display a string of text on the screen (at the command prompt) when executed...

clearly, if folks in the anti-spyware field are just now coming up with an idea that was debunked in the anti-virus field over a decade ago, the anti-spyware field isn't anywhere near as mature... the question is are the anti-spyware principals looking into learning from what the anti-virus community and industry have already figured out?...