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

are we winning, or losing, or have we already lost

a popular refrain from security folks these days is that we, the good guys, are losing or are fighting a losing battle... occasionally someone will say that we're actually winning, and others might even say that we've already lost...

all of these are wrong and here's why...

for starters let's look at what it means to win... what end results in security would indicate that we have won? naively, if we no longer had to think about security, if we could just set our security mechanisms and then forget about them and remain secure from there on out then we'd have won conclusively... that's not very realistic, however... how about instead if we continue to work tirelessly to keep things secure and in so doing are able to foil every attempt at breaching the security we've set up, every attempt at compromising the information we're protecting or exploiting the resources of our endpoints? that too sounds like a pretty conclusive win, however if we were able to take the possibility of mistakes and bad security decisions out of the equation like that then it's quite likely that the security decision making process could be replaced with an algorithm, which brings us back to the set and forget security mechanisms...

how about losing - what would it mean to lose? again naively, if our security failures become so bad that we are forced to just throw up our hands in defeat and stop using the technological resources we've been trying to secure then that would be a clear indication that we've lost... alternatively, if we continue to work tirelessly to keep things secure but fail most if not all of the time then that too would be a pretty obvious case of having lost... of course if we fail all the time, or most of the time, or even just enough that the value of our technological resources is no longer greater than the cost of our failures then, barring blind faith, it stands to reason we'd just throw up our hands in defeat and stop using those resources - so again it collapses to a single indicator...

neither of these sets of outcomes seem very likely... we're always going to have successes and we're always going to have failures... we're always going to have to keep working at security - and, because it's going to continue indefinitely, the very notion of winning or losing in the larger context of security as a whole is as meaningless as winning or losing at life... individual successes or failures cannot translate into winning or losing on the whole anymore than having a good or bad day translates into winning or losing at life... security isn't a game and it's not a war, both of those things eventually end and security doesn't... whether you win or lose an individual battle (or many of them), the constant struggle that is security (like life) goes on...

and for those who decry the perpetual cat-and-mouse game we seem to be in and hold that up as proof that we're losing (or have already lost), consider this: if there is no perfect security (something many take to be axiomatically true) then we can conclude that for every measure there exists a counter-measure... since counter-measures are themselves measures we can conclude that for every counter-measure there exists a counter-counter-measure, and so on and so forth... given that (somewhat inductive sounding) conclusion, the cat-and-mouse game is the only feasible outcome - one or both sides would have to be either too stupid or too lazy to find/use the counter-measures available to them for it to have turned out any other way...

snake oil from agnitum

how do i put this succinctly without seeming overly personal? folks, stop and think about how you're using the P word... which word is that? well, take a look at this agnitum blog post and see if you can figure it out:

First of all, why did we decide to add total malware protection to our core firewall product?

hmmmm, was it product? no it was protection, specifically total malware protection... i've said it before - the unqualified use of the word 'protection' is bad enough but to qualify it with a word like 'total' implies something about a product that just is not (and cannot be) true...

don't get me wrong, i know what the intended meaning of total malware protection is (it's supposed to mean that it offers a degree of protection from all types of malware, not all instances of it) but anyone who sits down and thinks about how the average person (with no knowledge of the malware field) will interpret that phrase should realize that average people will not understand or even conceive of that intended meaning... you know what they might understand though? that it's comprehensive, that it has full/total/complete coverage, or simply that it handles all types of malware... if you're going to write marketing material make sure you thoroughly consider how the average person thinks...

now at this point you might be thinking there goes kurt picking on the smallest little slip-up again, but there's more... snake oil isn't just about making outrageous claims, another hallmark of snake oil is the unthinking use of jargon... consider the following:

Using award-winning VB100 technology licensed from a leading malware expert

now i ask you, what is VB100 technology and what awards has it really won? actually knowing what you're talking about is a good first step towards not sounding like a snake oil peddler and that means knowing that VB100 isn't the technology but rather the award... maybe it's a grammatical slip-up by someone for whom english isn't their native tongue, but if so it stands in stark contrast with what is otherwise excellent english prose...

and yet there's still more... i understand they're licensing anti-malware technology from a vendor whose won the VB100 award but who is the vendor? wouldn't that be a good thing to tell people? wouldn't it be nice to be able to verify that that vendor actually won the VB100 award rather than taking agnitum's word for it? wouldn't it be nice to be able to look at the VB100 history to see how often the vendor won the award (since that is where the real significance of the VB100 award lies)? i mean really, if the vendor's engine is so great then the name should engender consumer trust, so why be obscure by basically referring to it as an unnamed award winning technology? what is there to hide?

you know what's really sad though? from the description it actually sounds like it's a pretty good engine (detection of all malware types integrated into a single light-weight client process) that really deserves a higher standard of promotion...

google search malware warning update

i wrote before about google's efforts to warn users of their search engine when visiting known bad sites and i had a number of concerns about how it had been implemented...

it appears that somewhere along the line ALL of those concerns were addressed... as you can see below, not only was a backlink added so that users could back out of going to the bad site but the mal-link itself has become non-clickable (a user would have to copy-n-paste the url into a browser window in order to continue to the bad site)... as such they've now made the safest option the easiest option...


but wait, that's not all... they've also gone and marked up the results page itself so you know right from the results page if a particular link is bad or not...


did my previous post on this have anything to do with getting these changes made? probably not, but that's not what's important... what's important is that the changes were made and the feature is a lot safer (and more convenient) because of it...

security catalyst's first q&a podcast

now i want to start of by saying that i don't often listen to podcasts, i don't multi-task all that well and need to just sit there and listen to a podcast in order to really absorb the content so they're really not very helpful to me per se... there are also usability issues with podcasts - you can't quickly scan through a podcast to save yourself time, you can't easily stop it and go back hours later without starting over (in part because you can't scan over the part you've already heard to reacquaint yourself with the context), and you can't easily quote/refer to/respond to a podcast...

that said, the security catalyst's first security podcast q&a caught my eye because the supporting summary information (which is a great thing to include with podcasts, by the way, and i wish more people did that) indicated that there was anti-virus material being covered and so it would probably be of interest to me... i also noticed some odd inclusions and omissions in the recommended links, but i'll get into that later...

the first thing that struck me about the anti-virus portion of the podcast (which starts about 25 minutes in, by the way) was that michael santarcanjelo and adam dodge got the overall answer right - as far as detection rates, heuristics, etc. go there really isn't a lot of differentiation between the major anti-virus players out there so using any of them should be fine... when i've brought this concept up it's generally been in response to the old what's the best anti-virus question and my response is that the detection rates of most of the mainstream products are so close to each other that their relative rankings can easily change from one month to the next... trying to decide on an anti-virus on that basis is pointless, you need to look at other broad factors like usability and quality of support - basically, you have to find the one that fits your particular circumstances best... for the consumer this is pretty easy as there are free trials available for many of the products...

the second thing that struck me was that they got the overall message so right while getting many of the underlying details so wrong...

1. they say that you want a product that has both real-time and on-access scanning -- real-time and on-access scanning are synonymous, the only real-time scanning any product does is the scanning it does when something is accessed (on-access)... perhaps they meant on-demand and on-access scanning as those are definitely both things you want...
2. they say heuristics look at how programs behave -- heuristics look for familiar/suspicious routines, not bad behaviour... behaviour blockers look for bad behaviour...
3. they say almost all major players have heuristics -- show me one that doesn't have heuristics and i'll show you one that isn't really a major player...
4. they say you should look for instant messaging protection because you can share potentially hazardous files over IM -- this is completely redundant, however, since as soon as you try to do anything with the file you just downloaded your on-access scanner will scan it...
5. they say you should look for webmail protection presumably to protect you from email borne malware you receive in your webmail -- this is redundant as well since, once again, since once you download the malware to your local machine and try to execute it (even if you don't know what you were doing was going to execute it) your on-access scanner will scan it before it executes... perhaps they mean more general web protection to block drive-by-downloads and various other browser exploits that can sometimes launch malware outside the scope of your on-access scanner...
6. they say you should look for conventional email protection if you're instead using email clients like outlook or thunderbird in order to prevent things like melissa or lovebug -- once again this is redundant, on-access scanners catch these when you try to access them... if you're a corporation or some other organization and running an email server then you may want to look into email scanning at the gateway (not to mention content filtering that blocks a variety of attachment types) however...
7. they say email protection is just as important as system protection -- well this is sort of right but for the wrong reasons; email protection is part of system protection... email is just one of many ways into the system...
8. they suggest looking at places like pcmag or cnet for reviews -- the reviews done by such non-expert organizations are notoriously bad (even consumer reports can't seem to do an adequate job of testing anti-virus products)... don't get me wrong, i'm sure they're adequately skilled to perform comparisons of extra (gee-whiz) features, but if you find such a review trying to compare detection rates then run away (unless they outsourced the review to a respected independent testing organization, but in that case why don't not get the review straight from the horse's mouth?)...
9. they suggesting looking at the ICSA anti-virus certifications -- i honestly have not seen much good said about ICSA's certifications but i have seen some not-so-good things said... long story short the certifications are paid for by the vendors (ie. they're bought), the criteria aren't as strict as some others, and the vendors get do-overs...
10. they omit av-comparatives.org and virus bulletin which are much more widely recognized and respected in the anti-virus community...
11. they say that companies won't send you viruses because (essentially) they're worried you'll something dumb with them -- in actuality the bigger concern is that you'll do something irresponsible or even malicious with them.. they have no way to know you won't so they err on the side of caution...

despite all this, i'm still happy with the message that was sent... i just wish it hadn't been followed by material that made me go no, no, no, no...

limited security benefits of limited users

the idea of running as a limited user is getting a lot of attention these days... it's not a new idea, the principle of least privilege has been around for a very long time, but there are some out there who (incorrectly) view it as the solution to the malware problem...

the principle of least privilege states that you should give the least amount of privileges necessary for an entity to do his/her/its task and no more... the idea is to keep people and/or things away from that which they have no need to access... you might well be thinking that this sounds like it really should solve the malware problem, after all if we can prevent the malware from being able to access things it needs to access in order to do it's job then it won't work anymore... indeed, many people think that this practice should be able to prevent viruses and all sorts of other malware... they think that by running as a limited user that any malware they happen to come across will be unable to access the system files and/or resources that are key to the malware's ability to do bad things....

the implicit assumption here is that you need administrative privileges to be able to do bad things... when you make it explicit, however, it should become obvious that this is false... as a limited user you can still delete or modify your own files, can't you? you can still connect to the internet and send data to 3rd parties and receive data back, right? you can still run programs that can display text and/or images, too... those things are more than enough to implement malware that operates in a limited user context... if you can delete or modify your own files then so could a (malicious or otherwise) program you run - opening you up to viruses and a variety of different types of trojans... if you can send and receive data over the internet then so can a (malicious or otherwise) program you run - opening you up to worms and remote control programs like RATs and bots, not to mention all sorts of spyware... and let's not forget that if a program you run can display text and/or graphics it can display annoying ads (ie. adware)...

as you can see, there are all sorts of malware that can theoretically run in a limited user environment... what running as a limited user will do is stop a great deal of the current malware from operating because that malware was designed with the assumption that it would run in an administrative user context... it was a safe assumption to make because most people did and still do run as administrator, and with all the extra power available in such a scenario why wouldn't a malware creator try and take advantage of it... the power they are generally most interested in, the one that is most advantageous to a malware writer is the ability to install the malware - to modify the system in such a way as to ensure that the malware gets run as soon as the computer starts up... but not being able to do that doesn't mean that a virus can't infect or a worm can't spread or a trojan can't trash your files or give remote control to a 3rd party as soon as you run it, it just means that it won't automatically continue doing it when the computer reboots...

and this isn't just theoretical, either... 20+ years ago while performing some of the first academic research into computer viruses, fred cohen was able to get a virus to spread successfully on a professionally administered unix system without having root (administrator) access and without needing the root user to run the virus...

what's wrong with identity management

this is something that's been nagging at me for a while and i think the cross site request forgery vulnerability in gmail from late last year/earlier this year underlines the problem... a single account for everything gives too much power to whoever or whatever compromises that account (whether by gathering the credentials or hijacking the session)... this isn't just a problem with google account, though, there was microsoft's passport, and of course the much talked about (these days) openid...

let's start with the reason for identity management, the motivating factor that lead to it's creation... there's some problem condition out there that pushed people to come up with the idea, supposedly as a solution (though perhaps not a good one)... that problem condition is that with so many sites out there requiring users to log on it's difficult if not impossible for users to remember all the username/password pairs for each of those sites... users, being cunning when it comes to finding lazy solutions, came up with the adaptation of using the same username and password for most/all of the sites they log into... the security problems with this are two-fold: first it creates a situation where instead of having different secrets (passwords) protecting different assets you have one login to rule them all, and second that single set of credentials is placed in many different databases (a different one for each site) which raises the probability that those credentials will get exposed by someone cracking into one of those databases...

identity management generally aims to move user authentication out of the hands of every tom, dick, and harry site out there and into the hands of a trusted few sites which then vouch for the user's authenticity to any other site that asks... this has the immediate benefit of storing user credentials at and conducting the authentication transaction through fewer sites (generally just one) so that the risk of exposure due to database cracking is reduced... unfortunately it still leads to a one login rules them all situation, and frankly database cracking is not the low-hanging fruit in identity theft - if you can do it you can certainly get a lot of credentials in one go, but it's far easier to compromise a user's credentials through the user him/herself by way of phishing or key loggers or a password stealer...

the problem that identity management solves is the same one that users solved by using the same username and password everywhere - it solves the convenience problem associated with many sites requiring authentication... it solves it a little bit better in that one particular type of attack surface (the remote databases) is reduced, but since it collapses multiple accounts down into one it leaves open (and actually promotes) the problem where the compromise of a single set of credentials exposes all your information and assets - and isn't that what the real problem with using the same username and password everywhere is?

the only real way to mitigate the risk of such catastrophic exposure is to use multiple accounts with different credentials - which may be possible with identity management but is definitely not the usage pattern it was designed for... the whole problem arises because using multiple accounts with different credentials isn't easy - everyone seems to want to solve that difficulty by simply not doing it, by finding a way around it, but there isn't one... client-side password managers actually do a pretty good job of solving that difficulty without simply avoiding it, but depending on the implementation those can have problems of their own...

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")

why 'safe site' indicators fail

there's been some interest lately in a study on the efficacy of various 'safe site' indicators such as HTTPS and website authentication images... these are indicators that are supposed to help the user determine that it's safe for them to enter their credentials, that it isn't a phishing site, but according to the study those indicators don't work (or rather their absence isn't enough to tell people that a site isn't safe)...

let's look at why... website authentication images (where you select an image to be shown on future visits to prove that the site is the same one you initially visited - essentially a visual shared secret authentication protocol) are a pretty new development, their use (and their significance) has probably not yet reached the mainstream among users... as such slip ups might be forgiven (if you could attribute a near 100% failure rate to mere slip ups)... maybe websites are just too unreliable when it comes to displaying images - perhaps we've come to expect images to be absent on occasion...

HTTPS indicators (that indicates you're visiting a secure site, that your session is encrypted with SSL or TLS) on the other hand have been around for quite some time... they've become about as mainstream in the publics awareness as they're going to get so their complete failure can't be blamed on it's novelty - perhaps they're just too unobtrusive?

the only one that had a significant impact was actually an unsafe site indicator (a warning that came up when visiting a site that wasn't safe)... now, aside from the interesting implications all this may have for why humans seem to more naturally lean towards blacklists, the relative success of these 2 types of indicators (safe or unsafe) brought to mind a little tidbit about human perception i heard some time ago... it seems that we're much better at noticing when something that shouldn't be there is there than we are at noticing when something that should be there isn't...

put another way:

The opposite to this effect is a situation where the brain perceives something that is not actually there. On being presented with an incomplete object, the brain automatically fills in the missing pieces according to our previous memory and experience. There are many examples available of common optical illusions to illustrate this.

this more than adequately explains why the absence of safe site indicators would be ignored by people, and in so doing shows why such human-interpreted safe site indicators aren't (and won't be) effective at warning people away from phishing sites...

(and yes, i realize the implications this has for my manual phishing email detection method - i can only hope that our tendency to pay attention to who sends the emails we receive makes share secret authentication as a way to weed out phish more workable in an email context than it is on the web...)

snake oil from eEye digital security

found this eEye digital security press release thanks to the infosec sellout blog... i agree with a lot of what the infosec sellout says about this press release but there's one thing s/he doesn't say, one phrase s/he doesn't use that i think it really needs to be said... in the press release in question, eEye is peddling snake oil...

take a look at this quote:

eEye is combining its own anti-virus dynamic heuristics technology with ‘sandboxing’ technology from leading anti-virus vendor Norman Data Defense to complete Blink Professional 3.0 as a single, small-footprint agent, incorporating multi-layered security methods to protect against both known and unknown vulnerabilities in real-time, thus making it the last security product enterprises and SMBs will need to purchase to stop 100 percent of malware attacks, regardless of signatures or patch updates.

do you see what i see? there's a fairly blatant implication that their technology will stop 100% of malware...

long time readers will probably recall past articles on snake oil and realize that snake oil is something i feel pretty strongly about and that this is a punch i will not pull... least of all in this instance with an example of one of the oldest and best known forms of snake oil in the malware domain...

detecting and/or stopping 100% of viruses (which is a subset of malware) is basically the archetype for anti-malware snake oil... it was the epitome of intellectual dishonesty among the less reputable vendors of the past and a cornerstone of most if not all the anti-malware snake oil to follow... there's no good reason why something like this should have been allowed to slip through the cracks unless eEye doesn't care about the quality of the message it sends out to people - and if that's the case, i would strongly suggest voting with your wallets...

words that mislead: protection

i've written about how there's no total, full, or complete protection before and i even touched on how the word protection on it's own was a little misleading, but now i think that that deserves to be more than just a footnote somewhere...

i think we're all intuitively aware of the implied boolean nature of the word protect and it's derivatives - you're either protected or you aren't... if you qualify it properly, then (and only then) the concept of partial protection gets acknowledged (ex. if you go into a sword fight with only part of a suit of armour, are you protected? no, not really... are you partially protected? sure)...

partial protection is all that anyone can ever offer, and usually partial protection is enough, so long as you're also aware of the fact that it's only partial and so have the opportunity to avoid situations where that protection might fall short... unfortunately security vendors rarely qualify their use of the word protect and it's derivatives (protection, protected, etc.) so ordinary folks get entirely the wrong message from the vendors and are lulled into a false sense of security, sometimes simply due to a sloppy choice of words (though as witnessed before, it's often a downright intellectually dishonest choice of words)...

so to help people make more accurate interpretations of the messages they get from vendors, whenever you see the word protect, protected, or protection, whether qualified or not, adjust it's qualification to mean partial protection and try and make yourself aware of the situations where that protection might fail...

on the application of legal pressure in the fight against malware

thanks to a reader i was pointed towards an article about kaspersky's efforts to make the law a more effective tactical device for use in the battle against malware...

using the law this way is not a new or unusual idea - there are many sides to the malware problem, it has many different dimensions, and some of those involve people rather than technology... from a strategic point of view it makes sense to try and address the problem on all fronts and one of those deals with the people responsible for the malware, be they malware creators or just purveyors... the only way to force them to stop being part of the problem (well, the only legal way to force them) is by using the law to catch and prosecute them...

doing so is not a mark of desperation, it's not something you do simply because you are being overwhelmed by the number of malware being created, it is something you do if you're smart... it is a strategy designed to subject the blackhats to the forces of attrition and thereby control (to some degree) the number of people creating/using malware and by extension the amount of malware being spread around and the amount of malware out there at any given time that qualifies as new...

it's controlling the amount malware that qualifies as new at any given moment that is the most interesting/tempting benefit here... whether an anti-virus company can keep up with the rate of malware creation or not it doesn't change the fact that as rate goes up the number of pieces of malware that can't yet be handled by known-malware scanning at a particular moment in time also goes up and therefore so does the user's chances of encountering such undetectable malware... now at 200 a day, most of which have very low distribution, and hourly updates available, those odds aren't necessarily cause for alarm but you wouldn't want them to keep growing unchecked...

of course if you are being overwhelmed by sheer numbers, it can help there too, but being overwhelmed (as opposed having already been overwhelmed) is just another way of saying you're currently operating at peak capacity with your current resources - it doesn't make too much sense to keep people around if you aren't making use of them after all... you can either acquire more/better resources (which costs money) or you can try to get law enforcement to reduce the demand for those resources (guess which one is better for the bottom line)...

an important thing to note however, is that the law isn't likely to be any more effective at addressing the problem of cyber crime than it is at addressing the problem of regular crime... as such, hinting around about solving the malware problem (which cyber crime is a part) as the article does about solving the malware problem is misleading... the law alone isn't going to do it, the law in combination with other tactics isn't going to do it, the law is just an additional measure to help mitigate the problem...

words that mislead: solution

when is a solution not a solution? when it solves the wrong problem...

how many times have you seen an anti-malware product called a solution? i know i've seen it a lot and it's one of those things that really bugs me because they aren't solutions to the problem you're expecting... when people think of an anti-malware solution they naturally think of something that will solve the malware problem...

but there is no solution to the malware problem and there can never be such a solution... a solution to the malware problem implies that it wouldn't be a problem anymore - that you and i wouldn't have to worry about it, think about it, or deal with it anymore... it implies that the problem would just go away - that will never happen... there can never be perfect security so there will always be things that can be taken advantage of, and so long as there is darkness in mens' hearts someone will be taking advantage of those things...

what anti-malware solutions solve are not malware problems or even security problems, but rather they solve business problems... say you're given the task of finding a security product with some arbitrary set of properties and deploying it in your organization... the problem you face is finding the product that is the best fit, that has the most requirements from your checklist with the fewest undesirable trade-offs - that is the type of problem that anti-malware solutions solve...

unfortunately, most consumers of anti-malware products are not thinking about business problems, they're thinking about keeping malware away from their computers... most of them are people, not IT departments with a new demand from management - and those who work in IT departments are people first and IT workers second, they're people when they go home at night, they're people when they're with their families on the weekend...

as much money as anti-malware companies make off of corporate customers, framing their message for the narrowly defined business context sends entirely the wrong message to everyone else... it suggests the product can make the malware problem go away instead of more accurately suggesting that it's simply a tool that can help the customer to better protect their systems...