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