the problem with the "like" trade

earlier today randy abrams posted an interesting take on facebook advertising and how misleading the word "like" can be (http://randy-abrams.blogspot.com/2011/12/facebook-misleading-advertising.html). this reminded me of a beef that i've apparently had going back at least as far as may of this year (judging by the timestamp on the screenshot i took).

specifically, randy said the following:

If I have to “like” a page to get the information I want, I don’t have a problem with that

well, with all due respect to randy, i do have a problem with it. randy makes some good points about the way people's pictures get used in facebook ads when they "like" things, but a point he neglected is that forcing users to "like" or otherwise post about something before they can see the content they've been lured with is a popular tactic in facebook scams.

now, i'm not trying to suggest that security companies making use of this marketing methodology are scam artists (though i am tempted to say that all marketing is in some way a scam) but they should be aware that by utilizing this sort of marketing they are effectively endorsing a marketing methodology (developed by facebook) that breeds victims. i don't expect facebook to care about such things, since such trickery is how they make their money, but i certainly expect security companies (especially ones with as strong a leaning towards empowering users as eset) to know better than to go along with facebook's questionable methods and do things like this:

"like"s are not something to be bought from users in exchange for free or otherwise tempting content. they are an endorsement and as such can't be legitimate until after the user has sampled the content. the idea of exploiting illegitimate user endorsements should be recognized as unethical and should be understood to have consequences. by using the sort of techniques that scam artists thrive on, one is basically training people to be victims. i expect better from security companies and i think you should too.

whitelist opinion smackdown

i realize i've been rather quiet as of late - not sure why, perhaps i lost my mojo... anyways, you can all thank cdman for rousing this ogre out of slumber...

in a recent post, cdman lays out his response to randy abrams' post on whitelisting... perhaps it was the hint at the possibility of an ad hominem attack against a fairly well known and long-standing member of the av community (randy was, for a long time, the voice of av from within the belly of the beast - aka microsoft) that piqued my interest, but that wasn't cool so let's move on...

cdman's first substantive beef is the suggestion that whitelisting companies can't do their job without anti-virus software... ignoring the fact that in practice this is actually true (whitelisting companies currently depend on anti-virus software to determine if something is safe to add to their whitelist) lets look at the hypothetical alternatives he suggests - specifically that whitelist vendors could rely on reputation or building the generic malware equivalent of marko helenius' automatic and controled virus code execution system...

relying on reputation offloads the problem of keeping bad software off the whitelist onto the very people providing the bad software... sure people who provide bad software consistently will get a bad reputation and not be trusted, but what about people who only do it once in a blue moon? microsoft releases tons of legitimate and safe software but they have on occasion also distributed virus infected materials... you'd be hard pressed to justify not whitelisting code from microsoft if you were relying on reputation but if you did whitelist all their code you would eventually whitelist something you shouldn't have... furthermore, relying on reputation is precisely the method that customer-generated whitelists are primarily made with, which would make a vendor-generated whitelist using the same technique rather pointless...

next is the idea of building a system to automatically execute samples and perform baseline comparisons to see if the sample compromised the system... and of course this has to be done on a scale sufficient to handle the rate at which sample files are produced (otherwise whitelist vendors wouldn't be able to keep up, much like av vendors supposedly aren't able to)... but have you looked at bit9's (a whitelist vendor) figures? av companies already augment their small armies of malware analysts with automated methods of determining what's bad, and old methods like this are almost certainly among them... if the av vendors can't keep up with the malware then what hope do whitelist vendors have in keeping up with the goodware when it's production rate is (necessarily) several orders of magnitude greater than that of malware? there are all kinds of capabilities peculiar to traditional av companies that whitelist vendors could try to replicate in-house, but the scale of the samples they have to deal with make it impractical for them to do anything other than to replicate the blacklisting capabilities in full in-house and that would mean they would still be using what the general population considers av - it would just be their own...

a third option cdman mentions is using technology like that developed by mandiant... whitelist vendors are unlikely develop such capabilities in-house when it's almost certainly cheaper to buy products/services from others who've already developed those same capabilities, but lets hope in this case they stay away from such ethically questionable companies as mandiant... bad enough that mandiant hires people whose marketability in security is thanks in no small part to their past efforts at making the problem worse, but to then turn around and have some of those same people do essentially the same thing in the company's name at an event like race-to-zero smacks of not just some lapse in HR's judgment but rather of an alignment of moral compasses... perhaps i'm in the minority here, but if a whitelist vendor gets in bed with a company like mandiant i wouldn't touch them with a 10 foot barge pole...

second to the beef about what whitelist vendors would do without av software was cdman's beef with randy's understanding of what actually constitutes a whitelist... i have to admit that my first impression on reading the statement that the TSA implements a whitelist was one of confusion... the most widely known (and reviled) measure the TSA implements is the no-fly list, which is fairly obviously a blacklist... i actually left a comment on randy's original post expressing my confusion but literally as i was writing it it dawned on me that there were other measures implemented by the TSA such as the newly revised rules for flights which basically require one to be granted permission in a 2-stage process before you can fly... of course, as i write this i'm reminded of the various trusted traveler programs that schneier has written about on occasion - those are also whitelists...

despite all the disagreement, though, in the end cdman and randy are actually in agreement about the role of whitelisting - it's simply another layer... both think it's got it's strengths and it's weaknesses, areas where it's more applicable than others, etc.. however, i think randy has once again distilled a complicated topic to a simple analogy when he compares the folks who say whitelists are the end of av with airbags calling seatbelts obsolete... what a clever way to say they're full of hot air...

recognizing social engineering - part 1

randy has a timely post over on eset's threatblog about the likely event that anna nicole smith's death will be used by the black hats in a social engineering ploy... it's really a very classic example of how significant media events can be used to fool people into installing malware... as such i thought i'd take the opportunity to generalize a way of detecting some kinds of social engineering - not all kinds, mind you, this won't include HP's pretexting or anything like that, just a classic broad category that randy's hypothetical example falls into...

the sorts of emails that randy describes are those that would appeal to our idle curiosity - we don't care enough to go and look for the info or pictures but if those things come to us then our curiosity can be satisfied... at a fundamental level this boils down to the principle that if something seems to good to be true then it probably is... this is not to say that the death was a good thing, but having answers to questions you never asked (such as what are the details of a now dead celebrity) magically appear in your inbox without any effort on your part is just too good to be true...

emails promising racy pictures of anna kournikova are similarly too good to be true... then there are emails promising information about the recent storms in europe, also too good to be true... emails from microsoft with a critical security patch attached? too good to be true.... emails with the subject line i love you? well the romantic in me doesn't want to admit it but with no evidence to the contrary it's probably too good to be true too... all of these are examples that have been used to spread malware...

good things don't just turn up in your inbox without you asking for them or searching for them or otherwise putting in some kind of effort to get them... the world doesn't hand us our every whim on a silver platter - that's basically what would be going on if things we were even mildly curious about just (supposedly) showed up in our inboxes for no good reason... so next time you're looking through your unread messages (or anything else, for that matter) and you get that "hmmm - that looks interesting" feeling come over you, think about the too good to be true principle and ask yourself if the object of your interest qualifies... ("if the bait looks obvious, don't take it")

ZERT's 3rd party VML patch

ZERT, short for zero-day emergency response team, have released a patch for the microsoft VML vulnerability that has been recently uncovered and exploited...

there have been 3rd party patches in the past (the WMF one being a prime example) but the significance here is that an organization has formed (with an impressive set of members) specifically for the purpose of releasing 3rd party patches to vulnerabilities that are exploited before a patch is available from the vulnerable software's vendor...

i've mentioned 3rd party patches before and why they're needed (because certain vendors don't do enough to shut the window of exposure quickly enough)... i thought they were a good idea and i think they're an even better idea now... rumor has it that microsoft may release a patch for the VML vulnerability out of cycle (before the 2nd tuesday of next month) but this rumor only seems to have surfaced after ZERT released their 3rd party patch... furthermore, another rumor has it that microsoft was/is considering releasing an early patch for their onecare customers (which just goes to show what i said before about their being no moral high ground for microsoft in the security industry is proving moot because they clearly have no interest in the moral high ground)... i have no idea if the 2 rumors are related, but regardless of that it seems to me that 3rd party patches may serve to help keep microsoft honest in a way that full disclosure was supposed to do...

i can't mention ZERT's VML patch without drawing attention to what randy abrams has written about it, though... in spite of being a member of ZERT, he wisely posts words of caution over the use of their 3rd party patch that basically boil down to this: most people don't need or use VML in the first place and so the existing workaround of disabling it is a better option than the 3rd party patch under those circumstances - you should only need the 3rd party patch if you really need the vector graphics (not just regular graphics, mind you) rendering engine to operate, and then you should only need the 3rd party patch until the vendor releases their own patch... that's good advice and i think it can probably be applied to 3rd party patches in general, not just this one...