metasploit open letter revisited

"what we have here is a failure to communicate"

at least, that's what it feels like after fielding a bunch of comments on my last metasploit related post. hd moore specifically felt the need to clarify his view and since it seems that my position could stand some clarification itself i'd like to reiterate my response to him here.

my open letter to the metasploit community was meant to drive home 3 points:

1. AV detection of metasploit output is a problem for anyone trying to use metasploit legitimately and not necessarily appropriate.
2. when people go around saying there's something wrong with AV because it fails to detect metasploit output (in other words, there's something wrong with AV because it fails to do something we've already established would be a problem if it did do) then that actually contributes to the problem by generating market pressure on the AV vendors to correct this supposed problem and add detection.
3. since (1) is a consequence of (2), therefore discouraging (2) should help minimize (1).

(2) is what i saw when i watched john strand's video, but as it happens i've also had a chance to communicate with john and gain a better understanding of where he was coming from (i'd like to think he also gained a better understanding of where i was coming from but that's immaterial for this discussion). i won't divulge the contents of a private communication but i will say that i came away with the impression that he was more interested in showing that there is something wrong with defenses that rely too heavily on what is traditionally considered AV.

if my interpretation is correct then i am in complete agreement with him and i think you'd be hard-pressed to find anyone in the anti-malware community or industry who would disagree. i'd even go so far as to say that his video was an appropriate way of demonstrating that point if that point had been presented in such an unambiguous manner. unfortunately that's not what i took away from it when i first viewed it, and as some of the comments on the 'open letter' post show there are those with a far less nuanced understanding of the topic. i just watched the video again and although i found the phrase that triggered my previous response, in light of my new found understanding i no longer see it the same way.

there isn't anything wrong with AV technology per se (and there are certainly some vendors with more non-signature-related bells and whistles than others), but rather the way people use it (as their one and only defense). it's a poor craftsman who blames his tools, so stop trying to drive screws with a hammer and stop trying to block new/unknown threats with a known-malware scanner.

bad advice: disable your av

i'm sure you can probably think back and remember at least one example of a piece of software you've installed in the past that came with directions suggesting you disable your anti-virus before you install.

that little pearl of anti-wisdom has been with us a long, long time and has always irked me. the software industry, whether too lazy, too hurried, or to ignorant to know any better, decided that rather than resolve whatever conflict they may encounter with security software it would be better to train users to drop their defenses.

what could possibly go wrong?

plenty could go wrong, of course, not the least of which being that once the users are effectively trained to drop their defenses when told it would be trivial for malware authors to distribute their wares with instructions telling people to disable their av. who needs to develop technical measures to bypass anti-virus when you can simply tell users to turn it off for you and have them do it like good little trained monkeys.

well, nowadays more and more applications are being delivered to users over the internet, specifically over the web, and along with that, anti-malware products are focusing increasingly on web-borne threats. as such you can probably guess this was bound to happen eventually:

yeah, this WTF moment was brought to you by a facebook application development company called chainn who thought it would be a good idea to tell users to disable (or even remove) norton anti-virus. hey, it worked well enough back in the days of desktop applications, right? why not facebook applications too? i mean, really, what's more important, online safety or finding out how you fit in amongst your friends?

apparently they also have some problems with adblock plus - i wonder why?

fooled by spam

march has really not been my month. first i find out that not only have i finally had my very first malware incident but that it had also been present for nearly a year, and then i get fooled into approving a comment that is in actuality spam.

cdman83 has a writeup on the spam campaign, and gunter ollmann got the final word from sophos that it really was someone loosely associated with them (an employee of a company they hired) who was responsible and who they intend to take to task over the fiasco.

perhaps i'm losing my touch in my old age and becoming too trusting, too willing to give the benefit of the doubt. then again, if i'd had the multiple comments that gunter ollmann had i would have had a far less ambiguous dataset from which to draw conclusions from. i guess i shouldn't feel too bad about being fooled, after all i was only fooled into approving a relatively benign comment - sophos was fooled into hiring the company in question in the first place and giving them money.

the energizer bunny looks more like a RAT

that's RAT as in remote access trojan, for the uninitiated.

by now i'm sure most security folks have heard about this but if you haven't yet, here's the US-CERT advisory, symantec's blog entry by liam murchu, a sophos blog post by graham cluley, a blog post at cybercrime & doing time by gary warner, a sunbelt blog post by tom kelchner, a zero day security blog post by ryan naraine, and that's just the tip of the iceberg.

now the reason i'm writing about this story that so many other people have written about when i normally eschew over-reported news events is because i have a personal stake in this - i actually have the offending device. worse still, i had the software in question installed on one of my computers since late march of last year. ouch! thanks to a tweet by mikko hypponen i found out about this early saturday morning (thanks mikko, that's just the way i wanted to start off my weekend) and proceeded to cuss up a storm because this is the first time in my 20+ years of computing that i have legitimately been been hit with malware - my perfect record is over.

oh well, enough of that. there are 2 things about this that i think deserve closer scrutiny. the first is that question of whether the malware shipped with the hardware device itself as many have stated, or whether the symantec blog is right and the software was only available as a download from the energizer website. i can't say conclusively one way or the other but i can offer some evidence that the software was only ever available from the energizer website.

1. the device has no memory capacity. no drive appears in windows explorer when you plug the device in.
2. when you plug it into a computer it asks to install drivers but can find no drivers to install.
3. the package i got did not contain any separate media, and when i searched for the device on ebay, none of the packages there seemed to either.
4. the instruction sheet (yes, i still have that too) informs you that you can see the charging status on your computer with free software from the energizer website
5. the software is entirely optional. the device works without it (though the software does offer improved usability over the indicator LED). the device even ships with an AC->USB converter (which is what actually drew my attention in the first place) so that you can plug the device into the wall and bypass the computer (and thus any monitoring software) entirely.
6. not only does the instruction sheet instruct you to get the software from the energizer website, but when you plug the device in, the device identifier displayed in both the new hardware notification bubble and driver installation wizard includes not just the product name but also the URL for downloading the software from energizer.

perhaps there was alternate packaging that included the compromised software, but when even the hardware tells you to download the software from the web then it hardly seems necessary for there to ever have been software packaged with it.

the second thing i think deserves examining is the question of what went wrong. as i said, i got hit with this, but could it reasonably have been avoided? that's a question i've been mulling over since saturday. let's go through the various failures and see if i acted unreasonably wrecklessly:

• anti-virus products didn't detect it back then. i scan everything and the software came up 'clean'. av failed to save me here.
• application whitelisting also failed me. it asked if i wanted to allow the software to run but this is software i intentionally installed - why wouldn't i allow it to run?
• of course there are reasons to disallow software you just installed - i did my due diligence and googled the file and everything told me that it was associated with the charger and nothing said there was anything untoward about it. as such the community intelligence, the nascent reputation system of the internet let me down also.
• the software firewall is an interesting case - in theory i could have made the connection and asked why battery charger software needs to open a port and listen for connections. on the other hand, i did research the file and found nothing to indicate it wasn't legitimately part of the software and therefore no reason not to trust that whatever it was trying to do was something it was supposed to do. maybe i could have been more suspicious, maybe i even was - the compromised system was a 10 year old clunker that isn't particular responsive to input at the best of times which, when combined with the occasional popup overload from the firewall/whitelist combo, has resulted in at least one instance of my clicking the accept button without seeing what i was accepting.
• could i have saved myself some headache (and saved a bit of face) by using sandboxing? given the particulars of the system there's no way i would use a full virtual machine on it, and besides that would have been overkill for this application. it also would have interfered with the rather desirable behaviour of automatically launching the monitor UI (application virtualization wouldn't have been much better in that regard). that sounds like a strange thing for me to say, but the PC is so old that launching anything on it is painfully slow so the automated behaviour was welcome at the time. i suppose the fact that i never had any intention of hooking it up to my main PC (which actually has power running through it far more often) means that at some level i actually was using a sandbox of sorts - a physical sandbox machine if you will - but really, i trusted the software and had no reason to think i needed to run it in a sandbox.

trust seems to be the recurring theme here. i trusted the software. maybe i shouldn't have trusted it, but you can't get very far in computing without trusting at least some software, and there wasn't a compelling reason not to trust this software.

one thing to take away from this (or at least something that i'm taking away from it) is that a number of my security behaviours only help to protect me against the unknown. if i trust something, even though i'm wrong, there isn't much my defenses can do to help me. i will certainly be thinking about ways to overcome that weakness in the future.

of course, since i was behind a NAT-enabled router and wasn't forwarding port 7777 to the compromised machine, some of my defenses did work - but i was lucky. if it had been some other, more aggressive type of malware things might not have turned out so well for me. or, on the other hand, anything more than the passive listening for commands might have actually tipped me off to the presence of something malicious.

we can play "what if" until we're blue in the face - i've identified both the fact that my defenses have room for improvement and the nature that improvement must take. i've also been reminded that what they say really is true - it happens to everyone eventually. it took more than 20 years for me which is longer than most and i've been a little cocky about that, but in the end there's always some weakness, some way in, and if it hadn't been for my monitoring of security-related events i'd probably still be compromised right now. in the end the thing that helped me the most was my interest in security itself.

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.