Sunday, December 31, 2006

how to recognize phishing emails the easy way

perhaps you've seen this phishing iq test before... if not, that's ok - it's basically a bunch of examples of legitimate emails and phishing emails and you have to try and figure out which are which... the root concept is that there are these heuristics or rules of thumb that you can apply so as to determine whether a particular email is phishy just by looking at it...

the fact that browsers now come with anti-phishing technology built in that tries to identify a phishing site just by looking at the URL is strong evidence that those rules of thumb for detecting phishing emails are a failure but take the test and look at some of those rules at the end and see if you can determine why those rules aren't going to work... if you ask me, those rules are just too complex for the average person to remember or apply... add to that the fact that the characteristics of a legitimate email are possible in phishing emails (for example, ebay starts their emails to you with your ebay user name but anyone who has interacted with you on ebay knows that user name and thus has the information necessary to make a convincing fake ebay email)... finally take into account that legitimate emails often display phishy characteristics (both in the test, where only one of the emails was completely free of phishy characteristics, and in this real world example) and it becomes clear that not only are the rules complex but they're pretty much completely unreliable too...

after getting through that test, if you're like me you're probably saying to yourself "there must be an easier way"... so you can imagine how glad i am that i don't need to try to remember and follow those screwy rules... instead, i do something i touched on in my spam avoidance article - i use disposable email addresses... now, while the spam avoidance techniques actually apply to pretty much all forms of email annoyance (if the bad guys don't know your email address they can't send you bad email), i'm actually talking about more than just keeping my email address out of the hands of phishers, something that works even when your real email address is known to the bad guys... i use unique (a different one for each site) unguessable disposable email addresses provided by sneakemail.com and then when i get an email from ebay or paypal or my bank i check and make sure that it was sent to the right address for that organization...

here's how the magic works - let's say i create an address like mgbwklw02@sneakemail.com and give that address to ebay and no one else... the address is a secret that only ebay and myself know and no one else can guess so when i get an ebay email sent to that address i'll know that it was sent by ebay because they proved who they were by using a secret known only to ebay and myself... it's like knowing the secret passphrase or handshake to get into an exclusive club (or, more technically, it's like a shared secret authentication protocol)... alternatively, if i get an email supposedly from ebay but sent to some other email address i'll know it's fake because it was sent to some address that i never gave to ebay in the first place... if someone really, really wanted to send me a convincing fake ebay email they would have to either guess exactly the right email address to send to or guess the label i gave my ebay address (sneakemail.com allows you to label your disposable addresses and includes the that label in the From: field to help you determine which address the email was sent to) and try to forge a sneakemail.com header...

could using unique unguessable disposable email addresses for sites/organizations and ignoring emails sent to the wrong address for the site/organization in question qualify as an anti-phishing safe hex rule? i think so... although it requires a little more work up front (creating a new address each time you create an account somewhere), it's conceptually simpler than the multitude of rules currently being suggested and it's a lot more reliable too since it doesn't depend on questionable criteria such as how the email was composed...

Thursday, December 28, 2006

how to avoid email spam

typically, the life-cycle of email spam (in the most general sense) goes something like this:
  1. the spammer gets your email address
  2. the spammer sends you spam
  3. you receive and do your best to deal with that spam

most of the anti-spam technology that the average person is aware of works to deal with spam after it's been sent, effectively trying to address stage 3 in the spam life-cycle... you probably know this technology as spam filtering, either a black list where you record all the email addresses (or perhaps domains) from whom you don't want to receive email, a white list where you record all the email addresses from whom you do want to receive email, or some more advanced content-based spam filter such as the bayesian filtering... as most average people are at least vaguely familiar with spam filtering (even if only by way of noticing there's a junk mail folder in their webmail) they also know (or if not, should be made aware) that filtering isn't a perfect solution, that some legitimate mail can get flagged as spam and some spam may fool the filter into thinking it's legitimate mail... nothing is perfect, but as spam volume increases the number of spams that sneak through spam filters also increase, and nobody (except the spammers) want to see the amount of spam in our inboxes increase...

addressing stage 2, trying to stop the spam from getting sent or at least making it more difficult or costly, is something most average folks aren't aware of (or at least don't often think about) because it's not something they've been a part of for the most part... early on there was account termination for those caught spamming, then there were CAPTCHA tests to stop the spammers from creating very large numbers of accounts (which would otherwise make account termination a non-issue) from which to spam from... after that there was a crack down on open mail relays and ISPs started trying to block their subscribers from connecting to outside SMTP servers... now spammers use botnets designed for sending spam, effectively moving the burden of stopping spam out of the hands of centralized organizations like ISPs and into the hands of end users whose machines have been compromised and who are least likely to be able to deal with the problem or even be aware of it's existence... if you've never heard of this before, now you've got a brand new reason to prevent malware from compromising your computer - to help keep the spam problem in check...

avoiding spam
neither of these qualify as avoiding spam, however... in order to do that one must address spam at the earliest stage in it's life-cycle, one must stop the spammer from getting one's email address in the first place... think of your email address as being like your home phone number - it's confidential information that you don't hand out to every tom, dick, and harry you happen across...

keeping your real email address secret is probably not the most intuitive thing in the world, especially since so many things require you to give them an email address, but there are services and techniques that can help make it easier... there are also limits to how well the secret can be kept, but as an example i've managed to keep a webmail address i use daily completely spam free (there isn't even anything in the spam folder) for over 2 years simply by being careful and not giving out the address except to those i trust... one other caveat is that you can't make an email address secret if it wasn't a secret before... if your current address is receiving spam then the spammers already have your email address, the address has been compromised and there's nothing you can really do about that - you can't put the genie back in the bottle...

what you can do, with a fresh email address, is use disposable email addresses that forward to that real email address... a number of people are already familiar with the idea of a throw-away email address and often use hotmail or some other free webmail provider to make one but unfortunately that leaves you with no way to know who leaked your address to the spammers so when you need to change addresses (because the current throw-away address has gotten too spammy) you'll have no way to know which organizations to not give the new address to (never mind the fact that you'll have to give a new address to a bunch of organizations)... this is where true disposable email addresses come in - you need to use a different address for each site you give an address to (whether it's ebay, amazon, or your bank) so you can identify which one leaked the email address simply by looking at which email address got leaked and so that you only have to turn off that one address when it starts getting spammed rather than changing addresses and updating a potentially long list of sites with your new address... dedicated disposable email address services make creating multiple addresses easier (certainly easier than creating multiple throw-away email addresses where you have to answer a CAPTCHA test for each one) and managing multiple addresses (ie. turning off the ones that get spammy) easier as well...

different services provide addresses with different properties; some will forward the email sent to the disposable address on to your real address while others might maximize the ease and convenience of creating a new address by allowing you to create one without contacting the disposable email address provider first... beware the combination of these two properties (something spamgourmet.com does), however, because you invariably wind up giving out the information necessary for others to create new addresses that will forward to your real address and you don't want any tom, dick, or harry to be able to do that anymore than you want them to be able to email you directly... instead, use the created-on-the-fly addresses in cases where no sensitive information is going to be sent and/or in cases where you're likely only going to need to check for mail once (because most on-the-fly disposable email address services also don't require a login to check the email - mailinator.com and dodgeit.com work this way), and use forwarding addresses (such as those from sneakemail.com or mailnull.com) for everything else so that you get the benefit of picking up the mail in one place that only you (and your real email provider) have access to...

website feedback
now that takes care of sites that ask you for your email address, what about if you have a website or even a blog like this one? you want to be able to receive feedback from people without being deluged by spam but if you put an email address on the page then software that searches for email addresses on the web will find that address pretty quickly and it will soon be filled with spam... using disposable email addresses on their own doesn't solve this problem...

one thing people like to try is email address obfuscation - where the email address is manipulated in such a way that software that searches for email addresses can't easily recognize it as one... unfortunately this runs into competing requirements - in order to truly prevent software from collecting your email address for the spammer the email address has to not be machine readable, however people expect to be able to click on something and start typing their feedback and that functionality requires that the email address is machine readable... no email address obfuscation method can achieve both requirements so you generally either have to break expected functionality or accept that the email address isn't truly hidden...

a better solution is to use a contact form, specifically one that doesn't contain your email address in it's code... mailnull.com happens to offer this facility, it's what i'm currently using for this site at the time of writing, you can see what it looks like by clicking here... the only major drawback to using a web-based contact form is that people can't send you attachments but considering how troublesome attachments can be from a security standpoint, not providing a way for first time contacts to send them to you doesn't seem like all that big a deal... if you do encounter a scenario where it is a problem, the first time contact could use a file storage solution like dropload.com with their own disposable email address in the To: field and then paste the resulting URL into the web contact form...

additionally, if you not only have your own website but your own domain, you may want to turn off the default/catch all email functionality (where email sent to any non-existent address on that domain is 'caught' and collected for review and possible redirection to relevant parties)... so long as you are providing people with a clear way to directly contact the right individuals within your domain there should be no reason for anyone to send email to non-existent addresses on your domain or firing emails blindly at arbitrary addresses on your domain...

friends and family
as i mentioned before, there are limits to the extent to which you can keep your email address secret and a potentially very big hole in the strategy involves your trusted contacts (be they friends, family, or business contacts)... these are people you can't reasonably be expected to keep your email address a secret from and so may wind up being a source of email address leakage... what can you do?

pretty much what you can do boils down to treating their email addresses with the same care you would treat your own and teaching them to do the same for you (maybe even pointing them here)... that means that you shouldn't give their addresses to websites no matter how cool those websites might happen to be or how interesting you think your friends/family/contacts will find the site (even those greeting card websites that are so popular around the holidays) - instead you should give those sites one of your own disposable email addresses and then forward the resulting email to the person you wanted to share the site with, thus giving them exactly the same information you would have given them if you'd exposed their email address to the website but without actually exposing their email address to the website...

additionally, don't share people's email addresses with other people they don't know... if you're emailing people that don't know each other, put your own email address in the To: field and put the other email addresses in the Bcc: field so that they can't see each other's addresses... if you're forwarding something to people, make sure not to include any of the email addresses that it was previously sent to or from as forwarded emails otherwise tend to build up large numbers of email addresses on a large number of strangers machines - any one of which might get compromised by a piece of malware that harvests email addresses for spammers and other email miscreants and that's something you want to minimize where possible...

anti-spam safe hex
all these things effectively form a set of spam-related safe hex rules... summarized, they are:
  1. treat your email address like a secret
  2. use a different disposable email address for each website you give an address to (so that if you do get spam you can tell who to blame)
  3. use contact forms instead of email addresses on your website
  4. turn off the catch-all email functionality for any domain you might have
  5. don't give your friend's/family's/contact's email address to websites
  6. don't give your friend's/family's/contact's email to people they don't know
  7. try to teach your friends/family/contacts to show your email address the same care that you show theirs

Friday, December 15, 2006

go find some other argument

i'm going to preface what i'm about to say with this: i like security incite blog, i like it's content and i like it's name and i look forward to reading the daily incite each day...

that said, mike rothman needs to find a different angle to counter the anti-patchguard arguments than what he used here... it's pretty clear that it's an emotional argument, he criticizes what he perceives alex eckelberry's motives to be rather than arguing the facts...

here are the facts:
  1. there are important security functions (functions that remain important in spite of vista's enhanced security) that are just not possible under the current state of affairs with 64bit vista and won't be possible for years to come...
  2. microsoft security program manager stephen toulouse admits that functionality is missing from the currently supported API and that it won't be seen until sp1 or sp2 here...
  3. alex makes a very good argument for why full kernel access is needed (if/when a new type of kernel access is required to address a novel threat, there's no way to address the problem in a timely fashion if you have to negotiate access for months/years with microsoft to get that access)...

it's not about whether microsoft has the right to change their product, obviously they do have the right... it's about the fact that they're hurting security by saying that it can only be achieved in a certain narrowly defined set of ways and making attempts to go outside that set (like when it becomes obvious that microsoft didn't think of everything) cause the computer to crash...

maybe alex is just looking out for his bottom line but that doesn't mean that he's wrong or that the issues he's raised don't matter... microsoft has made entire classes of security monitoring impossible and anyone who cares about security should care about that and anyone who doesn't think those techniques are going to be useful anymore (that vista will obviate the need for such techniques) doesn't understand malware... to paraphrase jeff goldblum in jurassic park 'malware will find a way'...

sure vista looks all new and shiny and secure, and it will probably make a dent in malware too (at least existing malware), but in the long run that doesn't amount to a hill of beans... windows 95 probably did more to kill the major malware threat of the day (11 years ago the major threat was boot sector viruses) than any other technology or event but it didn't stop malware, malware evolved (obviously as windows is now seen as a malware magnet) and continues to evolve and will continue to evolve in the future... in order to deal with a constantly evolving threat landscape you need flexibility and that flexibility isn't there, nor is it even on the table (microsoft has promised additional kernel access but they haven't promised full kernel access)...

no one is arguing that there isn't good reason for microsoft to block access to the kernel, but doing so without first implementing all the necessary officially supported alternatives? come on, you don't brick over your back door if you don't have a front door yet...

Thursday, December 14, 2006

what virtualization can and cannot do in an anti-malware context

there seems to be some mismatched expectations about the protective capabilities of keeping untrusted behaviours/applications/etc confined to a virtual machine... essentially what we're talking about here is a sandbox for untrusted things like web browsing and email... the general idea is that if you can keep the bad stuff from the internet away from your physical system and confidential information then you should be fine... unfortunately it's not that simple...

the idea of the sandbox is to create a barrier separating 2 environments, one environment (the host system) containing important data and one (the sandbox) containing only things you can easily replace... while it is true that malware that gets onto the virtual machine probably won't be able to get to your physical machine (unless you move it to the physical machine yourself or in the unlikely event that it exploits a vulnerability in the virtual machine that allows it to escape), what isn't true is the assumption that you don't have to worry about malware and other security threats anymore because you're protected...

consider, for example, the scenario where adware gets installed on the virtual machine - will the separation stop the ads from reaching your eyeballs? no... and if a worm gets onto your virtual machine, will the barrier that protects your physical machine stop the worm from spewing back to the rest of the internet? no... and if you get a keylogger or password stealer or some other sort of spyware in your virtual machine, does the fact that it's in a sandbox stop you from entering or accessing sensitive information like your bank account credentials or your credit card number? no... does a virtual machine stop you from visiting a phishing site? no...

virtual machine based sandboxes are great for testing malware as well as other sorts of software because in a testing context you can enforce the separation of the virtual environment from any sensitive data and because a virtual machine is easy to restore to a previous state (simply by restoring a copy of the virtual machine made when it was in that state)... operating in a sandbox, on the other hand, makes it quite improbable that you can keep sensitive data separate from the sandbox (because malware and sensitive data travel over many of the same channels) and restoring the VM to a previous state does get rid of the malware but does not undo the damage done by any sensitive data that may have been leaked by the malware (you can't put the genie back in the bottle)...

in an operating environment you can't simply treat malware and related threats as a system recovery problem - flattening and rebuilding (whether done to the physical machine or the VM) may get rid of the malware but it won't undo the malware's consequences... recovering from the consequences of malware is a much more complicated problem which is one of the reasons it's preferable to prevent them in the first place... since sandboxes don't prevent malware, only the passage of malware from the sandbox to the host system, sandboxes won't protect the user from the consequences of malware... that means in an operating environment that includes a sandbox, the sandbox will require protective software just the same as if there were no sandbox at all - and virtual machines are notorious for being noticeably slower than their physical counterparts so that anti-malware software that slows down your physical machine is going to make your virtual machine even slower...

for all the things it can't do, however, a virtual machine based sandbox is easier to recover than the host system, but is it significantly easier than restoring a physical system from a previous image? my guess would be no, but that's really for the computer operator/administrator to decide...

Wednesday, December 13, 2006

what is greyware?

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

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

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

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

back to index

Monday, December 11, 2006

the stupidity of exploit wednesday

exploit wednesday is the day after patch tuesday, so named because apparently exploits get released on that day supposedly so as to maximize the length of time the exploit can be used against systems...

but who says the day after patch tuesday is the best day to release exploits? does it really maximize the window of exposure? if an exploit were released one day earlier (ie. the same day as patch tuesday) would there really be time for microsoft to create and test a patch to be included in patch tuesday? how about 2 days earlier (as in today, the day before patch tuesday)? how about 3?

if we look at history, what is the shortest time microsoft has ever needed for researching, addressing, testing, and deploying a patch? an exploit should be releasable before patch tuesday so long as there isn't enough time for the patch to be included... right now there are currently 2 unpatched microsoft word vulnerabilities (one of which has been known about for a week or more) with exploits being used in the wild and they aren't getting included in tomorrow's patch roll-out because there wasn't time to go through the extensive development and testing process that microsoft puts patches through before deploying them...

if the exploit is serious enough to warrant an out of cycle patch then it doesn't matter when you release it because you won't be able to manipulate the size of the window of exposure through timing the release... otherwise the maximum window of exposure is achieved by releasing {minimum microsoft patch time} - 1 days before patch tuesday...

if the bad guys who make and sell the exploits don't know this yet then they're morons... if the bad guys who buy the exploits haven't figured this out yet and agree to an exploit wednesday release date then they're also morons... if the good guys are expecting the bad guys not to figure this out, if they genuinely don't expect to see many exploits until exploit wednesday then they are naive and they're eventually going to get caught with their pants down...

what is a zero-day exploit?

a zero-day exploit is exploit code that is in the wild (being used on computers in the real world rather than just a lab) on the same day (or even earlier) that the vulnerability it exploits is discovered by the good guys...

often the vulnerability is discovered by virtue of discovering the exploit code (ie. the exploit code reveals the presence of the vulnerability)...

the zero-day adjective dates back at least to the early warez days where releasing a pirated copy of something while it was still zero days old was something that was handsomely rewarded by others in the scene...

back to index

Monday, December 04, 2006

old viruses never die

the wildlist is often seen as the definitive reference for what viruses are in the wild, so much so in fact that a special form of 'in the wild' (ItW) that has become synonymous with in the wild according to the wildlist...

not long ago, however, i heard and interesting and fairly reasonable criticism of the wildlist that brought it back down to earth... that criticism was something along the lines of there being a reporting bias in the wildlist where some viruses, though active in the wild, aren't reported on the wildlist because anti-virus products remove them without incident when they're encountered... when you consider the fairly finite list of trusted people who report to the wildlist and the fact that there's really no reason to draw the attention of any of them to a virus that any trained monkey (armed with an anti-virus product) can get rid of it's easy to see how many viruses could go unreported on the wildlist...

this means that the lifespan of a virus can not really be measured by how long it stays on the wildlist... this in turn means that a virus that is on the wildlist for two years did not necessarily last longer than a virus that only stayed on the list for one year...

my favourite example of a long lived virus is stoned.empire.monkey; it was on the wildlist for over 10 years, few viruses can boast such longevity... one of the reasons it stayed on the list so long is because monkey was not as simple to remove as other viruses (especially other boot sector viruses) in it's day - the generic advice involving fdisk had unintended consequences (loss of access to your data) where monkey was concerned because monkey moved and encrypted the original uninfected MBR... this meant that instances of monkey infected computers were much more likely to be brought to the attention of a wildlist reporter somewhere...

however monkey disappeared from the wildlist sometime in late 2003, presumably because the environments in which it could thrive were gone (boot sector infectors generally can't spread in the 32bit windows environment that was introduced some 8 years prior to monkey's disappearance from the wildlist)... in spite of anti-virus products being able to detect and remove monkey for almost if not the entire time it was on the wildlist, av programs did not seem to be able to drive it into extinction any more than the fox could drive the rabbit to extinction in the classical biosphere models found in highschool biology textbooks... instead, loss of habitat seems to have had the biggest effect in killing off not just monkey but the entire class of boot sector infectors...

it's entirely likely that monkey is not alone in this respect... if detection and removal couldn't drive monkey to extinction, why should they drive any other virus to extinction?... given the reporting bias of the wildlist suggested earlier, it's quite likely that many viruses still go about happily infecting unprotected computers and being easily zapped when they encounter av so that there's no report of their activity - that they continue spreading just under the radar until the environment on which they operate is gone and for most virus classes that kind of loss of habitat hasn't actually happened yet...

in fact, it's debatable whether there's even been complete loss of habitat for boot sector infectors like monkey... just last night this blog was visited by someone doing a google search on the keywords 'stoned.empire.monkey.a removal' (i hope they found killmonk, the dedicated monkey removal tool)... my guess is that, since boot sector viruses are considered extinct, nobody bothers with the safe hex steps that mitigate the risk of boot sector infection (ie. changing the boot sequence for the computer) so old floppy disks are re-introducing the virus to active machines, and/or maybe (just maybe) some of the machines out there are still running dos...

anti-virus is dead - not!

well, it looks like yet another (ahem) security expert (albeit one who apparently worked for an anti-virus company in some capacity a decade ago) is sounding the death knell for anti-virus software...

don't be alarmed though, the sky is not falling... people have been prognosticating the end of anti-virus software since the last millennium... it hasn't happened yet and it probably never will..

this example isn't much different than the previous hundred and one instances of av doomsayers... i've written about the supposed failure of anti-virus software in the past - does that address this situation? you betcha... the author (amrit williams) trots out 3 whole examples of worms that anti-virus software didn't stop, but seems to have forgotten the tens of thousands that it did stop... perceptual bias? sure... mike rothman previously made an elegant comment about mismatched expectations and judging by how far outside of av's scope most of mr. williams' examples of av's failures are his expectations are very mismatched...

what he really seems to be getting at is that av sucks because it's not UTM... the argument seems to be that anti-virus on it's own doesn't do as good a job at solving the business problem of security management as a security suite would and perhaps he's right about that narrowly defined part of the malware problem, but certainly not about the malware problem as a whole which neatly transcends your field of vision while you've got business blinders on...

stand alone anti-virus isn't going anywhere, not so long as the world is more than just a collection of businesses, not so long as there are home computers/networks out there, not so long as my security needs differ from your security needs, not so long as best of breed still has benefits, and not so long as we collectively still remember the saying "jack of all trades, master of none"...

stand alone av is evolving mind you, by including detection of additional forms of malware (that most people, and the av products themselves, were calling viruses anyways), but that doesn't stop it from being stand alone anti-virus...

Saturday, December 02, 2006

what is pharming?

pharming is a phishing enhancement technique that manipulates domain resolution (by changing the victim's hosts file or by DNS cache poisoning) in order to make it impossible to recognize a phishing site just by looking at the URL...

by this i mean that when the victim visits the phishing site it will have the domain name of the site that the phishing site is impersonating... in fact, when the victim tries to go to the legitimate site, whether by typing in the URL from memory or using bookmarks or other legitimate links they will be redirected to the phishing site instead...

while some of the simpler phishing attacks may disguise the phishy nature of a site by using URL tricks (such as URLs with @ symbols in them, or URLs that are simply close to the legitimate URL or contain the legitimate organization's name in them), pharming disguises it at the network level so that even anti-phishing toolbars and technology are unlikely to detect the attack... that said, pharming is a more difficult form of disguise to pull off than simple URL trickery...


back to index

Thursday, November 23, 2006

what is phishing?

phishing is a form of identity theft where the victim is enticed (typically by means of a message of some sort) to use what appears to be a legitimate logon page for some service (like online banking or paypal or ebay) but is actually a fake page designed to capture identifying information (like credit card numbers or login credentials) that enable the perpetrators to fraudulently pose as the owners of that information...

like email scams, phishing is usually about getting your money; however, unlike email scams where you are convinced to hand over your money, phishing just tricks you into revealing the information necessary for the phisher to take your money him/herself...

also like email scams, phishing is a form of social engineering - usually you're given some compelling reason to visit their fake logon page such as giving you the chance to undo a transaction that you never actually made or making mandatory updates to your account information...

back to index

what are email scams?

email scams are scams (confidence games) perpetrated over email... it's where someone sends you an email that tries to convince you to give them your money (or something else of value), whether for a pyramid scheme or a 419 scam or some other kind of hustle...

because they fool you into doing something you wouldn't otherwise do, email scams (and scams in general) qualify as a form of social engineering...

back to index

what is spam?

spam is a form of network abuse whereby one tries to force feed a (usually commercial) message to as many people as possible...

by force feed i mean that the spammer puts the message where people don't want it and can't easily ignore it - often they have to do something about it to get rid of it...

reaching as many people as possible is achieved either by sending the message many times to many people (such as with email spam) or broadcasting it in such a way that a single instance of the message will be seen by many people (such as with usenet spam) or both...

it may seem like this description isn't doing spam justice, that spam's impact is larger than what is implied here, that a message you don't want to see is a minor annoyance (like commercials on tv) in comparison to spam... well multiply that minor annoyance by 100 (or more)... a single spammed message really doesn't have a lot of impact and if we only got a single spam every now and then we wouldn't really be all that concerned about it... the problem with spam doesn't come from the nature of spam but rather from the sheer unrelenting volume of spammed messages... one popular statistic (at the time of writing) states that spam accounts for 85% of all email traffic - that's a lot of garbage to wade through to get useful content out of your email...

spamming can be done over any network that humans communicate (in some fashion) over such as email (conventional spam), usenet (usenet spam), instant messaging (spim), blogs (splogs), blog comments (comment spam), or even p2p networks...

[see this article on spam etymology for details on the origin of the term]

back to index

what is junk mail?

junk mail is an umbrella term for any unwanted email...

this includes email spam but it can also include those unfunny jokes your friends forward to you and those service updates from whatever online services you may have signed up for... and of course there's also the chain letters, scams, phishing, email worms, etc...

junk messages can also come in through other communication media as well, but junk mail is best known in part because email is such a mature and widely used medium compared to many of the others (like instant messaging or p2p)...

back to index

Monday, November 20, 2006

grey goo strikes again

looks like one of the more interesting things in security blog land today was a service outage over the weekend in second life caused by the infamous grey goo (virtual virus hits second life, grey goo hits second life, worms in second life, security, a human problem)... i'm not sure why they all chose this particular time to take notice of the grey goo in a malware context but at least now i know i'm not the only one who thought it was an interesting instance of game-related malware...

this particular case was pretty unremarkable, though, unless you take the golden rings (from sonic the hedgehog) into account... otherwise it really wasn't a big deal - it's not the first time and it's not the worst time... presumably the first time was the worst time because linden labs hadn't yet developed tools to cope with the problem of self-replicating code in the game, but now they have and this latest case saw new logins blocked (if you were already in the game you could generally stay in) for less than half an hour while they cleaned up the mess (as opposed to the head scratching and long-delayed resolution they went through when the problem first came up in october of last year)...

of course there's more to the story of grey goo than most seem to be reporting... last month i wrote about it, about it's classification, and about the counter measures linden labs developed - essentially behaviour blocking technology... the fact that grey goo continues to pop up from time to time illustrates the broader principle that behaviour blocking can't completely solve the virus problem... i suspect that the quick cleanup this time points to what essentially boils down to a signature based removal technique as well (which, for the time being at least, is a perfectly reasonable way to recover from the special cases that get around the primary defense), so linden labs continues to be an interesting example of anti-malware techniques and technology developing in the apparent absence of but parallel to the anti-virus industry...

Thursday, November 09, 2006

how to avoid codec roulette

does this sound familiar? you've gotten this video off the internet and when you try to play it you get informed that playing the video requires a codec you don't have...

this is actually a pretty old problem and the obvious solution most people hit on is find the codec and install it - and of course then you have to hope that it actually works and that it doesn't cause conflicts with other codecs or general system instability...

more recently a more insidious trend has emerged - the codec, rather than simply not getting along with other codecs or being poorly coded, is not a codec at all but is actually malware... this is a pretty clever form of social engineering because when a person makes a judgment about the safety of the whole thing it is at this point when they decide whether to try to watch the video in the first place and the judgment most will make will be that the video file is probably safe because video files generally are... at that point they become committed to watching the video even though the demand for the codec changes the entire safety equation - they pay no heed to whether or not the codec is safe, they just want to be able to look at this video they have in their hot little hands... you could almost think of it like a bait-and-switch scam...

these sorts of fake codecs have been getting a fair bit of attention by the security related press and a lot of people have been trying to address the problem by coming up with lists of bad codecs and the sites distributing them... many of these same people criticize the classic anti-virus model of enumerating bad things as being a broken model so i'm not sure why they think their own ad-hoc enumerations of badness are any better... at any rate, lists such as this fail to address a significant part of the socially engineered problem - once a person decides to watch the video they are much less likely to think about the safety of the codec they're subsequently asked to install in order to get at that content they are trying to watch...

another much more to the point way of addressing the problem is to just tell people don't install codecs... this advice would certainly work, but people who have videos they can't watch have an incentive to not listen to that kind of advice... it's not like you can tell people that the video is probably a fake because there are so many legitimate codecs out there that aren't installed on computers by default that legitimate videos asking for legitimate codecs is actually still a very probable scenario...

as an aside i'd like to admit something to you - i am a consumer of video content, i have been for quite a long time and i played codec roulette back in the day before codecs became a major malware attack vector... codec roulette pissed me off because it was so much work sometimes to find just the right codec... there was even a point where i tried re-encoding the videos so that i'd wind up with files that were all the same format, but even that required the codecs...

it turns out that a solution to the hassle of the old-school codec roulette works pretty good for the new malware enhanced version of codec roulette as well... the reason is because the solution to the hassle of codec roulette is to find a player that will play just about anything without ever having to find and install codecs... armed with such a player, supposed video that needs a codec you don't have becomes a much more suspicious scenario and so one that people are less likely to fall for...

for me, that media player was the vlc media player (which i supplemented with real alternative for realmedia files)... there may be others (in fact there probably are) that handle even more formats but i don't recall the last time i encountered a video i couldn't play right out of the box or even if i've encountered any such files since moving to this solution (even video downloaded from youtube, or mkv files which i'd never even heard of until i had one and found that yes vlc handles them too)... i have no idea how well vlc handles DRM contaminated video files but i don't need or want digital rights malware on my computer anyways...

so consider this a bit of safe-hex for video consumption... get a player that can play just about everything and then when a video you can't play comes along consider it suspicious by default and don't bother with it because it's probably not going to be good for your computer...

Friday, November 03, 2006

malware creation in academia

i wrote about one instance of academic malware writing not too long ago... in that case a virus was made to prove that viruses could be a threat on what was essentially a tricked out windows box (paging captain obvious)...

another pair of incidents have grabbed people's attention recently even though they aren't exactly new... one involves mobile malware created and released for download by the university of santa barbara which symantec actually linked to and then quickly removed the link (thanks guys, it's nice to see i'm not the only one trying to follow an anti-malware linking policy) and which predictably (and rightly) drew criticism...

and of course there's also our old friends from university of calgary (who gained infamy for running a course where the curriculum involved writing viruses, which many people spoke out against) deciding to branch out into spam and spyware... this too drew criticism, and rightly so... if you're anti-drugs then you don't create/use/sell drugs, if you're anti-violence then you don't create violent situations (at least not intentionally), so how can you pretend to be anti-malware if you create malware? have we forgotten what the prefix anti- means?

well, not everyone has forgotten what it means - the anti-malware industry, for example, remembers quite well and for the most part will not hire those who create malware (although not all sectors of the anti-malware industry are as principled as others)... ed moyle thinks the av industry is being unfair to punish students for taking such courses, but he misses the point - it's not a punishment, it's a consequence... there are plenty of fields where previous breaches of the fields' mores disqualifies you from being employed in those fields... police, firefighters, even school bus drivers have to be people you can trust not to do something that is a taboo in the context of their respective jobs... any job you can think of has a similar requirement because all jobs involve trust at some level... i hardly think it's unreasonable to expect that people who create malware shouldn't be able to get jobs in the anti-malware industry...

on the other hand, when a professor or academic adviser teaches or endorses this type of pursuit knowing full well what the consequences will be for the students (and the professor in question most certainly did), certainly more than the students themselves, then shouldn't the finger of blame spend some time pointing in his general direction? and if the professor later compounds that affront by branching out into addition malware fields so as to disqualify his students from even more segments of the anti-malware industry, can there be any question about whether he's serving his students' interests or if he's teaching them material they'll actually be able to use in the fields they would otherwise expect to be able to use it in (i know if i learned about viruses i'd expect to be able to put it to use in the anti-virus field)...

of course proponents of this kind of training will talk a good game about needing to understand how malware works, but what most fail to recognize (or perhaps they're just hoping your own thinking is sloppy enough to miss this) is that learning how a thing works and learning how to make that thing are actually quite different... learning how to make a thing is not required in order to learn how it works - i don't need to know how to make a shiv in order to know how a knife works, i don't have to learn how to build a car in order to make it go... moreover, just because you wrote malware X doesn't mean you know how it actually works, all you really know is how you intended it to work - making malware doesn't really teach what you'd expect it to... were these malware creation activities to be replaced with reverse engineering of existing malware, the students would learn not only how the malware worked but they would also learn a skill that would be directly applicable to a career in the anti-malware industry and they might even wind up being sought after by multiple competing anti-malware vendors... wouldn't that serve the students' interests better? wouldn't that better prepare them to use the knowledge they gain in the field it applies to best?

Tuesday, October 24, 2006

the myth of AV's failure

i'm sure you've heard it said before that the idea of conventional anti-virus techniques are broken or obsolete, that av is failing... i've touched on the topic before here and here but i think it's time to tackle this myth head on...

people say and believe that conventional av is outdated because of all the reports of it's failure... there are lots of examples where program X failed to stop malware Y from infesting computer Z so could forgive some of the greener minds for concluding that those reports are representative of reality, that anti-virus products don't do a good job...

what anyone with any degree of training in statistics will notice, however, is the obvious selection bias in those reports - you hear about av products failing but you don't hear much in the way of success stories, not because there are no successes but because there's no reason to report them... the failure reports give an entirely lopsided view of the efficacy of conventional anti-virus techniques, leading to the negative perceptual bias the security community now suffers from...

conventional anti-virus (known virus, or known malware scanning) does fail, there's no denying that... specifically it fails to detect new/unknown malware, and that is an accepted and acceptable limitation... acceptable because no single technique can ever be effective against everything (thus necessitating other, complementary techniques) and new/unknown malware, though good for capturing media attention, is not quite as big a deal as it's made out to be... known malware vastly outnumbers new/unknown malware and new/unknown malware (especially that which affects many people, thereby posing a significant threat) generally does not stay new/unknown for long...

now, if known malware scanning really was as broken a model as some people like to think it is, why does a piece of malware's population growth start decreasing once it becomes known malware? it doesn't magically stop trying to spread (or in the case of non-replicating malware, the malware spreader doesn't automatically stop trying to spread it)... the population growth starts decreasing because it begins to fail to spread (or be spread)... the fading out of a particular piece of malware can take years, a decade or more in some cases (usually for reasons unrelated to a scanner's efficacy), all the while it's trying and usually failing to spread... potentially failing orders of magnitude more times than it ever succeeded - and those failures represent successes for known malware scanning...

if people thought seriously for a moment about the life-cycle of malware, about the relative deployment of various anti-malware technologies, and the implications they have for the notion that scanners are failing, falling behind, or just not working they'd realize that in fact scanners must be working far more than they're failing otherwise the population of a given piece of malware wouldn't go down... this is still very much an av world, most people use nothing more than scanners (if they even use that much), there aren't enough deployments of alternative technologies to stem the tide of the malware's spread...

scanning isn't broken or outdated or failing - malware would be a much bigger problem if it were... the notion that it is failing is just an erroneous perception based on an interpretation of incomplete facts...

sunbeltblog on patchguard

this is going to be another one of those totally out of character posts where i actually say nice things so get your protective gear on because the world might just end while you read it...

i was playing around with the idea of doing my own post on patchguard, inspired by some of the crazy notions i've seen bandied about on various security blogs (mostly those without any anti-malware specialization), but now i don't have to because alex eckelberry has absolutely nailed it...

he touched on all the right things, from the inevitability of failure of any given preventative measure, to the importance of flexibility when trying to deal with new threats... he even incorporated concepts of anti-malware strategy and tactics the likes of which i rarely see discussed but often aspire to myself...

bravo, alex...

Wednesday, October 18, 2006

ipod viruses

lots of people have been posting about the fact that apple let a virus slip into it's video ipod product line... a lot of them were rightly ticked off at apple's disingenuous attempt at passing the buck to microsoft for not making their OS "more hardy", and i could certainly parrot that sentiment if i wanted to be a parrot (it certainly wouldn't be the first time i held apple's feet to the fire over malware issues)...

but there's a small kernel of info that was shaken loose that doesn't really seem to have gotten the attention it deserves... see, as much as i enjoy finger pointing, i think this incident (and the similar cock-up by mcdonalds in japan) is an excellent object lesson for the average user about an old malware issue that has been all but forgotten in this day and age - that being that removable media represents a potential infection vector...

oh sure, nobody's making bootsector viruses anymore, and floppy disks are becoming extinct so the traditional threat we used to think of with regards to removable storage media is a non-issue, but removable storage media has evolved and the malware risk has evolved with it and in some ways gotten worse (autorun anyone)... the more things change, the more they stay the same...

if it can store data (like songs or video or whatever) then you should think of it as being as dangerous as a floppy disk used to be... whether it's an actual floppy disk or cd or dvd or flash/pen/thumb/usb drive or mp3 player or media player, so long as it's new to your system it needs to be scanned for malware before anything on it can be used or executed (and that means you should probably disable autorun - as inconvenient as that sounds)... otherwise you have to deal with things like worms infecting your pc as soon as you connect your shiney new ipod to it...

what is a boot sector virus

a boot sector virus (or boot sector infector, or BSI) is a is a virus that infects a special kind of program called a bootstrap loader...

pure boot sector viruses spread by way of shared floppy disks - when one person gave another person a disk with a BSI on it and the second person booted their computer from that disk (sometimes accidentally) the BSI would execute and infect the hard disk (if one was available - early computers didn't always have hard disks) and/or any flopply disks that were subsequently inserted into the computer during that session...

some viruses were able to infect not only boot sectors but also conventional programs like *.EXE files - these were called multi-partite viruses...

on PC's, contrary to a popular misconception at the time, BSI's were never able to infect the machine simply be inserting an infected disk, a virus always has to be executed or run in some way before it can do anything and boot sectors (infected or otherwise) only get executed during bootup... other mitigating factors for BSI spread were the introduction of BIOS options to prevent booting from floppy disks (generally by way of changing the boot priority to attempt booting from the hard drive first or exclusively) and to monitor changes to the master boot record and give the user the opportunity to prevent those changes... one of the final nails in the coffin of BSI's was windows 95 (and later) which prevented BSI's from being able to spread after the operating system had loaded (giving the viruses too small a window of opportunity to spread)...

back to index

Tuesday, October 17, 2006

the virus problem is solved... NOT!

years ago (in 1988 if i'm not mistaken) peter norton (of norton utilities fame) famously stated that computer viruses were an urban myth, like aligators in the sewers of new york... even though he didn't really have much to do with it's development, it's still quite ironic that an anti-virus product bearing his name (norton anti-virus) and at one point his likeness has become one of the dominant forces in the anti-virus industry...

now, john thompson (ceo of symantec, maker of norton anti-virus) is being quoted as saying that the virus problem is solved... if you're wondering - that would be the sound of my irony meter being blown to smitherines from an overload because after 18 years norton-related irony has come full circle...

i don't know what world john thompson is living in or what his special definition of solved is but it seems to me that if people are still having problems with viruses then the virus problem isn't solved...

the virus problem is fairly clearly not solved, so how are we to interpret claims that it is? well, one conclusion that we can draw is that if symantec thinks the problem is solved then they can't have any vision for future innovation in the anti-virus domain - after all, you wouldn't call something solved if you were still in the process of coming up with better solutions, would you?...

if they were just changing their focus to more socially engineered attacks like phishing and fraud instead of traditional malware as has been suggested (in spite of the fact that malware remains a great enabling technology for those other kinds of attacks), then why try so hard to divert attention away from the virus problem? why say something they know isn't true (and i'm pretty sure they know the virus problem isn't solved - they aren't dummies) unless there's something they're trying to hide (like a lack of vision, or perhaps a belief that they aren't going to be able to be nearly as successful in the av industry in the future as they are now)...

whatever's going on, saying the virus problem is solved is a statement that should engender mistrust, not just because it's blatantly false but because it's likely some kind of deception (like a magician or street hustler employing the art of misdirection so that you don't notice the trick)... something just doesn't feel right about it...

Monday, October 16, 2006

second life's 'grey goo'

i don't play second life myself (i don't know how people find the time) but i caught wind of an interesting story last week by way of boingboing.net about self-replicating objects inside the second life game...

pat yourself on the back if you think this is going to wind up with me labelling them viruses - but not too hard (you might break your spine) since this is a virus related blog...

yup, it appears that users can make their own objects in second life and code behaviours into those objects with a scripting language... that makes them, essentially, programs... and those second life objects that self-replicate? well they're self-replicating programs, which fits the academic definition of virus like a glove... apparently there are a number of different grey goo incarnations (since counter measures were developed and deployed) but i haven't found any descriptions yet that could be interpreted as a program infecting another program, so i would probably classify the grey goo as a kind of worm (more specifically i suspect it might qualify as a rabbit)...

one of the things about this that is interesting to me is that this is a departure from the other stories one often hears about regarding internet gaming malware... generally the malware one hears about is a password stealer or some other kind of spyware meant to enable the attacker to steal something of value... they're held up as examples of how malware today has become financially motivated (so-called crimeware)... as near as i can figure, however, there's no direct financial benefits to grey goo attacks - if anything they seem more like the vandalism stage of malware we used to have and perhaps it's good to remember that technically that hasn't really gone away yet (obviously)...

some folks may disagree with the vandalism charactization - after all, in the real world grey goo would qualify as a weapon of mass destruction... second life isn't the real world, however... the grey goo in second life doesn't consume other in-game resources like real world grey goo would (which makes it both more benign and in some senses harder to control) - the only resources second life grey goo consumes are the computing resources of the game servers, effectively executing a DoS attack on the game... nobody dies and nobody's in-game character dies; at most it really just brings the servers down and interferes with in-game commerce (which has apparently branched out into real-world commerce but interfering with that wouldn't really qualify as mass destruction)...

another interesting aspect are the counter measures that have been developed to combat the grey goo, particularly because they were developed in-house at linden labs (creators of second life) rather than by the anti-virus community and because they seemed have come up with familiar solutions in spite of not being part of the anti-virus industry and probably not even thinking of it as a viral problem... one blog commentor shudders at the thought of writing an anti-virus to address the problem and yet that's exactly what linden labs did with their grey goo fence... of course it's not what the average person would consider an anti-virus, it's not a signature based known virus scanner (perhaps because the anti-virus industry has done such a poor job of image control that the idea of creating a conventional scanner for this problem was anathema to the developers), it's a behaviour based system that triggers on excessive instantiation (rezzing) within a family of objects (too many children in too short a time is bad)...

one key thing to point out is that behaviour based systems (like all preventative measures) are not perfect and the grey goo fence is no exception... apparently second life requires objects to be able to instantiate other objects so some level of self-replication is always going to be able to get in under the grey goo fence's threshold... additionally it might be possible fool family membership evaluation (perhaps by socially engineered player intervention)... at any rate, the grey goo fence has failed and a new counter measure being suggested is limiting some of the scripting functionality required for self-replication so that only trusted individuals can make use of it - which is essentially a kind of whitelist... whitelists won't be a silver bullet either, of course, because there is a limit to the accuracy and scope to which one can objectively define trust...

it'll be interesting to me to see where this kind of in-game malware proceeds - whether truely infectious self-replication emerges, whether other types of malware-related techniques are employed... it almost makes me want to play the game and see it first hand... almost...

Tuesday, October 10, 2006

complete / total / full protection is snake oil

it's been a while since i last held a vendor's feet to the fire over advertising meant to instill a false sense of security - otherwise known as snake oil... well, i'm about to make up for that...

now, i want to make it clear that i generally don't go looking for anti-virus ad copy or marketing material, i grew out of that complete and utter bullshit a long time ago and as a result rarely ever see actual anti-virus advertisements (actually, i do my best to avoid advertisements in general because really it's all bullshit, but anyways)... i knew that misleading claims occasionally slipped into a vendors marketing material from time to time but clay (of claymania fame) brought to my attention the disturbing fact that snake-oil in the anti-virus industry is actually much more common than i had been aware or wanted to believe... on further investigation it seems to be fairly ubiquitous...

but before i really lay into them, let's start with the title of this post... we've know for a long time that 100% protection was snake oil, it was an impossible claim that obvious snake oil peddlars pushed on an unsuspecting public years ago until the community woke up and said we weren't going to accept that anymore... so then ask yourself does complete, total, or full protection represent a significantly different meaning than 100% protection? not as far as i can tell - they're the same thing just with different words in order to avoid the old snake oil alarm bells... it's not like we're talking about almost full, nearly complete, or just about total protection; these folks aren't saying that if you use their product you'll be 99 and 44 100ths percent protected, no it's complete/total/full/100 percent protection all the way...

so when mcafee creates a product whose very name is mcafee total protection they're lying to the public and their brochure that states "It offers comprehensive security that’s always on and always up to date—and the confidence that you are completely protected." is promoting a false sense of security - you are never completely or totally protected...

when sophos claims that "Sophos Anti-Virus Small Business Edition detects and disinfects viruses, spyware, Trojans and worms at every potential point of infection, ensuring networks and remote users are fully protected." they're telling you 'porkies' - you're never fully protected either...

when computer associates tells you they are "Providing Complete PC Protection from Internet Threats" they are full of hot air (or maybe something else - once again, you can't have complete protection...

when eset informs you "That means you’re purchasing more than antispyware software, you’re purchasing total-protection software. And peace of mind." they're totally full of it - because they certainly aren't giving you total protection...

when grisoft pronounces that they provide "Complete security protection against all of the most serious Internet threats, including viruses, worms, trojans, spyware, adware, hackers and spam." it is complete bunk - once again, there can be no complete protection...

when f-secure states that "F-Secure® Internet Security 2007TM provides a complete and easy-to-use protection against all Internet threats, whether they are known or previously unidentified." they're going completely overboard - complete protection against known and unidentified/unknown threats is nothing short of fantasy...

when panda software asserts that "The new Panda Internet Security 2007 offers the most complete protection so you can use the Internet with absolute peace of mind." they're actually setting you up with a double-whammy - complete protection is impossible so absolute peace of mind is entirely unwarranted... that brings up another type of misleading claim - the worry free protection... panda software really likes 'worry free' ("Browse the Internet, download any file you want, play online for hours... without any worries")...

they aren't the only ones, as trend micro clearly shows with "Trend Micro Antivirus can effectively remove viruses, email worms and Trojans that can destroy your data and files. You can use the Internet worry-free, knowing you’re protected from viruses in email messages, Internet downloads, instant messages, and removable disks."...

and norman gets into the act too with "This product combines the award winning Norman Virus Control and Norman Personal Firewall in one package to offer customers complete peace of mind while using the Internet." - no security program catches everything therefore no security program should be giving you complete peace of mind...

worry free protection that gives you peace of mind just another form of the install and forget snake oil that we've seen before and that bitdefender is proudly displaying here when they say "Ease of use and automatic updating make BitDefender Client Standard an "install and forget" antivirus product." - isn't it great how they even knew to highlight the offending phrase with quotation marks?

this isn't even all of them... i'm sure if i looked harder/longer i'd find even more vendors doing these (and similar) things... it's bad enough that the words protect and protection all by themselves suggest they're complete - you normally have to qualify their use in order to suggest anything less that complete protection - but to so blatantly do the opposite, making false claims and giving the public a false sense of security, and on such a large scale . . . . . words fail me... it makes me ashamed to admit to knowing anyone in the industry, and very glad i'm not one of them...

[edit - thanks for pointing out that the last paragraph was borked, clay... hopefully it no longer looks like the product of someone who was up way too late...]

Saturday, October 07, 2006

corrections for cytrap labs blog

here we go again... ok, this particular blog didn't accept my comment at all so instead of getting the text out of historical feed items for a comment aggregator feed i got them out of a backup i saved in google notebook (i backup my comments before submitting because i occasionally encounter problems during comment submission and need to resubmit)...

the article in question is Do not believe everything you read but you should reflect on it - anti-virus software tests which was about (you guessed it) the consumer reports controversy... my comment was as follows:
"This is more scientific than the test method used by Independent Security Evaluatiors (ISE) used by Consumer Reports to conduct these tests on its behalft?"

yes, retrospective testing is more scientific than testing with lab-made viruses... retrospective testing uses viruses from the real world while ISE's test used viruses meant to approximate those from the real world (ie. it simulated the processes by which viruses are created in the real world based on a variety assumptions which may or may not be valid)...

"A 40% detection rate in a retrospective test is seen as being pretty good for most anti-virus software because it means that it detects all the new malware appearing during 3 months by heuristics and generic detections."

??? 40% detection rate means it detected 40% of the viruses, not all of them... it's considered pretty good because most do much worse than 40%...

"Using currently-known viruses to measure the performance of older AV engines is based on the assumption that the viruses we know about today will be the same kind as those that we will see in the near future. Hence, what was unkown three months ago should be representative of new viruses in general?"

the only assumption here is your own that retrospective test results are supposed to be generalizable... the reason retrospective tests (and other tests for that matter) are performed over and over again is precisely because they are not individually generalizable and a general sense of how well a product does can only be gained from looking at trends across multiple tests...

"Just for the record, zoo viruses are commonly defined as “existing only in lab environments” and thus not ITW (in the wild) until leaked. If they only exist in lab environments, what might their origin be?"

just for the record this is an oversimplification of what zoo viruses are... they do not exist only in labs, they are simply believed to not be actively spreading in the wild... they can still exist all over the place, in vendor labs, in private collections, or in the hot little hands of those who simply haven't gotten around to trying to spread them yet...

"Further, where is the line to be drawn at “vendor created”? Vendors get viruses in various ways but sometimes provide compensation to people providing them (e.g., also called vulnerability research). Examples of this can be found in the Perrun JPEG virus proof of concept and the Commwarrior.a SymbianOS virus."

if those are supposed to be examples of viruses whose creators were compensated by the vendors then i think you need to provide some proof... although a certain famous name in the av industry is believed to have paid for viruses, that was a long time ago and those efforts helped him become a pariah in the av industry and community...

"The AVIEN open letter:
>Public letter concerning the Writing of Viruses & How it Does Not Teach about Virus Prevention (May 30, 2003)
is not necessarily very helpful. I even wonder why some of these well known av industry representatives let their name stand on this letter."

consider reading the signatures more closely - they are not just av industry representatives, there are lots of people on the list that are outside of the av industry...

" > “…it is not necessary and it is not useful to write computer viruses to learn how to protect against them.”
One could interpret this statement as saying something similar to: trust us we know best and do not need to explain ourselves to people like you."

or you could interpret it as simply the result of a great deal of online discussion that occurred elsewhere (in multiple venues)... petitions generally don't include all the conversations and arguments that lead up to their creation...


and that pretty much covers all the corrections i have saved up... for now...

corrections for the virus alert blog

i'm always on the lookout for good new sources of malware and/or security information, especially blogs (growing a security blogroll as big as mine doesn't just happen, y'know)...

now sometimes i find a good one and sometimes i find one that could use a little work... the virus alert blog is one that that i thought could use a little work so i offered some corrections to a couple of articles that i felt held the most misinformation... i don't think the comments i left were overly critical, more just corrective... certainly not something anyone should take offense to - but apparently offensive enough for them to be taken down without explanation or correction to the articles in question...

well, isn't that just dandy then... y'know, i respect the right of a blog owner to decide whether or not s/he wants to accept feedback from others... look at me, i've disabled comments here in part to avoid comment spam but also to avoid being engaged in complex debates in a medium that frankly just wasn't designed for it (which is why i point people to alt.comp.virus and alt.comp.anti-virus)... i still accept feedback, mind you, and even make corrections from time to time based on that feedback, just not in the form of blog comments... but if you're going to allow comments then allow comments, don't disappear them...

whatever... thanks to my use of comment aggregation (via co.mments.com) and a feed reader that keeps track historical feed items i have the full text of my comments to share with you...

the first article was Computer Virus Myth #5 which basically said getting infected by viewing a web page was a myth and not possible... my response was as follows:
By kurt wismer. October 5th, 2006 at 7:59 am

while it would ideally be true that you cannot become infected just by browsing to a web page, the reality isn't so simple…

there are multiple examples of malware getting executed on a host machine simply because a user browsed to a malicious website - adware and spyware do this all the time so there's no reason why a virus can't do the same… if the virus can get executed (and the spyware example you yourself acknowledge proves that software can get executed under this scenario) then the virus can infect the machine…

in fact, one type of instant messaging worm spreads itself by sending messages to your IM contacts containing nothing more than a link to a malicious website which, when visited by your contacts launches the viral on their machines…

so long as there is java, javascript, activex, flash, shockwave, and any number of other active content web technologies out there (not to mention vulnerabilities that allow arbitrary code execution), any kind of malware can get executed by browsing to a malicious page - and for viruses that means they get the opportunity to infect…
("launches the viral on their machines"? looks like i missed a word - should have been "launches the viral code on their machines")

the second article was The 3 Main Types Of Computer Viruses which lists trojans, worms, and email viruses as the 3 main types of (ahem) viruses... my response was as follows:
By kurt wismer. October 5th, 2006 at 8:35 am

this really begs some corrections…

first and foremost - a trojan isn't any kind of virus… although viruses can often be considered a kind of trojan, the reverse does not hold true… the fundamental requirement for a virus is that it self-replicates and there's nothing in the definition of trojan horse programs dealing with self-replication…

worms can be considered viruses but generally only in the academic sense (whereby the mathematical definition of virus used in formulating proofs includes all self-replicating programs)…

email viruses are more accurately referred to as email worms… the tradition with viruses is that they are classified by what and/or how they infect (what: boot sector viruses, file infectors, macro viruses, etc - how: overwriting infectors, appending infectors, companion infectors, cavity infectors, etc)… "email" is neither a 'how', nor a 'what' (since email is not any kind of program it cannot be infected, it can only serve as a container), it is a transport medium (which is how worms are generally classified; email worms, IM worms, IRC worms, P2P worms, etc)…

Tuesday, October 03, 2006

google search malware warning

a while ago (2 months?) google added a malware warning feature to their search engine that utilizes the stopbadware.org project and looks a little like this


i only saw it first hand for the first time today (despite being an avid google user) and i already have concerns...

the first is that you don't see the warning until you click on the result from their results page... why not save the user some hassle and just mark up the results page like siteadvisor does? i mean, really, it shouldn't be that hard (it might make siteadvisor redundant, however)...

the second is worse, however... of the options it gives the user for continuing from the warning page, the easiest one for the user to choose is to go on to the bad site... this is backwards - if google really wants to help people they should make the safest option the easiest one to choose - that means it needs a backlink, a box to enter a new query, and something that makes it more difficult to click on the mal-link like a checkbox that says "i understand that the site contains badware and want to visit it anyways" that must be checked before the mal-link can be click on...

come on, folks... this is basic secure UI design, surely all those big brains in the googleplex understand such a basic principle as making the right choice the easiest choice...

Thursday, September 28, 2006

diebold voting machine viruses

i saw a lot of articles about the recent research done on the potential for malicious code injection and vote stealing on the diebold accuvote ts voting machines but there was one kind of article i was expecting but never saw...

you see, the researchers claimed to have created a virus for the voting machine as part of their research - so where's the outcry from the anti-virus community about that? there doesn't seem to be any (and i have web searches on virus/worm/trojan/{as many other malware terms as i can fit in a search query} redirected to my feed reader so i'm pretty sure i would have seen something if there was something to see) and that seems kind of peculiar when compared to the reaction to the consumer reports av tests...

what could be the cause of the silence? do they only care about virus creation when it serves as a handy way to deflect criticism that makes the vendor's product look bad? the fact that vendors whose products weren't tested by consumer reports also raised a stink about the virus creation, and the fact that the anti-virus-writing public letter most often cited was originally in reference to a university course that advertized virus writing as part of the curriculum, both suggest that the community's concern over virus writing is not as narrow and self-serving as the nay-sayers would have you believe...

maybe the security researchers involved in the voting machine virus creation are somehow beyond reproach? well, some people thought the security personalities involved in the consumer reports test were beyond reproach too, so that shouldn't be it either...

maybe the technical circumstances of the voting machine virus nullify the threat it poses? [sarcasm] because a virus that can only infect voting machines (that run windows) wouldn't really be a threat to the public if it fell into the wrong hands - it's just a threat to democracy... [/sarcasm]

well, i'll tell you what - i can't speak for anyone else in the anti-virus community, but if they're anything like me, maybe they just didn't know what to think at first, and as time wears on it becomes easier and easier to just let it go... when i first read the headlines i wasn't sure what to think - on a very basic level i felt uneasy about it but i wasn't sure if that was just a knee-jerk reaction so i waited for some anti-virus type who knows more than me to provide some analysis (or even an opinion) that would at least shed some light on how other people in the community felt about the whole thing... nothing doing though, so i've had to mull it over myself and i've come to the conclusion that my knee-jerk reaction was right...

the fundamental arguments against writing viruses for supposedly good reasons are a) there are inherent risks and social costs (unless you're able to ensure that no one ever finds out about it or encounters it) , and b) there ways to get the same results without creating a virus and thus without the problems in (a)... both of these apply in this case...

the risks are that the virus will fall into the wrong hands (either accidentally or on purpose) and affect people and as smart and trustworthy as the researchers may be, no one is above reproach (saints have been known to kill people), no one is beyond making errors... the risks remain no matter who is involved and the impact here could be dire, subverting the democratic process (even just for a single country) can a affect everyone... add to that the social costs of telling people who really have no business handling viruses let alone creating them that virus creation is a legitimate research practice... sure it might also embolden smart people to do good research too, but considering the persistent and autonomous nature of the threat that a self-replicating program poses (it can keep going and going long after anyone involved in it's creation or spread has lost interest and moved on) it really does only take a few bad apples to ruin the bunch...

that brings us to the issue of there being ways to get the same results, in this case being able to prove the same things, without creating a virus... i've already shown that this is possible in the general case and in this case in particular the researchers state quite clearly that the voting machines are general purpose computers (that makes viral susceptibility a forgone conclusion)... in fact they've made it clear that the machines run a version of windows, so there's absolutely no reason to create a virus for this platform since just about everyone knows that windows and viruses go together like peas and carrots... unless you want your new nickname to be 'captain obvious' there's no need to prove a virus is possible on this platform and so no need to create one for their security proof...

so if there was no need to create a virus, if you could demonstrate everything you needed to demonstrate with non-viral code (and you could), then the ends can not justify the means - the risks, however small they may be, remain present and the social costs are completely unmitigated... i don't want to bash the researchers too much (i do that an aweful lot) especially since there was a question (at least in my mind) about whether or not the ends might really justify the means in this particular virus-creation case (by gosh, democracy was at stake), but creating an actual virus (and by their description it was an actual virus, basically a kind of boot infector) was a wrong-headed thing to do...

how to prove 'virus-ability' without creating a virus

let's say you're a security researcher and you're trying to demonstrate some security problem that involves viruses... it's relatively easy to write your deomonstration code as a non-replicating proof of concept exploit and simply say "this could easily be attached to a virus" and leave it at that - it's perfectly true that it could be attached to a virus, any function you like can be added to a computer virus, they're just programs after all...

that's all well and good if you're dealing with a normal desktop pc or some other platform for which we already know viruses are possible, but what if you're dealing with a system where viruses are as yet unheard of like an internet connected toaster, an assembly line robot, or an electronic voting machine? it may not be enough to just assume viruses are possible on such platforms, of course, because the proof you were trying to construct for the existence/feasability of whatever threat you were trying to demonstrate won't really be much of a proof anymore... you could try proving that the system in question satisfies the requirements of a general purpose computer, after all virus infectability is inherent to the general purpose computing platform, but that's probably going to go over most people's heads...

so try this instead: first show that you can introduce your own code into the system and get the system to execute it, then show that the code you introduce can write a secondary program (like a hello world program) to the systems storage memory and execute it... at this point you've proven self-replication is possible on the system, because if your main program can write a secondary program to the system's storage memory it can also write a copy of itself there...

now, let's say you want more than just basic self-replication, lets say file infection... have your main program do one of the following: write it's secondary program overtop of an existing host program on the system, rename an existing host program to something else and then give your secondary program the name the host program used to have, or change whatever pointer the system used to locate the existing host program so that it points to your new secondary program instead... you have now demonstrated the potential for file infection and so far have still not created a virus...

but wait, there's more - what if that's still not enough (and lets be honest, messing around with a single computer system doesn't really have the impact it used to), what if you need your hypothectical virus to spread to other systems over a network (a network worm)?... this too is relatively simple, instead of having your main program write a secondary program to the local computer's storage memory, have it send the secondary program to a second system along with whatever tricks you need to get the second system to execut it... this demonstrates network spreading because your main program could have just as easily sent a copy of itself rather than a dummy program.... and if you want it to have some real visual appeal, make your hello world program print "i'm infected" instead of "hello world"...

at this point you'll have demonstrated all of the viral characteristics that would be necessary for your larger security proof without actually writing a virus, therefore making the writing of viruses for security proofs (even security proofs for computing platforms for which real viruses are unheard of) unnecessary...