IT Security Blog

Just about anyone and everyone who is active on the internet is either using, has used, or at least has heard of Twitter, the micro-blogging service that grew in usage by 752% in 2008 and is poised to grow even more in 2009. 

As we know, where there are users, there are hackers.  Any technology that has grown in popularity at the speed of which Twitter has is certain to become a target for information and money stealing cyber criminals.  As such, Twitter has been the target of several application exploits over the last few months including a Samy-like exploit which would force users to follow you, multiple Clickjacking exploits, and two worms dubbed Mikeyy and Stalkdaily just this past weekend.
Funny enough, one of the things that is frequently part of the fallout of numerous security exploits is a drop in brand trust and user confidence.  So far, that fallout does not appear to have taken place with Twitter.  At least based on the reported numbers, Twitter's growth does not seem to have been hampered at all despite the numerous security flaws that have been patched over the past 8 months.  Perhaps this is because there hasn't been a serious incident of data theft or widespread malware infection as a result of one of these exploits.  Rest assured, those are coming!

So, what can we learn as a result of Twitter's recent security woes? 

I believe that one of the most important lessons to be learned from Twitter is the need to ensure security is being built into your product from the concept and design phases, not after the code has been consumed by the public.  This is true for online applications like Twitter as well as boxed software that you buy in the stores.  Don't let your customers be your test bed to identify security risks because you can bet that criminals will find them and exploit them before your customers do.  At that point you have put your customers at risk also.  It is far cheaper and less damaging to your corporate brand and reputation if security risks are identified up front, before any code is launched than to try to retrofit security into a live product.

Up to this point the vulnerabilities exposed on Twitter have largely been considered annoyances.  I was unable to find any reports of identity or financial theft as a result of a Twitter exploit, and again perhaps that is why they haven't been placed under the same microscope that Microsoft and Google have been.  Don't take these proof-of-concept quality threats lightly though as they could easily have been much more nefarious than they were.

Let's take the Mikeyy worm as a primary example.  One of the ways that Mikeyy would spread is by sending Tweets out under the accounts of infected users trying to lure their followers to visit the profile of another Twitter user that exploited a site flaw.  Once that page was visited the user's account was hijacked and Tweets would be sent out as them to their followers trying to trick them into clicking also.  Rinse and repeat.  In this instance the worm was merely spreading out across Twitter to anyone who was fooled into clicking the link presented in the Tweet.  What if this link was forwarding unsuspecting users out to a drive by malware site that installed malware like Storm or Conficker?  In a previous post we discussed how URL abbrevation services can potentially hide an underlying threat vector to redirect users to malware drive-by or phishing sites.  Granted, that example isn't one of a specific Twitter flaw, but it is just another thing that users of the popular service need to be on the lookout for.

In its short existence Twitter has almost single handedly revolutionized how we communicate (in 140 characters or less :) ) online.  Whether you are using Twitter to communicate with friends from school, family, or professionally to keep up on market trends or as another method to increase your brand awareness (a recent report by comScore said that more than 50% of Twitter users are between 25-54 with most users being on the upper end of that scale), Twitter has stormed onto the social media scene and has already become an important part of how people communicate online.  I use it myself.  As such, it creates another avenue by which we need to make sure we educate ourselves and our users about the potential for online threats.

I have been starting to feel like I have hardly been in the office over the past month.  After attending MAAWG in San Francisco for a week in mid-February I was in town for a week and a half before going on an extended vacation/business trip to Orlando for InfoSec World 2009 and some time visiting my wife's family.  I am finally back in town and expect to be so for about the next month until RSA rolls around in late April so expect to see regular blog updates rolling out again.

I wanted to take a few minutes to talk about something that has kind of been bothering me lately.  It is something that I have been hearing more and more of in passing conversation as it relates to browser security, in particular between Firefox and Internet Explorer.  Similar to the debates that have been raging for a few years now between the "security" of Apple's OS X (and previous versions) as compared to Microsoft Windows are debates between how using Firefox is a more secure browser than Internet Explorer. 

Is it, really?  Or Is it just a matter of perception? 

At the end of the day, the level of security of any application installed on our computer is a combination of the vendor's ability to release timely updates to address new security issues, and the user's ability/willingness to install those updates.  The discussion about application security is completely irrelevant if user's do not install the updates that the vendor provides. 

Take this recent analysis of the Conficker worm/botnet as an example.  According to the report, more than 90% of the users who got infected with Conficker got infected while using Internet Explorer 6, the default browser that comes with Windows XP.  Windows XP is also the OS that has the highest concentration of infected Conficker users, but that is to be expected as it is currently the most deployed Windows OS version.  What this tells me is that many users who are running Internet Explorer 6 are not keeping it up to date with updates and patches.  This is also somewhat to be expected because the largest concentration of infections are in countries like China, Brazil, Russia, and India who also have some of the highest numbers of pirated copies of Windows in the world.  You could argue that this might not be the best example of browser security because Conficker is an exploit for an OS level vulnerability, but the reasoning is still sound in that if you aren't applying OS patches you likely aren't patching your browser either.  If you aren't familiar with the "insecurity iceberg" report, I would recommend it.  It is a good read as it outlines browser and plugin usage across many different data cross-sections to illustrate that browser security is about more than just the browser.  It also includes the many plugins that are available such as Adobe Flash, Java, Apple Quicktime, and Adobe PDF Reader. 

So, to go back to my original question, is Firefox really more secure than Internet Explorer?  In addition to my previous argument about patching, I believe this also comes down to an issue of perception.  For example, Firefox releases security updates more frequently than Internet Explorer.  Does that make it more secure or less secure?  Additionally, Firefox has a "nagware" type of feature where it regularly throws popups at you when a new version is available encouraging you to upgrade to the latest and greatest version of the browser.  This gives the impression to the user that they are being kept safer.  Second, Firefox has an active community of developers creating plugins for Firefox that help create additional security features on top of what the browser already provides.  Neither Firefox nor IE have any native protection against what is known as Clickjacking.  With Noscript, a plugin available for Mozilla based browsers like Firefox (et al), Clickjacking protection can be added.  IE currently has no protection available although it is being planned for IE 8.  Another security threat that I have written about previously is the danger that can be introduced by URL abbreviation services like TinyURL and SnipURL.  Firefox has a plugin that will allow users to preview where these abbreviated URLs will really take the user before they click the link.  URL abbreviation services are being used more and more by phishers and malware creators to trick users into clicking on legitimate looking links and redirecting them to malicious web sites.  So, there are security related addons that users can plug into their browsers if you know what the good, actively maintained ones are and know where to look, but this functionality isn't native to the browser and leaves the user with having yet even more software to have to update.

You could make analogies between the OS X and Windows debate here too.  Apple users claim they don't have the malware problem that Windows users have.  In sheer volume of released exploits, this is certainly true, however you are also dealing with a much smaller market share.  Is the reason that Firefox exploits haven't been more widely targeted that they just don't have the market share to support the effort on the part of cyber criminals? 

My point is that there are compelling arguments on both sides of the browser security war debate, but at the end of the day is onus is still on the user to make sure their software (includes both browser and plugins!) is patched regularly, and that they are employing additional security measures like anti-virus and outbound traffic blocking firewalls to reduce their risk.  More online threats are moving to the browser every day so having multiple layers of defenses in place at different points of the network remains your best method to minimize risk. 

ClickJacking.  One of the newest and most talked about, yet at the same time one of the most secretive new buzz words in Internet Security.  Clickjacking is actually a rebrand of what was originally called "UI Redress".  I guess ClickJacking was considered a sexier term.

What is it? 

Don't get me wrong, the concept of ClickJacking is not new.  The term has been floating around for about a year now.  Jeremiah Grossman and Robert "RSnake" Hansen were supposed to give a talk about it at the OWASP NYC Appsec conference, but were asked by people at Adobe to not give the talk as the vulnerability affects one of their products.

Essentially what ClickJacking entails is using iframes and web page layers in DHTML such that you overlay a potentially malicious button (for example) on top of an existing legitimate web page button such that when a user clicks it they believe they are clicking the legitimate button instead of your malicious overlay.  This all happens transparently to the user.  At this point the users click on the button has been "ClickJacked"

Since ClickJacking does not require Javascript (as so many of today's other web based attacks do) using plugins like NoScript will not provide any relief.  In Firefox you can turn off iframes, but this is a global setting, not a per site setting.  So, if you turn off iframes in your Firefox config you've now disabled them for every web site, and there is no telling what you could break on how a web site is supposed to render if you do this. 

In case you are interested there is a fairly detailed write up here that defines the problem and why it is difficult to fix.  It also outlines some potential solutions, all of which have their positives and negatives.  It's fairly wordy so if you don't generally like to have to hack through the technical weeds of a problem you may not find it interesting.

ClickJacking is an interesting problem to address because right now so little is known on a wide scale about what the issue is and how to identify whether or not your application is being compromised.  Additionally, there are virtually no tools to assist web site designers to protect themselves.  I am sure that will change as more is learned about this type of attack, but typically those tools are developed well after the attack vector is being actively exploited.  It's too late then.  That's like installing the burglar alarm after your house has already been robbed.

Although it is nice that Adobe wants details withheld until they can patch the vulnerability within their own application, that does nothing for the other web site application developers who will be playing a serious game of catch up after the fact...