open letter to the metasploit community

dear metasploit community,

first, please direct your attention to the following video as it demonstrates the very thing i'd like to speak to you about:


as members of the metasploit community, you are no doubt aware of the various legitimate uses for metasploit and the exploits it generates. validating the efficacy of a patch, testing patch deployments, maybe even some penetration testing.

i imagine that you're also aware that some in your ranks have embarked on a wholly misguided ideological quest to highlight the supposed shortcomings of the anti-virus industry using metasploit and it's output.

now let's be clear about something here; we are all in agreement that there are legitimate uses for metasploit's output, therefore that output in general can only be classified as potentially unwanted programs. let's also be clear that the only proper way to address the vulnerabilities that metasploit's output exploits is by patching the vulnerable software. as such, the argument put forward that there's something wrong with anti-virus products that don't detect metasploit output is fallacious on 2 counts: 1) the output isn't necessarily malware (usually only greyware), and 2) anti-virus products are not the proper defense against known exploits (patching is).

there are some concepts in the anti-malware community that some members of the metasploit community may be less aware of than others. one is that there is a countably infinite number of possible programs, and of those a countably infinite number that can do bad things. it is beyond the realm of possibility to detect an infinite number of things so the anti-malware industry has wisely limited it's focus to those that actually exist, to threats that are real, at least as far as malware scanning goes.

another concept which may not be all that apparent is that, while we've faced users of malware creation toolkits for a long time, we have generally lumped them in with the script kiddies due to the complete lack of skill requirements for using such toolkits.

now, even though metasploit isn't a malware creation toolkit (since it's output generally can't be considered malware), it's being used like one in the above video (with the concomitant implication for the user in question). furthermore, this non-malware is being uploaded to virustotal, effectively abusing the service by wasting it's bandwidth on known non-malware, in order to test scanners in a manner that the people who run virustotal themselves say is invalid.

this in turn is putting pressure on av vendors to add detection for metasploit's output, even though that output isn't technically malware, and you know what? as vendors add better and better detection for metasploit's output files, metasploit becomes less and less capable a tool for the legitimate purposes we already identified because anti-virus products will interfere with it's use. how can you use output files from metasploit to validate patch efficacy, test patch deployment, or perform pen-tests if the anti-virus is blocking them? the argument could be made, i suppose, that anti-virus impeding pen-tests is actually a good thing, but it's clear that anti-virus is a fragile defense against exploits when compared to the proper defense of actually patching the vulnerabilities and if AV is interfering with your ability to test if the proper defenses are in place, that really can't be considered a good thing.

with all of this in mind, i would like to ask the metasploit community to do whatever you can to help discourage people from engaging in the behaviour demonstrated in this video. it's arguably worse for the metasploit community than it is for the anti-malware community, but it is definitely bad for both communities and, i think, bad for security in general. no one is helped when people burn one perfectly good tool in order to shame another simply because the tool they're targeting doesn't behave the way they naively think it should.

malware classification fail

here's one from the drafts pile, hopefully it's not too stale


i'm wondering what the anti-malware world is coming to when the leading vendor classifies something as a trojan even though it clearly discloses what damage it does.

by this logic, every copy of every operating system also ships with a trojan horse program, either in the form of the delete command or the format command.

one of the basic requirements of a trojan is that it tricks the user into executing it - the original trojan horse wouldn't have gotten very far if there was a warning sign on the outside that said it contained enemy soldiers that would sack the city when night fell. so too would suspected malware not get very far if it plainly disclosed what it does.

this game is at worst a potentially unwanted program - in other words, grayware. we can't just go around calling every bad program (or even just every bad non-viral program) a trojan anymore than we can go around calling all malware viruses. not using the proper terminology is a great way to confuse everyone and confusion is something we don't want to sow, right?!?

some critical thinking on fake alerts for the user

tad heppner over at the mcafee avert blog had an interesting user-centric post about fake alerts pushing rogue anti-malware products... what interested me was that it presented some ideas that a user could theoretically apply (like safe hex) to determine whether a particular security alert is trustworthy or not, but i think he could have taken this further...

his suggestion of using responsible browsing practices is a little vague (and some fake alerts don't even make it obvious that they have anything to do with browsing in the first place), doing a bit of research on what you're being asked to install/buy is a good idea (though i suspect people won't have the presence of mind to do that when scare tactics of "you have a virus" are being used), and looking for secondary indications of infection is just a little too technical...

now, presence of mind when scare tactics are being used will always be a problem, but if a user can keep their head and not panic then this line of thought might come in handy: if the alert is warning you that you have something bad on your computer and then asking you to install/buy something then it stands to reason the alert didn't come from something you already installed/bought... now unless you intentionally went to a website that scans your system without needing an install that means that whatever is giving you an alert examined your system without your permission... i think we all intuitively understand that things shouldn't be searching through your files without your permission so that alone should signal to the user to stay away from it, whatever it is...

another good (and somewhat related) idea is to be familiar with what the security alerts from your actual security software looks like so that when a strange one pops up you'll be able to tell that it doesn't belong... downloading the eicar standard anti-malware test file should probably cause anti-virus software to pop up an alert so you can see what that alert is supposed to look like and how it's supposed to behave... that's not the only security software a user may have installed, mind you, but there aren't necessarily simple standard ways of triggering alerts from those other security products, and that's something someone might want to look into...

when is a PUP not a PUP?

when it hides itself...

i came across a post on the mcafee avert labs blog the other day talking about potentially unwanted programs adding 'rootkit' functionality and i was struck by the absurdity of it...

if a PUP is using stealth and taking steps to avoid detection, why are we bothering with the euphemistic classification of 'possibly unwanted program'?

that a program is possibly unwanted implies that there is also the possibly that it is wanted, but taking steps to avoid detection implies that the program's creators don't care if the user wants the program or not and are in fact anticipating that the user won't want it...

if the creators of the software don't genuinely believe people want their software, why are we giving them the benefit of the doubt? i can see some legitimate reasons for software to hide other things on a system (to protect them from uninformed alteration, for example) but i can't see any legitimate reason for a program to hide it's own presence...

i'm not going to call a spade a spade, i'm going to call it a god damned shovel - if what used to be called a potentially unwanted program has added stealthkit functionality then it's no longer a potentially unwanted program, it's fully fledged malware... not all spyware/adware/what-have-you qualified as potentially unwanted programs in the first place, it was always a very special and very tenuous distinction that applied only to the most benign instances... actively avoiding detection isn't the mark of something benign...

a question from panda labs

the folks at panda have floated a question on their blog... it's an interesting question but since they don't seem to have any comment feature available on their blog there does not appear to be any direct way to give them feedback on the question...

in simple terms, given a file format that supports a feature heavily abused by malware purveyors, should anti-virus companies be detecting instances of that filetype where that feature is actually being used and if so what do you tell people who use that feature legitimately?

my answer is yes, absolutely, add detection for files using features known to be abused by malware... of course years ago i was also completely in favour of having anti-virus products detect the MtE mutation engine in spite of the fact that (according to dr. solomon) some knucklehead (my words) was using it legitimately in a code obfuscation product... i don't think i managed to change dr. solly's mind on the matter, though...

now this new case would probably mean some interesting things when it comes to office documents... and then there's html files with embedded scripts... oh, and it would be really cool (though i doubt many would agree) if you could detect multi-media files that make use of digital rights malware technology..

ok, so maybe you have to stick to the format-features that are seeing widespread abuse right now (i still think drm would apply, but anyways) but this is absolutely a worthwhile thing to do - widely abused format-features represent significant risk and tools need to be available to manage (ie. avoid) that risk... that's what you tell the people using those format-features legitimately...

alternatively, don't approach this as something for a virus scanner to naively detect (ie. an entry in the blacklist) but rather as a context in which to apply some sort of whitelisting so that people can add authorization for trustworthy content providers... or hey, why not combine the two - treat such files as potentially unwanted objects or greyware that you detect but include the ability to add exclusions for certain types of content... i think you'll find that files utilizing such widely abused features fit reasonably well into the greyware classification...

what is greyware?

greyware is the class of programs that are neither clearly good nor clearly bad... the world, unfortunately, is not just black and white, there are shades of gray and that is where grayware gets it's name... it's also called things like potentially unwanted programs, potentially unwanted applications, and other variations on that theme...

greyware represents the cases where the context sensitivity problem of the trojan definition is particularly acute... for example, commercial keystroke logging software can fall under a number of malware categories like keylogger, trojan horse program, and even spyware, but if it's used by upper management to keep an eye on what employees are doing with corporate assets or if it's used by correctional agencies to keep track of what convicted felons do online then there's an argument for not calling it malware at all...

another example is adware that gets bundled with conventional software to help offset the cost of that software... if the user knowingly and intentionally accepted the trade-off of viewing ads in order to use the software for free then there's nothing wrong, but if not (and this is often the case) then it's malware...

as should be clear, greyware does not have a functional definition... it would be nice if we didn't see that sort of thing, if we could call something bad or good solely by virtue of what it does, but unfortunately only a black and white world has that property...

back to index