Saturday, March 31, 2007

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

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

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

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

Monday, March 26, 2007

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

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

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

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

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

kaspersky spread FUD about the mobile malware threat - in the original article the kaspersky folks make it clear that you may well not be very likely to see mobile malware in your home country... the dependence on the regional market penetration of susceptible devices (smart phones) on the extent of the risk has been well established..

kaspersky took a news crew into a faraday cage in order to make them understand that mobile malware was a real threat - no, they took them in the faraday cage to demonstrate how cabir works...

cabir is only a threat when you intentionally ignore the warnings - this is the oft cited yes/no prompt that people consistently think should mitigate the mobile malware threat even though it has been well established that the 'no' button doesn't work (the worm just sends itself again immediately so the prompt comes back as soon as you hit 'no'... if you need to make a phone call your only real options are to hit 'yes' or get out of range of the other infected device because you can't use the phone while the prompt is there)...

kaspersky has suggested that mobile malware is common - again, read the original article, you'll find they don't make that claim at all... they do say that there are certain geographic locations where it's more common than others, though...

kaspersky could have just found someone with the virus instead of taking the news crew inside a faraday cage - yeah, an anti-virus company is going to demonstrate the functioning of a piece of malware that is epidemiologically equivalent to an airborne biological pathogen without the protective measures necessary to keep it from spreading beyond their control... now pull my other leg...

Tuesday, March 20, 2007

the folks at panda have floated a question on their blog... it's an interesting question but since they don't seem to have any comment feature available on their blog there does not appear to be any direct way to give them feedback on the question...

in simple terms, given a file format that supports a feature heavily abused by malware purveyors, should anti-virus companies be detecting instances of that filetype where that feature is actually being used and if so what do you tell people who use that feature legitimately?

my answer is yes, absolutely, add detection for files using features known to be abused by malware... of course years ago i was also completely in favour of having anti-virus products detect the MtE mutation engine in spite of the fact that (according to dr. solomon) some knucklehead (my words) was using it legitimately in a code obfuscation product... i don't think i managed to change dr. solly's mind on the matter, though...

now this new case would probably mean some interesting things when it comes to office documents... and then there's html files with embedded scripts... oh, and it would be really cool (though i doubt many would agree) if you could detect multi-media files that make use of digital rights malware technology..

ok, so maybe you have to stick to the format-features that are seeing widespread abuse right now (i still think drm would apply, but anyways) but this is absolutely a worthwhile thing to do - widely abused format-features represent significant risk and tools need to be available to manage (ie. avoid) that risk... that's what you tell the people using those format-features legitimately...

alternatively, don't approach this as something for a virus scanner to naively detect (ie. an entry in the blacklist) but rather as a context in which to apply some sort of whitelisting so that people can add authorization for trustworthy content providers... or hey, why not combine the two - treat such files as potentially unwanted objects or greyware that you detect but include the ability to add exclusions for certain types of content... i think you'll find that files utilizing such widely abused features fit reasonably well into the greyware classification...

Monday, March 19, 2007

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

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

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

Saturday, March 10, 2007

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wednesday, March 07, 2007

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

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

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