100% virus-free... again...

well, the marketroids are at it again and this time they work for panda software:

SLA (Service Level of Agreement): 100% virus-free guarantee.

and

Together with quarantine management, this enables absolute protection against viruses, worms and Trojans. We are committed to offering a 100% virus-free service.

and once more for the trifecta

With respect to the antivirus filtering service, TrustLayer offers a 100% virus-free contractual guarantee.

y'know, if it wasn't for that 'absolute protection' bit (that sounds familiar), i might have believed they had the best of intentions at heart and simply meant that they'd give you your money back if they failed to keep the viruses out (not that that will necessarily compensate a business for the cost they'll incur when malware slips through and their guard was down due to a false sense of security)... not unlike the marketing message i knocked messagelabs for years ago (in fact, the service being offered doesn't sound fundamentally different either)...

even if i were inclined to believe they had the best intentions, the road to hell is paved with such intentions... consider how the message has evolved as it's traveled, first to yahoo finance

Panda Software guarantees that email filtered through TrustLayer will be 100% free of virus.

and then from there to the daily incite

What's old is new again. Panda guarantees 100% virus-free email. Join the club, the other email security services have been doing this for years. And how do you prove it anyway?

mike rothman at least knows to take this with a grain of salt but not everyone is as savvy - who knows what other paths it's taken and what false impressions it's given...

100% virus-free (aka 100% protection) are the magic words you do not say, it's the promise you do not make... this is why i distrust marketing: not only do they generally not really know they technology they're selling but, as this example indicates, they often don't know the business/industry either.... i've said it before, i'll say it again; 100% protection / 100% virus-free is the archetype for anti-virus snake oil and there really is no excuse for it anymore... somebody failed anti-virus marketing 101...

as always, vote with your wallet... if you want intellectually honest av vendors, market pressure is the tool you need to use...

and then hell froze over

anti-virus companies do not hire virus writers, if i've said it once i've said it a thousand times... oh sure, there was that one example where a company which wasn't even in the security industry (their main focus being graphics) hired benny (aka marek strihavka) to be the lead developer of their anti-virus software (which wasn't actually for public consumption at the time) because they felt he was reformed (even though he still makes viruses available on his webpage) and was then thoroughly denounced by multliple members of the av industry... then, of course, there's the case of sven jaschan who was hired by a security company - but again NOT an anti-virus company or even a company looking to make anti-virus software, so one could say that he doesn't count (especially since his hiring resulted in the company losing an av company it had hoped to partner with)...

it may seem like these violate the av companies don't hire virus writers rule but in reality these edge cases (neither company is technically an anti-virus company) actually reinforce the rule by virtue of what the av industry does in response...

so you can imagine, then, how far my jaw dropped when john sharp, founder of authentium, solicited applications from students who graduated from a virus writing curriculum:

Authentium to George Ledin's students: if you're interested in a job, we'll look at your resume. Based on your training, our assumption is that you're going to do a better job helping us detect and defeat malware than someone without this knowledge.

now, i realize one might argue that people who learned to write viruses in school don't have the same motives as those who write and release viruses (though it occurs to me that a virus writing curriculum would appeal to exactly the type of person who would write and release viruses so you may actually be dealing with a population whose bad apple content is higher than average) and the debate has been weighed in on by far more influential individuals than myself - but, with many companies refusing to hire such students just as they would virus writers, mr. sharp's words are unexpected to say the least... i wonder if he's shared his philosophy with helmuth freericks, who was listed as the vp of r&d at authentium when he signed the public letter against teaching virus writing that's being hosted by the anti-virus information exchange network...

things get more interesting than that, however... authentium's (formerly command software system's) command anti-virus used to license the f-prot scanning engine and given the identical naming produced by the two it seems like it still does... that engine is produced by frisk software international... frisk has made his feelings on the subject of virus writing curricula very clear, stating that it's ethically unacceptable, so it'll be interesting to see what if anything becomes of this if authentium really does hire students who've taken such courses...

when misunderstanding hurts you

today's post by tyler reguly about a revelation he found in f-secure's marketing message caught my eye because i think it exhibits some misunderstandings that i suspect are probably not unique to him so i'm going to try and clear up some of the confusion...

the statement that triggered all of this was that f-secure ships out around 6 updates per day... in tyler's words:

When you are pushing out that many updates it tells me one of two things. i) You are “sweatin’ the small stuff” or ii) You have a bad QA process and need to push out fixes.

he goes on to investigate whether there is enough malware to justify that many updates and finds that no-one is producing write-ups of new threats at anywhere near that rate...

the key misunderstanding here is what exactly those threat write-ups represent... they are not the only pieces of malware that the respective av companies encounter, far from it, they are just the ones that have distinguished themselves enough from the background noise of hundreds of pieces of malware being processed per day to warrant a write-up... nobody maintains a repository of malware write-ups equal in quantity to the amount of malware their product detects, that's just too much work for too little return, so they pick out the ones that are significant in some way such as ones that do something genuinely new, or ones that have in hindsight proven to be a slightly more significant threat than the vast majority...

notice the word hindsight... it is, unfortunately, not possible to predict which pieces of malware will make it big and which won't so it's not possible to use that as a criteria for issuing an update... technically sophisticated viruses have gone nowhere while barely functioning frankenstein creations have run amok... as such, all the anti-virus companies can do is try to minimize (within reason) the window of opportunity that a potentially significant threat will have... in fact, sometimes the failure to become a significant threat (certainly a desirable outcome) hinges on the rapid and widespread deployment of detection capabilities for it...

f-secure accomplishes this with around 6 updates per day... some companies ship updates hourly (and have been doing so for years now)... these aren't fixes (at least not generally), it's not a QA problem, there genuinely are sufficiently many pieces of malware being processed each day to warrant this update frequency... does that mean they're sweating the small stuff? maybe so but it's only because there's no way to know what's going to become big...

the slow death of someone's credibility

robin bloor doesn't show up on my radar very often, but when he does it always seems to be about how anti-virus is dead, dying, or doomed in some way... this time it's about the slow death of anti-virus technology...

dave lewis thought it worth pointing to (thus leading to the blip on my radar) and the folks over on the authentium blog went against their better instincts and actually responded to it...

it's a good response, too, and it touches on a point i've also made about whitelisting - specifically that the numbers of good programs (ie. those that would be put on the vendor supplied whitelist) far exceed those of malware... why this is interesting is because one of the main arguments against anti-virus technology is a fundamental disdain for enumerating bad things on the premise of it being too big of a problem... clearly, if enumerating good things is several orders of magnitude harder than enumerating bad things then this particular argument is garbage... it's nice to see that a whitelist vendor is owning up to the enumeration cost, even if some whitelist proponents are unwilling... to the unwilling i would say imagine if the TSA used a whitelist instead of a blacklist - do you think telling most people they can't fly because they aren't on the fly list would work better than telling a few people they can't fly because they are on the no-fly list?...

this time around mr. bloor wants us to believe that, because whitelisting is gaining traction in the market, his prognostications about whitelisting replacing blacklisting are gradually coming true... seemingly choosing not to consider the possibility that the trends he's noticed are nothing more than the maturation of the whitelisting market, and unperturbed by history's numerous examples of the av industry adding technologies to their portfolios rather than replacing the old with the new, mr. bloor's arguments seem rather ridiculous...

but then again, they're coming from the same guy who thinks traditional polymorphism and server-side polymorphism are comparable - that because traditional polymorphism (where the transformation function responsible for the polymorphism is carried with the self-replicating malware and therefore open to attack by the av'ers) has been around for 16 years that the av industry should have developed something capable of dealing with the newly emerged server-side polymorphism (where the transformation function isn't carried by the malware and thus isn't generally open to attack) by now...

so should anyone take him seriously when he says whitelisting is better than av and that it's going to replace av? no, because whitelists are not going to replace blacklists, whitelists aren't better than blacklists, they're just different from blacklists... whitelists don't have the same weaknesses blacklists do just as blacklists don't have the same weaknesses that whitelists do... the notion that we would or should use only one type of technology to protect ourselves from malware is antiquated and fundamentally broken - there is no silver bullet, no panacea, and if you don't employ a multi-layered strategy (aka defense in depth) then you're just setting yourself up for unnecessary failure... i have to wonder, when av technology is still here 10 years from now, will robin bloor be eating crow or will he still be forecasting av's death like some inverted version of monty python's parrot skit...

threat agents

one way to look at security is that it is (by and large) an attempt to prevent bad things from happening as much as possible (or at least as much as is cost effective) and to minimize the impact of those bad things that slip through... in other words, it's about preventing and/or negating threats...

but what is a threat, besides just a bad thing that could happen? the word threat is actually used in a number of different ways (and somewhat ambiguously) corresponding to the variety of ways threats can be classified/categorized... for example one can categorize threats by what's being threatened (ex. computers, networks, data, etc.), by what property of that thing is being threatened (ex. confidentiality, control, integrity, authenticity, availability, or usability), or even by the specific nature of how it's being threatened (ex. a DDoS attack, identity theft, etc)...

very often, however, the term threat is used to label the thing that is doing the threatening (ex. web-based threats)... despite being called threats, what these actually are are threat agents; that is they are agents that pose and sometimes carry out threats to whatever it is that is/was being threatened... usually, when something bad happens, something (some agent) caused it to happen so the obvious approach to preventing the bad thing from happening is to find some way to deal with the agent(s) that would cause it - in essence, addressing the security threat at the root, but in order to do that one needs to be aware of and consider the details peculiar to that type of agent, so . . .

at the most general level, the agents of concern in information technology are biological, technological, and environmental...

• biological
  for our purposes, biological threats are usually people... they can be other things, of course - it's certainly possible for other living things to cause undesirable events with security implications (be it a moth stuck in a relay, or animals chewing through cables, etc.) but usually it's people and those people are either internal or external to the organization interested in that which is being threatened...
  
  
  • external people
    these are almost exclusively blackhats, moreover they are people who start their attacks from the outside without any privileged access to the thing they're attacking... these could be crackers, virus spreaders, phishers, spammers, scammers, bot herders, or some other kind of malware profiteer... if they can be found, the law is generally the best (not necessarily the most effective, mind you, due to potential cross-jurisdictional complications) tool for eliminating the threat they pose...
  
  
  • internal people
    often referred to as the insider threat, these are people who do have privileged access to the thing being threatened (or at least to means by which that thing can be accessed)... the insider threat can take the form of either a malicious insider or a thoughtless insider...
    
    
    • thoughtless insiders
      the threat posed by thoughtless insiders is the threat of an accidental security breach... thoughtless insiders aren't trying to attack the system, they just forget to take the care they ought to take or just don't know any better... being insiders, they have privileged access to potentially valuable resources and are generally the only ones who can accidentally affect the security of those resources... because the nature of the threat is accidental, training is an obvious choice for dealing with the threat... though there are some dissenting opinions on the effectiveness of training, with the proper motivation (the stick is good, but it might be better with a carrot) suitable personnel should be capable of operating in a secure enough manner...
    
    
    • malicious insiders
      unlike thoughtless insiders, malicious insiders are trying to attack the system... these are motivated and often intelligent attackers who may (but don't necessarily need to) use many of the same methods that external people do... also like external people, the law is a good tool for dealing with them and there's the added bonus that being an insider should obviate jurisdictional complications...
  
  


• technological
  when i refer to technological agents, i'm referring to either software or hardware (the shades of grey in between those to are generally collapsible to one of those to, ex. firmware can be thought of as a special kind of software)...
  
  
  • hardware
    there is all kinds of hardware that could be used to affect the security of a system (ex. taking a sledge hammer to a computer is probably going to affect the usability of that computer and the availability of any data that was on it) there are some kinds of hardware that pose intentional threats to the security of your data/computer/network... examples of hardware that pose a threat to the confidentiality of data include hardware keyloggers as well as RFID cloning hardware or even TEMPEST hardware... whether or not the hardware agent requires some kind of physical contact, it is a physical thing that can be found and/or can be blocked in some way (be it an air-gap or some kind of shielding)...
  
  
  • software
    software agents are logical entities that (for the time being) generally can only directly affect other logical entities (ie. data)... they exist in some type of memory, whether it's RAM, the hard disk, an EPROM, or some other storage area, and can generally be located if one knows what to look for and the agent is in a state where it's incapable of interfering with that process... software threat agents can be further broken down into malware and other attack tools...
    
    
    • malware
      malware is a kind of malicious software agent that runs on the victim machine... the category can be subdivided into many different types (which i've tried to do and will eventually continue to do in my what is it series of posts) but for now lets just stick to self-replicating (viral) and non-replicative (non-viral) malware...
      
      
      • non-replicative malware
        non-replicative malware is the majority of what is being created and deployed right now... an instance of non-replicative malware is, by and large, an agent that acts as a proxy (not in the network sense, but in the more general sense) for the person deploying it - that is, it's carrying out that person's intent or acting for that person... for example, maybe they can't watch you log into your bank directly, but if they can fool you into running a keylogger or password stealer (or a dropper or downloader that in turn introduces a keylogger or password stealer) then that malware will watch you log in for them... as such, not only can we try to address the software agents themselves but we can also try to address the people responsible for them and hopefully eliminate them as a source of future malware...
      
      
      • self-replicating malware
        self-replicating malware (viruses and worms) can act as proxies for a human agent, just as non-replicative malware does... however, unlike non-replicative malware, self-replicating malware doesn't stop affecting new victims when the person who made/deployed it grows tired of it and moves on... instead, self-replicating malware just keeps going and going no matter what happens to the person originally responsible for it...
    
    
    • other attack tools
      not all software agents need to run on a victim's machine in order to affect security... mass mailers, password crackers, keygens, DoS tools, packet sniffers, and many others are all capable of doing bad things without running on a victim's machine and that means they can't be located and neutralized by the same means that malware can... generally speaking, dealing with the person who uses such tools (ie. external human agents) is probably going to be more feasible than trying to locate and eliminate instances of the software itself (though some anti-malware vendors have done an almost decent job of scaring people away from using many of these sorts of tools)...
  
  
• environmental
  environmental agents like fire, water, tornadoes, crashing vehicles, etc. are a little esoteric as agents go but they can affect data, computers, and networks, and not just their availability either... if a tornado tears through a building with confidential paper-based records, a hospital for example, those records may very well not stay confidential (it's raining medical charts!)... now for many other threat agents, dealing with them involved detecting/locating them and neutralizing the threat those specific agents posed (whether by changing, isolating, or eliminating the agent)... that also works for some environmental agents too (ex. you can detect a fire and extinguish it) but, as the tornado example indicates, sometimes you can't do anything to affect the agent (you may instead want to isolate the thing you wish to protect from the agent)...
  

(yes, i know i focused more on malware than anything else... i am a malware-centric sort of guy, after all... still, sometimes i like to think about the larger context and how malware fits into it...)

protecting data in use?

although lonervamp's blog entry on protecting data in use is not my first exposure to this concept, it does seem to be turning into a nucleation point for a discussion on the topic as both mike rothman and anton chuvakin have posted reactions to it...

for context's sake, usually when we're talking about protecting data we talk about protecting data at rest (which is when the data is residing in a data store/data repository/database) and protecting data in motion (which is when the data is traveling between the data store and an agent that consumes the data, be it a client application or a user of that client application, or potentially data traveling between 2 data stores)... when we're talking about protecting data in use then, we must necessarily be talking about data that has already reached the data consumer...

also, when we're talking about protecting data, we are at the very least talking about maintaining those properties of the data that are described in the CIA triad... but what specifically do we mean in the case of data in use? are we concerned about the data's availability to the data consumer once it's reached the data consumer? i would say no; in fact i would say that the data's availability at that point is not just a certainty, it's a tautology...

how about integrity then? surely we're interested in maintaining the integrity of the data once it's reached the data consumer? again i would say no... it is expected that the data consumer will transform the data in arbitrary ways (making integrity impossible to enforce) as part of the synthesis of new knowledge... we're interested in preventing the data consumer from writing corrupted data back into the data store, of course, but that isn't protecting the integrity of data in use, it's protecting the integrity of data at rest...

that leaves confidentiality... how many of you reading this think you can safeguard the confidentiality of data once it gets into someone else's hands?... we usually say that the genie is out of the bottle at that point, with the understanding that you can't put the genie back into the bottle... the technical preventative paradigm for protecting the confidentiality of data is access restriction, however you cannot restrict access to data in use as it is data to which access has already been granted... the notion that you can strictly control how the data is used by exclusively tying it to proprietary software and/or hardware is the very conceit at the root of DRM...

technical preventative controls that protect the confidentiality of data in use are impossible, but let me soften that a bit... i've heard it said that you shouldn't say "no", rather you should say "yes, but . . . ", and by being specific about technical preventative controls i have left myself room for a "yes, but . . ."... it is possible to protect the confidentiality of data in use by way of technical detective controls (ie. audit logging or perhaps some clever user-specific watermarking) and/or administrative preventative controls (ie. confidentiality clauses, termination policies, non-disclosure agreements, etc)...

people are generally not satisfied with this, of course, because they naively expect technology to be able to solve their problems completely (despite the fact that technology is notorious for only ever providing parts of solutions)... it's also unsatisfying because detection takes work and administrative controls have less of an air of perfection about them (not that any control is perfect, of course)... regardless of their satisfaction, however, data in use is fundamentally and irrevocably data that can be misused because it is data that is in someone else's hands...

economics of 2 factor man-in-the-middle phishing

by now i would hope that most people reading this blog are aware that 2 factor authentication doesn't protect against phishing...

over on the symantec security response weblog, zulfikar ramzan concedes very much the same thing, that man-in-the-middle phishing can compromise even 2 factor authentication schemes, but puts it into a broader context and states that the 2 factor authentication still changes the economics of the attack and effectively makes it less profitable...

you see, the world of cybercrime is one where information is frequently bought and sold and the one-time passcodes generated by security tokens used in 2 factor authentication schemes are supposed to prevent your credentials from being traded like a black-market commodity... as such, the theory goes that the phishers, rather than having a salable good that they can pawn off on someone prepared to actually use the information, are only able to access the compromised account login sessions directly and so have to be prepared to get their money from the victims directly... this is a riskier proposition and therefore seemingly less valuable to the phishers...

although it may seem like the credentials the phisher captures are useless for resale, i'm not entirely convinced they are - credential re-use being what it is and with the heightened sense of security that the tokens offer, i'm sure those usernames and passwords will often be useful on sites other than the ones using the 2 factor authentication systems... moreover, i'm not convinced that the economics of the attack are changed as much as one might think, or that there isn't a comparable salable good to be offered here... if pornographers can monetize live video feeds of young women in various states of undress then i don't see why phishers can't sell real-time access to the login sessions they've compromised, perhaps even by setting up their customers as mirrors for the phishing page(s) and using load balancing to direct the appropriate proportion of phishing page requests to those customers' mirrors depending on how much the customer paid (and those customers could in turn resell the sessions in exactly the same way their provider sells them)...

2 factor authentication certainly changes the phishing landscape, but to say that it will reduce profitability assumes the bad guys can't innovate (which is a pretty bad assumption to make)... one simply has to imagine new ways to do things, and criminals are already familiar with imagining new ways to make money...

mcafee's allysa myers on the wildlist

ok, not literally listed on the wildlist (though, as a wildlist reporter i suppose technically she is), but rather discussing the wildlist and making a good point that i haven't seen made before...

i've mentioned the wildlist before, and once i even mentioned some of it's limitations (such as not focusing on non-viral malware or the under-reporting of malware that is trivially removed by anti-virus software)... the limitations i mentioned before were pretty damning on their own, and should have been enough to make one question the relevance of the wildlist, but the point allysa myers made last week takes the cake...

the long and the short of it is that in the world of commercial malware the distinction between in-the-wild and zoo malware has been pretty much lost... unlike viruses back in the day, commercial malware doesn't get shelved once it's completed... it doesn't just get held up and studied like some intellectual novelty, or worn like a badge of honour amongst virus writers, commercial malware almost invariably gets deployed... that means people are going to encounter it in-the-wild (even if it never becomes widespread enough to make it to the wildlist)...

additionally, while myself and many others engaged in a protracted campaign to influence the vx community away from virus spreading and other behaviours that tended to lead to viruses finding their way into the wild, there is no real opening to do the same with the malware profiteers of today as there is no way (no work-around, no compromise that makes everyone happy) for them to achieve their goals without releasing the malware... so not only do they almost always release the malware now, they will continue to do so in the future...

so the question then becomes: if almost all malware is now going into the wild, what's the point of having a list of the malware in the wild? why bother continuing to make the distinction for such a subset if it's complement is so insignificant? maybe commercial malware hasn't completely overwhelmed the non-commercial variety (yet) but when it does (and i believe it must) i suspect the wildlist will have finally outlived it's usefulness...

understanding the malware threat of pirated software

recently both symantec and sophos have come out with statements to the effect that pirated software represents a security risk to users' computers and/or identities...

i haven't seen anyone crying FUD about sophos' claims (at least not this time, maybe next time) but mitchell ashley had some choice words about symantec's claims and, while i think i've expressed myself well enough in the comments to that post, the existence of that post and that sentiment makes me think some explanations need to be made more pronounced than they would otherwise be as simple comments...

the basic premise is that pirated software might damage users' machines or steal their identities... the way this would happen would be that the pirated copy of the software would have some malware type of functionality added to it or perhaps even be completely replaced with malware...

the question is, is that a credible threat and is there a good reason to mention it? if the answer to either of those is no then claims like those made by symantec really would qualify as FUD...

one of the oldest safe-hex tips was to only get software from trusted/official sources... this was to counter the major malware vectors of the day, which were warez (pirated software), bulletin board systems, and floppy disks... i personally have encountered a number of people over the years who ran into problems with malware precisely because they didn't follow this safe-hex principle and while floppy disks and bbses are all but extinct now, the warez scene is still around (otherwise we wouldn't be talking about software piracy) and so is still a viable malware vector... it's not an accidental malware vector either, as numerous virus writers and virus spreaders have in the past demonstrated how rich with computer using risk takers the warez scene is by targeting them and successfully spreading their malware... malware profiteers in today's commercial malware world would have to be short sighted indeed to pass up such fertile and proven ground...

of course, in the specific case being referred to by symantec, the users weren't getting their software from some warez site (at least not to their knowledge)... they weren't engaging in obviously risky behaviour, but rather they were purchasing the software from commercial pirates fraudulently posing as authorized resellers...

now you may think that the fact that they're commercial pirates that are in it for the money obviates the conventional warez-associated risks but let's look at that more closely... just because they're in it for the money doesn't mean they don't have other motives... in fact, if you were a malware profiteer trying to deploy bots (for example), why not devise a social engineering ploy that involved bundling the bots with seemingly legitimate software and enjoy the added bonus that you'd need to charge your victims money in order to make the legitimacy of the software believable?... additionally some of the employees of the commercial pirate organization may be disgruntled enough to tamper with the software or it may get contaminated accidentally - it's not like commercial pirates care about their falsified reputation enough to enable strict quality controls, if something goes wrong they can just blame the actual vendor... speaking of which, the software the commercial pirate is selling may not have come directly from that actual vendor but instead from a warez site with all the associated risks but none of the transparency about those risks that would allow the customer to gauge their risk exposure accurately...

so the threat seems plenty credible to me but still you might wonder whether it's worth it to mention the risk if there haven't been any actual reports of anything bad in the pirated software... if you're thinking like this then i can only tell you that you're thinking like a victim... in my experience victims usually think things are safe unless something specifically says they aren't... if you don't want to be a victim you need to turn that around and (as i'm sure robin bloor, marcus ranum, and many other anti-virus detractors/whitelist enthusiasts would suggest) start considering all software to be inherently untrustworthy by default unless given good reason to think otherwise...

how can you know who to trust?

there are a lot of conflicting messages out there concerning malware issues and so naturally one is faced with the question of who do you trust to give you the right information?... i'd like to say that this an easy question to answer, particularly because i don't have a big problem separating the wheat from the chaff... however, the fact is that i've spent years honing that particular skill and, with numerous examples of everyone from ordinary users to security experts choosing to either listen to or be people suffering from false authority syndrome, the evidence suggests that it's really not as easy as it ought to be...

with that in mind i thought i'd share my own mental processes on this subject in hopes that it might raise the bar, even if only a little bit... now i'm not going to just tell you to listen to the experts; for one thing that just shifts the onus on to how to figure out who's actually an expert or not, but also because that can be a little more exclusionary than it needs to be (for example, it excludes me, and if you shouldn't be listening to me then you should stop reading this)... here's what i am going to tell you, though - what to avoid and what to look for...

here's what you should probably avoid:

• famous people / big names - being famous on it's own doesn't make one smarter, it doesn't make one more accurate, more capable, or more in tune with the truth... fame is pretty much orthogonal to the truth...
• the media - their power to elevate the audience is matched only by their failure to do so... their job, ultimately, is to make their content look better/more important/more interesting than it is in order to sell advertising and thus make money... their is no motivation for them to present the unmodified / unhyped truth...
• vendors, or at least the marketing departments thereof - one need only search this blog for references to the term snake oil to see examples of why their words need to be taken with a grain of salt... marketing's interests are aligned with the company's interests rather than the publics interests...
• experts in some other field - though many experts seem to not be aware of this fact, expertise is non-transferable... you could be a genius when it comes to networking but that doesn't mean you know the first thing about malware...
• crowds - the wisdom of crowds is not universal, especially not where malware is concerned... in malware it usually turns into the wisdom of mobs, or digital maoism (to borrow a term from jaron lanier)...

all that being said, here are some of the things you should be looking for:

• relevant (malware-related) credentials - this means some kind of significant experience that's relevant to the field; maybe it's professional experience, maybe academic, maybe something else, but relevant credentials are the first and probably most important thing you should be looking for when trying to decide whether someone knows what they're talking about in this field...
• consensus with those who have credentials - just because someone doesn't appear to have credentials themselves, that doesn't mean they can't know a thing or two about the field... if what they say agrees with what those who do have credentials say then perhaps they do know something... this can be particularly significant when combined with past performance...
• past performance - if someone is right (or appears to have been right) most of the time about the subject then there's a good chance they'll be right in the future too...
• impartiality - all the credentials in the world won't matter much if someone has a vested interest that isn't aligned with the publics interests... the extent to which this matters depends a lot on the message; the easier it is to objectively and independently verify the information the person is giving, the less impact a vested interest can have...
• does it make sense - there comes a point where you'll have gained enough knowledge of the field that the idea being presented will just click and you'll be able to judge the message itself rather than having to worry about whether the person sending it knows what they're talking about and is impartial...

nothing is foolproof of course, even being an expert yourself won't guarantee that you are only trusting the right people...

(and now that i've written this, i suspect that it can apply to fields other than malware as well)

do we really need bruce schneier?

there's a sacred cow in security, a living sacred cow by the name of bruce schneier... a cryptography expert, a squid enthusiast, and a self-proclaimed media whore, bruce schneier is one of the biggest names in security and he's asked if we really need the security industry...

according to bruce:

The primary reason the IT security industry exists is because IT products and services aren't naturally secure.

naturally secure? my reaction to those words is much like peter lindstrom's reaction, it seems to mean perfectly secure without 3rd party assistance (ie. inherently invulnerable) but that's just absurd... i know perfect security is impossible, you know perfect security is impossible, and bruce better darn well know that it's impossible otherwise what good is he as a security expert?

his very next sentence reads:

If computers were already secure against viruses, there wouldn't be any need for antivirus products.

now here it's quite clear he's talking about perfect security against viruses... there's just one problem, viral susceptibility is inherent to general purpose computers - so long as you can share data and the device can do more than a handful of narrowly defined things it can support viruses... this has been known for over 2 decades, i've said it here many times in the past, i've even said it in the comments on bruce's own blog so it's not as if he's never been exposed to the idea...

a really telling quote is the following:

The whole IT security industry is an accident -- an artifact of how the computer industry developed.

this suggests that security is only needed because of accidents/mistakes that happen when designing and implementing systems... this is a fundamental assumption that few people in security these days seem to question... a vulnerability is often described as a flaw, mistake, or error in the code - but this is one of the most common misconceptions i see about the nature of vulnerability as it ignores the prospect of inherent vulnerability... everyone always says that things should be made secure from the beginning instead of bolting security on after the fact, but the only way to avoid needing to add security after the fact is if it was perfectly secure from the beginning and once again, that's just not possible, not just because it's so hard to avoid all possible mistakes but because some forms of vulnerability aren't the result of a mistake... take a website, for example - there can only ever be a finite amount of bandwidth available for hosting that website so it will always be possible for an attacker (or group of attackers) to use up all of that bandwidth irrespective of any mistakes in the website or webhost or network or browser or operating system or any other component even remotely associated with such an attack...

bruce wants to believe that eventually security will be folded right into the products (like the OS) and services (like the network connection) so that 3rd party security products become redundant... this is, at it's heart, the logical conclusion to where the best-of-breed detractors see things going - after all, if security functionality is going to converge into single integrated products, it might as well converge right into the products that security is supposed to be protecting in the first place, right? unfortunately there will always be new and as yet unheard of attacks (and even existing attacks are not completely obviated by even the best security) so products and services can never be naturally secure and it will always be necessary to bolt on additional security after the fact...

so the question is, has bruce jumped the shark and do we need him badly enough that we'll follow...

the effectiveness of user education

amrit williams has a post up about how ineffective user education is... if you've read this blog for a while you probably know how i feel about user education already but i guess there's more to say than to just point to anecdotal evidence of it working in real life (amrit does that himself with the example of his mother)...

so which is it? technological 'solutions' or user education, nature or nurture, particle or wave, fate or chance - to paraphrase forrest gump, it's a bit of both...

amrit is right that user education isn't going to make things secure, but let's look at that again - nothing is going to make things secure, not user education, not technological controls, not even a combination of the two... security isn't a boolean property, it's a gradient, talking about making things 'secure' is pure sophistry as we should be talking about making things more secure than they are right now... don't let the great be the enemy of the good; since perfection is impossible anyways one must settle for simply making things better...

in that vein user education has a rather well defined place... security requires intelligent, context-sensitive decision making that just can't be hard-coded into the system... i understand and appreciate that people are hard to control and generally unreliable... i understand why security folks would want to ignore the user problem since they're trying to build reliable security... unfortunately, whether we like it or not, users are a part of the system and they're always going to be a part of the system - technology cannot be an island unto itself, technological controls are just tools and users need to know how to use those tools properly or the tools themselves will be ineffective (just as knowledge without good tools is also ineffective)...

neither user education nor technological controls can reach their full potential on their own, they need each other if we're to get the most out of our attempts to make things more secure - and unreliable though that might be, it's better than relying on either individually...

malware will thrive in vista and whatever comes after vista

... and whatever comes after that, and whatever comes after that, and whatever comes after that, etc., ad infinitum...

so some experts are saying vista will have malware problems and a bunch of people are talking about it...

can an expert possibly tell me why this is news?

follow me on this one: we know that all general purpose computers (note the alternative) that accept new software are able to support viruses (something that's been known for some 20 odd years now)... we know that self-replication (the ability to make possibly evolved copies of oneself - the defining characteristic of viral malware) is not magical or special in any way so it's reasonable to assume those same general purpose computers will support non-viral malware as well... further, we know that a computer with windows vista loaded on it (or really, any computer with a range of functionality sufficiently broad enough to warrant ANY operating system) qualifies as a general purpose computer...

so the fact that vista will have malware problems shouldn't be news, it should be a forgone conclusion... just as the fact that linux can (and to a certain extent does) have malware problems, and mac os x can (and to an increasing extent will) have malware problems, and smartphones can (and to an increasing extent will) have malware problems should be forgone conclusions...

why has the industry forgotten this? why does the IT industry seem to keep forgetting the past? if it's not viruses then it's DRM or the finer points of key management or shannon's maxim... it's frustrating to watch a collection of supposedly smart people be so dense...

when is a bad test not a bad test?

when it's FUD'ing snake oil...

there have been a number of posts about anti-virus/anti-malware testing recently... even i posted about testing in response to what has become a series of posts about anti-virus testing over on anton chuvakin's blog (1, 2, 3, 4)... well this post is a follow-up because anton has managed to post the original test paper that his series of posts were based on...

to say that i was unimpressed would be an understatement... lets start with the number of samples - you may recall from my previous post that i said that the minimum number samples needed to account for the 2% detection rate that was being claimed was 50... according to the actual paper

Of the 35 malware files, three invalid files were removed from the sample set, leaving 32 malware binaries used in the final tests and performance calculations

so if only 32 samples were used, how is it that the lowest scoring product only detected 2% of the samples? detecting just a single sample gives a detection rate of 3%, not 2%, and all products tested detected more than just one sample... it can't be blamed on anton misremembering the figure he was told either, since the actual test paper states

the lowest was tied between ClamAV and FileAdvisor with a 2% detection rate

in one place and

two products tied for the lowest detection rate at 2%

thankfully the chart with their results clears this up - it's 2 raw detections (not a 2% detection rate) which means a 6% detection rate (which was also correctly reported in that same chart)... now, you'll have to forgive me for calling a spade a spade, but this level of mathematical incompetence (recognizing that you can't have a 2% detection rate with only 32 samples is grade school math and simply reading the column marked "percent" in a chart takes even less skill than that) is inexcusable for people who wish to have their test taken seriously... given such a complete lack of mathematical acumen, it's almost understandable that they failed to realize that a test bed of 32 samples isn't anywhere near large enough to give statistically significant results...

bias also figured heavily in the test... not only because they only used samples that got through the layers of protection already present on the systems they culled the samples from (thereby missing a potentially huge chunk of what's really posing a threat to users and irrevocably compromising the results and the integrity of the test itself), but on a deeper level the test was written from the perspective of an incident response technician... what is the perspective of an incident response technician? well these are the people who spend their days dealing with the after effects of the failure of security software and/or preparing for the next failure so as to make cleaning up after that event easier than cleaning up after the previous one... all they see are the security product's failures because that's their job, and if it weren't for the immutable fact that all security products fail they wouldn't have that job and they'd have to find some other form of employment (such as performing and publishing dubious tests)... just as police (who deal with criminals on a daily basis) are prone to developing an imbalanced view of society if they're not careful, so too are incident response technicians prone to developing an imbalanced view of the efficacy of security products if they aren't exposed to the security product's successes (which are generally invisible by design)... this acute form of perceptual bias taints the entire test at fundamental levels - including the design and methodology of the test (as evidenced by their belief that they need only collect samples that successfully compromised production systems that already had protective measures in place)...

so far these problems would seemingly be attributable to the testers simply being inexperienced and/or suffering from false authority syndrome... it's time to shine a light on a part of the test that can't easily be attributed to that... there was one product in the test that didn't do too badly - in fact it did better than all other products, it detected 50% more than the next best product, and it was one of the few products in the test that weren't used through virustotal... that product was asarium by proventsure (no link for reasons that are about to be made clear)... go and read the paper carefully (it's only 4 pages) and tell me if you can see something a little off about it... yes, that's right - the product that did the best, the product that was better than all others by a wide margin was the product made by the company whose president helped write the paper and is the contact listed in the abstract... the test, which is titled "Antiviral shortcomings with respect to 'real' malware" by gary golomb, jonathan gross, and rich walchuck, is NOT independent... one or more of it's authors has a clear vested interest in making one product look good at the expense of all others... this puts all the other problems with this test into a new and decidedly unfavourable light... the bad math, the sample selection bias, the insignificant sample size, etc. - in light of this revelation they all point to a cooked test designed to make all products other than asarium look worse than they really are (FUD) in order to make asarium look better than it is in comparison to them (snake oil)... the test, therefore, becomes little more than a marketing stunt by a disreputable company whose product should probably be given a wide berth...

and poor anton chuvakin - though widely regarded as a security expert, not only is he clearly not an authority on malware himself but apparently he also can't recognize a fraud/pretender when he sees one... that doesn't bode well for average folks' ability to do the same, does it...

defensive lines in end-point anti-malware security

some comments on my post about anti-malware tests have inspired me to examine what the various defensive lines are for end-point anti-malware security... this isn't going to include things like network intrusion detection/prevention systems because those are in the network rather than on the end-point...

as such, the first line of defense happens just as content is coming off the wire and into the system... this is before it gets written to disk (assuming the content ever does get written to disk, which sometimes is not a valid assumption) and is represented by things like exploit scanning network proxies (one might also consider the inbound traffic filter of a personal firewall as working at this stage of the defense)... i say this is the first line of defense because (assuming you have defenses here) this is the first one that malware would encounter when traveling to your system... this hasn't always been a defensive line however; before the internet became ubiquitous, malware tended to be passively shared either on removable media like floppy disks or over the telephone line when downloading from bulletin board systems - both of which happened to suit the second line of defense quite well...

the second line of defense (which used to be the first line of defense) starts just after content has been written to disk and continues for as long the content persists on the disk... this is traditionally the point at which new incoming materials would be screened against a blacklist (anti-virus product, generally)... content shared on removable media is suited to this defensive line because the media is just another disk to check... content shared via BBSes were similarly suited to this defensive line because the content had to be saved to disk before you could do anything risky with it (like try to execute it)...

the third line of defense happens just before the content is executed... this is where application whitelisting comes in (though on-access scanning with anti-virus will also trigger here since accessing the content is usually a prerequisite for executing it)... this of course assumes that the content is executable or otherwise interpretable in some way as instructions for the computer to follow (basically that it's some sort of program)... if not then it's not really malware (even exploit code is a program of sorts, though it tends to be executed in an unconventional way)...

the last line of defense happens after the content is executed... this is where behaviour-based protection (sandboxes, behaviour blockers, some/most types of HIPS, immunization, change-detection, outbound traffic filtering, etc.) comes into play, obviously, because at this point the defenses are looking for bad behaviour from the running programs... there's no later stage than while the malware is executing to prevent the malware from doing it's bad deed - if the defenses at this stage fail to detect/stop the malware's bad behaviour then prevention has failed...

the myth of meaningful informal anti-malware tests

bad tests are not necessarily a problem that is unique to the anti-malware field but it is one that those in the anti-malware community have encountered countless times... it's not that average folks are physically incapable of performing good tests, it's that they simply don't do it...

an informal test lacks strict adherence to established testing protocols, often because the standards set for good tests are so high that most people can't be bothered to go to all that trouble... only those who are dedicated to the process of anti-malware testing have ever done a half decent job of it because it requires a substantial investment of time and effort, not to mention a certain degree of expertise to ensure that the testbed is free of garbage/scanner fodder and duplicates...

i could stop there, i suppose, and hope that what i've said isn't too abstract, but i really object lessons and one sort of fell into my lap... dr. anton chuvakin has used the the results of one such bad test to support the now popular opinion that anti-virus is dead... i saw where this was going early on (the original question was obviously loaded)... i guessed the results would be bad and suggested the most likely reason was that the malware was too new - to which i was told that some samples were weeks old, though weeks can technically still be new enough if no one else has reported it yet... additionally, if a particular piece of malware isn't affecting many people the av companies may down-prioritize it in order to focus on samples that are affecting more people...

the test, as described so far, worked like this: someone who does incident response at a public university collected samples from compromised machines for a period of time and then when the batch was big enough (weeks after the collection was started) this person submitted them to virus total and took note of the results... the results were as follows: the best detection rate was 50%, the worst was 2%, and the average was 33%...

now, i can see a lot of problems with such a test but lets start with the big ones:

1. statistical significance - the sample size was too small... it may sound picky to those who want to believe, but even an unskilled labourer intuitively knows that asking 5 people their opinion on X does not give you a result that can be generalized to the entire population... this test (or at least the interpretation of it that we've been given) pretends to represent the ability of anti-virus products to protect against malware that is currently in the wild affecting people but most likely has a sample size of about 50 (50 is the minimum necessary for a product to get a 2% detection rate, but larger sample sizes make a perfect 50% detection rate increasingly unlikely)... since the wildlist has over 1600 different pieces of malware on it and since that only represents the self-replicating malware (which are believed to be in the minority now), a sample size of 50 (or even 100) just doesn't cut it...
2. sample selection bias - the samples came from compromised machines in a production environment... maybe that sounds reasonable to you but let me ask you this - if you test a variety of lie detectors against people who have proven themselves to be good at fooling lie detectors, are you really measuring how good those lie detectors are in the real world? the answer is no, you're only measuring how good they are against an artificially constructed set of people... the same goes for malware from compromised production machines - the malware you find there is the malware that has proven itself to be good at evading anti-malware scanners, not in-the-wild malware in general...
3. sample selection bias - the samples came solely from computers in an academic institution... sorry to say but universities are not a typical environment... if anything, they are the place where the incidence of truly malicious insider threats are the greatest (uni students practicing their l33t skills)... home users don't intentionally compromise their own computers, enterprise users may consider it (or even try it) but there are more/stronger controls in place (stricter logical access controls, more personally significant administrative controls, etc.) to prevent and/or deter it...
4. test-bed integrity - the test was carried out by incident response personnel... we really have no way of knowing how clean (in the sense of being free of detrimental garbage) the test-bed was... even if it was an incident response technician who was capable of reverse engineering each sample of malware (and had the free time in which to do it), simply reverse engineering the samples would not be enough to determine whether the samples were sufficiently different enough from one another to be considered distinctly different pieces of malware... and since many incident response technicians simply follow a script, there's a serious question as to whether all the samples really were malware instead of scanner fodder and whether any of them were duplicates...

now as i've already said, those of us who have been in the anti-malware community for a while have seen countless examples of these kinds of tests so we know to take them with more than just a single grain of salt... unfortunately the average person doesn't know why they should be wary of such tests and when security experts use these same sorts of tests to prop up FUD that scares people away from anti-virus products it doesn't help anyone... it's bad science and a doctor of physics should know better...

snake oil based lubricants should not be used with your browser condom

thanks to alex and paperghost for bringing my attention to the hilariously named browser condom...

browser condom is basically application virtualization/sandbox technology like sandboxie, bufferzone, and green border but something struck me about some of the quotes i was seeing, something distasteful...

right at the top of vappware's product page we have:

It's and advanced technology that allow you to run any kind of software in your computer without a risk of be infected with any kindof virus, spyware, trojan and any kind of malware. (VTD) , Virtually Transmitted Diseases.

are you thinking what i'm thinking? yes, apparently the folks at vappware are unfamiliar with the halting problem and it's implications with regards to any technology being able to stop all viruses (let alone all malware), hence i'm calling it snake oil...

now to be fair (who me?) it occurred to me that maybe i should take a look at some of the competitors to compare them to vappware with respect to snake oil and was disappointed to find that similar claims are made about both bufferzone (which boasts "complete safety") and green border (which "frees you from ever worrying about clicking the wrong link")... sandboxie was the only one i looked at that didn't seem to have such outrageous claims (or at least if they do have one it's not as easy to find)... sandboxie also seemed to be less flashy and more informative right off the bat, almost like they were hoping people would choose their free product based on it's actual merits (how refreshing)...

SSL: hot or not?

peter lindstrom made a post today about SSL that seems to have inspired a lot of discussion among other security bloggers...

one of the main contentious points made was that SSL prevents packet sniffing from being successful but since packet sniffing has never been a threat for websites there's little value there... here i would say peter is seeing the world through SSL coloured glasses in that he sees what the world looks like with SSL but not what it would look like without SSL... lori macvittie correctly points out that in the wireless world packet sniffing is a big deal however she underestimates it's significance to the wired world... dave goldsmith and tyler reguly both seem to recognize that in the wired world the absence of SSL would mean you have to trust every machine your traffic flows through, thereby creating a lot of potential for your confidential network traffic to be viewed by nefarious individuals, but apparently nobody questions the wire itself... the fact is that, other than SSL, there are basically no logical or physical controls either in the cloud (in the case of wireless) or on the wires coming out of peoples houses/businesses... without SSL these would undoubtedly be low hanging fruit...

i'm not going to go point by point as others have, instead i'm going to turn things around and look it from a different angle... the question that needs to be asked, that i think peter was trying to get at, is 'has SSL failed to protect our information (or at least the subset of which that travels across the internet to various websites)?'... the answer is yes it has, but not for the reasons peter seems to think... the reality is that SSL wasn't supposed to protect our information, that was never it's job, SSL provides a secure channel for communication between point A and point B... it has the potential to protect against one kind of attack, not all possible attacks - as peter points out there are other ways to compromise the data but that has nothing to do with SSL or it's ability to do it's job... SSL is part of the puzzle, not the entire thing, and that is why it has failed to protect our information in transit...

there are 2 main avenues of attack that SSL is powerless to prevent: compromise of the end-points and impersonation of the end-points... if the client-side end-point (ex. your computer) becomes compromised (ex. perhaps by malware) then the data that is being sent over an SSL channel can be captured before it gets encrypted and sent to a malicious 3rd party... if the server-side end-point (ex. the website) becomes compromised (ex. again perhaps by malware, or perhaps by some malicious or neglectful person who works for the company that runs the website) then that same data that was sent over an SSL channel can be captured after it's been decrypted at the other end... this is a hard problem, one that a lot of research has gone into over the years and even after all that time there still isn't a perfect answer - and there may never be one... at any rate, preventing the entities at either end of the secure channel from doing bad things with the data is outside the purview of SSL...

likewise, preventing entities that are trying to communicate from establishing a secure channel with the wrong entity (as in a man in the middle attack) is also outside the purview of SSL... SSL makes sure the data is encrypted when it leaves your computer and decrypted when it gets to it's destination... your browser makes sure that destination is who they claim to be (checks the site's certificate) and warns you before establishing the SSL session if that doesn't seem to be the case... what nobody checks is whether the 'who' that that destination claims to be is the same as the 'who' you were trying to communicate with... just because i am who i say i am doesn't mean that i am who you were intending to contact or that i am trustworthy in any way - the fact that extended validation certificates exist at all underscores how meaningless regular certificates have become due to them being handed out too freely... EV certs aren't really going to solve this problem, by the way - as i've written before people just don't notice when things are missing, they don't verify that the cert is the right one for the site they intended to visit, and the computer can't really do that verification for the user (at least not in general)... there has to be some way for the points at either end of a secure channel to authenticate themselves to each other or else you can't know that the channel that SSL is securing is the entire channel involved in the communication... this is also a hard problem to solve, but it's a little better defined than compromised end-points...

so is SSL useless because it doesn't solve these parts of the problem? no, we're definitely better off with SSL than without - but at the same time there's still a lot of the puzzle left to be solved so the information we're sending across the internet is not yet secure...

more mobile malware madness

y'know, there are times when i'm not really a big fan of repeating myself (like when it comes to garbage masquerading as insight) but when a supposed top security [/straight face] influencer [straight face] takes a piece of techdirt trash at face value (what's next? will we be citing crackpot, errr, slashdot as an authoritative source?) what's a malware guy to do?

(if this is sounding angry it's because i finally had to unsub from techdirt a little while ago after discovering how inaccurate it is even outside the malware field)

taking the false claims and misrepresentations from the top:

1. f-secure spreads mobile malware FUD - see my previous post on the subject...
2. kaspersky spread FUD about the mobile malware threat - in the original article the kaspersky folks make it clear that you may well not be very likely to see mobile malware in your home country... the dependence on the regional market penetration of susceptible devices (smart phones) on the extent of the risk has been well established..
3. kaspersky took a news crew into a faraday cage in order to make them understand that mobile malware was a real threat - no, they took them in the faraday cage to demonstrate how cabir works...
4. cabir is only a threat when you intentionally ignore the warnings - this is the oft cited yes/no prompt that people consistently think should mitigate the mobile malware threat even though it has been well established that the 'no' button doesn't work (the worm just sends itself again immediately so the prompt comes back as soon as you hit 'no'... if you need to make a phone call your only real options are to hit 'yes' or get out of range of the other infected device because you can't use the phone while the prompt is there)...
5. kaspersky has suggested that mobile malware is common - again, read the original article, you'll find they don't make that claim at all... they do say that there are certain geographic locations where it's more common than others, though...
6. kaspersky could have just found someone with the virus instead of taking the news crew inside a faraday cage - yeah, an anti-virus company is going to demonstrate the functioning of a piece of malware that is epidemiologically equivalent to an airborne biological pathogen without the protective measures necessary to keep it from spreading beyond their control... now pull my other leg...

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...

there's more to security than just prevention

thanks to richard bejtlich for drawing my attention to this (because i find dark reading to be impenetrably dull)...

it appears that joanna rutkowska is trying to get the message across that there's more to security than prevention, that there's always some way around preventative measures and so you have to worry about detection as well... i can't pass up the two-fold irony here... first, joanna became a household name in security precisely because of her claim of making 100% undetectable malware, which should mean that focusing on detection is wasted effort... second and regarding the same claim, her undetectable malware is implicitly preventing detection... if she wants to bang the drum of no perfect prevention then more power to her, but she's going to need to eat her own dog food, as the saying goes...

richard echoes her sentiments though, and although there's a really good reason for all the focus on prevention (come on, say it with me now, an ounce of prevention is worth a pound of cure) i'll chime in with my own support for them too... security doesn't start and end with prevention (well, it might start there, but it definitely doesn't end there)... all preventative measures fail under some circumstances so it becomes important to try and detect preventative failures... i've written about the limits of prevention in an anti-virus context before (what i wrote applies equally well outside of the malware field) and when i did i made it clear that security doesn't end with detection either... it's all well and fine to detect a preventative failure, but then what?... after detection comes remediation - when you've discovered that your attempts to prevent bad things from happening have failed then you need to remedy the situation... in security one often will hear of the CIA triad; confidentiality, integrity, and availability are all things that security aims to maintain... well prevention, detection, and remediation form a triad too - they're the stages one goes through in the process of trying to protect something...

at this point you might be thinking that if security doesn't end with prevention and it doesn't end with detection then it must end with remediation because there aren't any elements left is this triad... one would be wrong for thinking that, however... remediation feeds back into prevention - since you don't want to have to keep applying the remedy over and over again you need to augment the preventative measures to help prevent what you failed to prevent before... prevention, detection, and remediation are a 3 stage cycle; they keep going indefinitely and each pass through the cycle makes security a little bit better/stronger....

operation spamalot

first off, yes it really is called (or at least code named) operation spamalot... though some might be tempted to say that someone somewhere has a sense of humour because of the apparent monty python reference, the fact that the term spam itself comes from a monty python skit means that the humour in the name operation spamalot is not very creative...

that said, i think it's kind of interesting that the SEC has decided to halt trading of companies that have been the subject of stock spam... interesting in a 'how many ways can this go wrong' sort of way...

over at the securiteam blog, aviram points out one way this could go wrong - a company's competitor could send out fake stock spam (fake in the sense that s/he's pumping without dumping because s/he has no actual shares) in hopes of getting the trading of the company's stock to be suspended, therefore benefiting the competitor...

let's extend that a little, though... what if a company's competitor sent out real stock spam? then, no matter what the SEC does, the competitor comes out ahead... if trading for that stock is halted it's just like the previous example, otherwise the competitor makes a nice profit when s/he dumps his/her shares...

how about a third possibility... what happens when the stock spammers in aggregate are spamming so many different stocks that halting trading of them all would hurt the stock exchange?

obviously something has to be done, but such draconian measures seem like they're probably going to fail in the end... aside from the fact that our inboxes get deluged with the stuff, isn't the key to the stock spammer's success the fact that the recipients are purchasing the stock in ignorance (rather than just the fact that the stock is being bought)? couldn't that ignorance be addressed? couldn't the folks buying such stocks get a warning about the fact that the stock has been spammed and that if they're buying it purely on the word of some email they received they may be being deceived?

oh well, it's probably too much work for them, but it does serve as a pretty good bit of advice (i hesitate to call it safe hex) - don't buy a stock just because an email told you it was a good buy... emails out of the blue that give you accurate stock advice falls under the heading of too good to be true...

what is stock spam?

stock spam is a form of spam intended to 'sell' a particular stock that the spammer has already invested in so that the price will go up and allow the spammer to sell his/her shares at a profit...

otherwise known as a pump and dump scheme, stock spam is unusual compared to more conventional forms of spam in the sense that there is no need to show the recipient a URL or clickable link of any kind... there is no specific vendor site which you need to go to in order to buy the stock, the spammed stock is bought where any stock is bought... this makes stock spam a prime candidate for being implemented as image spam since the image spam's lack of a clickable link won't have any negative effect on the stock spam's success...

another difference between stock spam and regular spam is that stock spammers are rarely operating on behalf of the company whose stocks they're pumping... in fact, pumping and dumping can hurt a company's stock so the companies whose stock get spammed by a stock spammer are just as much a victim of the stock spammer (if not more so) than the spam recipients...

back to index

what is image spam?

image spam is a form of spam where the contents of the spammed email are generally little more than an image file containing an advertisement for the product being spammed... often such emails don't even include a clickable link to follow to get to the vendor's website in order to buy the product - instead they contain a url in the picture that the recipient then has to type into his/her browser in order to get to the vendor's site...

a large amount of the spam seen lately is image spam... martin overton has posted about it on a number of occasions on his blog and this post on spam in particular shows multiple types (i think the ransom note format is rather humourous) though a lot of advancement has been made in spam obfuscation since even that short time ago...

the basic premise behind using images in spam instead of normal text or html is that it makes it much harder to analyze in an automated way... essentially, it uses the principles of CAPTCHA in order to foil anti-spam technologies... it used to be that an anti-spam technology would simply look at the contents of an email to tell if it was spam or not, but with image spam it becomes necessary to create software to extract the text from an image (often a distorted image) before those contents can be analyzed and what makes CAPTCHA work is that that's not easy for a program to do...

this isn't the first time such dark implementations of CAPTCHA have been seen... certain email worms have used it in the past in order to foil automated email scanners (the worms sent themselves in a password protected archive along with an image containing the password - and yes, even with all the hoops one would have to jump through in order for such a scheme to be viable, a number of those worms were successful)...

back to index

what is an email worm?

an email worm is, predictably, a type of worm that spreads over email...

email worms are perhaps the most well known type of worm since most people have seen more than a few of them in their email... in fact, during the peak of an email worm's population growth, some people have been known to see thousands of samples of a single worm in their email...

often email worms send themselves as email attachments to their victims, leading to a general rule of thumb that instructs users to be cautious with unexpected email attachments (as well as technology to strip out email attachments if they conform to one of a list of known executable file types)... there have been some email worms (such as vbs/bubbleboy), however, that have been able to spread inside the body of the email instead of as an attachment, so just looking out for email attachments isn't necessarily enough when it comes to email worms....

email worms, like all computer worms, are just programs and as such need to be executed before they can do anything... at one point email worms used any number of exploits to get themselves executed automatically as soon as the email was opened in a vulnerable email client (such as outlook or outlook express) or sometimes even as soon as you simply selected the email in the list (if you had the preview pane turned on)... many such vulnerabilities have been fixed and the option to view emails as plain text instead of html (since html rendering of email was often required for the exploits to work) has grown in popularity, but so to has the use of social engineering in order to trick the user into executing the attachment - and that still remains effective to this day...

back to index

security tokens don't protect against phishing

you never know when you're going to come across a train of thought so thoroughly wrong it deserves to be debunked... that's what i learned today (hey, i haven't gone to sleep yet, it's still officially today) when i read david maynor's blog entry where he mentions thinking that with a paypal security token he won't have to worry about where he enters his paypal credentials anymore...

gold star if you're shaking your head just thinking about that... security tokens, generally part of a 2 factor authentication system (where you prove who you are using something you know, like a password, and something you have, like a token), won't protect you against phishing - at least not completely... the simplistic phishing attempts that we're familiar with right now would be thwarted by 2 factor authentication but not only can the practice of phishing adapt to 2 factor authentication it's already started to do so...

phishing schemes using man-in-the-middle attacks have already been spotted in the wild and some specifically support 2 factor authentication...

the reason phishing is possible is the same reason man-in-the-middle attacks are possible - one end of the communication (in this case the phish site) hasn't been authenticated... you can strengthen your own authentication until you're blue in the face - even 3 factor authentication won't help you if you don't know for sure that the person you're talking to really is who they claim to be...

site authentication is a hard problem, though, a lot harder than people give it credit for... as i've said before, site authentication schemes that work by placing something on an authentic site to prove it's authentic won't work very well because we just aren't all that good at noticing when something is missing (which it theoretically would be for a fake site)... i also don't understand what's so special about things like site authentication images that prevents them from being spoofed by a man-in-the-middle attack as well - the attacker's system should be able to pull the proper image from the real site so long as it sends the same identifying information to it that the client normally would have...

sender authentication isn't quite as hard a problem, though... perhaps david should read my post about avoiding phishing emails the easy way so that he can harden up that soft spot he has for paypal phish...

what is a man-in-the-middle attack?

a man-in-the-middle attack is a type of attack where the attacker tricks both sides of a 2-way interaction into believing s/he is the other entity in the transaction...

for example in a man-in-the-middle attack, you might think you're talking to your friend bob when in fact you're talking to mallory who then passes on what you say to bob... bob in turn thinks he's talking to you but in fact is also talking to mallory who then passes on what bob says to you... mallory gets to see both sides of the conversation and even has the opportunity to subtly change it for some nefarious purpose, perhaps to make bob mad at you or something...

there are all kinds of contexts where man-in-the-middle attacks can be useful to an attacker - in simple terms they allow an attacker to gather data sent over what was believed to be a secure channel, whether that data is login credentials for a bank or encrypted web traffic sent to a secure site, and possibly even inject their own messages (such as a financial transaction) into the communications... the channel may even be secure in and of itself, but the problem is that the party at the other end isn't who they claim to be... securing the channel over which communication occurs doesn't secure the communication unless you also authenticate (make sure they are who they say they are) the parties at both ends of the channel...