It has been a while since we've seen a fast spreading worm affect a significant volume of victims. This past week however a new variant of Conficker (aka Downadup) reportedly infected millions of Windows machines. So called 'big bang' worms have largely faded from the headlines not so much for technical reasons but rather for both procedural and motivational reasons. On the procedural front, we've shortened patch cycles and locked down external access to/from networks. From a motivational standpoint, attackers have decided that 'big bang' worms don't meet their needs. Attackers have real financial motivations and drawing media attention to their efforts is not generally conducive to increasing revenue. Attacks have tended to be increasingly stealthy in nature. Why then has Conficker suddenly been so successful? Not surprisingly, the answer relates to weaknesses in enterprise defenses and ingenuity on the part of the attackers.
Enterprise Defenses
Patch Management - It would appear that patch cycles aren't so foolproof after all or at least there are still adequate numbers of end users that are not patching machines in a timely fashion. Conficker uses a vulnerability (MS08-067) that was patched nearly three months ago as its primary attack vector. Now a significant potion of unpatched machines may represent home as opposed to enterprise users but if you're looking for willing zombies with broadband connections, there's no need to be picky. Some are using the success of Conficker to call for mandatory patching.
Network Shares - Should vulnerability exploitation not succeed, Conficker then looks for network shares with weak passwords. While enterprises have significantly locked down the network perimeter over the years, the LAN itself is typically wide open. End users are freely permitted to open network shares and password strength is not enforced. Companies need to realize that it takes only one infected machine to infect an entire network. When the majority of computers are laptops that leave the corporate fortress regularly, having a single infected machine is almost a given.
Attack Techniques
Multi-faceted - Conficker is a hard working worm. It attempts to exploit machines vulnerable to MS08-067, spread via network shares and even connected removable storage devices. While leveraging multiple attack vectors is not a new technique for malware writers, Conficker's authors were wise to choose paths covering a lot of ground. Rather than just hammering away at a list of known vulnerabilities which are likely all exposed or all patched, Conficker instead tries exploitation, brute force and piggybacking.
Dynamic Domain Names - Once infected, Conficker attempts to contact other attacker controlled machines in order to retrieve additional code. Rather than simply using a round robin of hard coded domain names or IP addresses, Conficker instead has the ability to contact thousands of potential domain names. Those controlling Conficker can use only specific names and ignore others. Taking down all of the domain names would be time consuming and in most cases a waste of time as they may never be used.
Is Conficker an anomaly or a sign of things to come. While I don't expect to see a resurgence of 'big bang' worms, I do expect malcode authors to learn from the successes of Conficker. In the meantime, grab the latest copy of the Microsoft Malicious Software Removal Tool to ensure that you're not infected.
- michael
Sunday, January 18, 2009
Friday, January 9, 2009
IRS works to prevent identity fraud this tax season
The IRS has released six new security and privacy standards aimed at ensuring authorized IRS online e-File providers handle tax filers' data with care. This is definitely a good move, as I'd like to believe that e-File provider web sites make juicy targets for attackers; an attacker would have a smorgasbord of social security numbers, bank account numbers, financial profiles, and all other supporting information necessary to commit identity fraud.
The abbreviated summation of the new standards:
As an aside, I also ran across this related press release from Verisign. Basically they talk about how the IRS has mandated the use of EV-SSL certificates. More interesting is that it states "More than 7,000 Web sites already rely on VeriSign EV SSL Certificates." It's unclear whether that's 7,000 *tax-related* web sites (doubtful), or 7,000 web sites total (more likely). I'm assuming the latter, and as such, I'm a bit surprised at how few EV-SSL certificates have been issued over the last two years (EV-SSL was announced in late 2006). It seems a lot of sites are just not buying into EV-SSL...yet?
Until next time,
- Jeff
The abbreviated summation of the new standards:
- Use extended validation SSL certificates (EV-SSL), with a minimum of 1024-bit RSA and 128-bit AES
- Weekly external vulnerability scans, following PCIDSS standards and using a US-based PCI ASV (Approved Scanning Vendor)
- Accessible privacy and safeguard policies available on the web site
- All submissions must be subject to a "challenge-response test" (i.e. CAPTCHA)
- The system(s) must use a registered domain name with a US-based ICANN accredited registrar, and ensure the domain name is locked against transfers and the registration information is publicly available
- Any discovered security incidents must be reported to the IRS within 24 hours after incident confirmation
As an aside, I also ran across this related press release from Verisign. Basically they talk about how the IRS has mandated the use of EV-SSL certificates. More interesting is that it states "More than 7,000 Web sites already rely on VeriSign EV SSL Certificates." It's unclear whether that's 7,000 *tax-related* web sites (doubtful), or 7,000 web sites total (more likely). I'm assuming the latter, and as such, I'm a bit surprised at how few EV-SSL certificates have been issued over the last two years (EV-SSL was announced in late 2006). It seems a lot of sites are just not buying into EV-SSL...yet?
Until next time,
- Jeff
Modern Graffiti
I've said before that attackers provide great insight into the evolving uses of technology. For the past decade or so the digital equivalent of graffiti has been website defacements. The past week has seen thousands of primarily Israeli sites defaced as a result of the current Israeli/Palestinian conflict. Defacements are the low hanging fruit of web security as it requires minimal skill to succeed. When your target isn't specific (i.e. any Israeli website), given the sorry state of web security, it is trivial to find a vulnerable victim using freely available scanning tools. For this reason, defacements tend to be the domain of script kiddies and are used for the same reason that physical graffiti is used - to get a message across, be it political, religious or just mischevious. However, as communication mediums are evolving, so too are the chosen targets for electronic graffiti, as was demonstrated this week by two very public attacks, on Twitter and the popular MacRumors live blog.
Twitter saw 33 'celebrity' accounts hacked with content added that was either meant to be mischevious, such as the breaking Fox News report on Bill O’Reilly's sexual preference, or intended to generate revenue as did several which included links to affiliate sites. 'GMZ' a member of the Digital Gangster forum was reportedly responsible for the attacks and used a simple dictionary attack on the Twitter administrator account of a user named 'Crystal'. The attacks succeeded because Twitter did not lock out successive failed login attempts - something they have now implemented.
The MacRumors hack came at a most inopportune time - during live coverage of the annual Macworld Expo keynote. At 9:24 am, an unintended post, which obviously caught the bloggers by surprise, suddenly announced that Steve Jobs had died. Shortly thereafter the entire live blog had to be shut down as the attackers eventually began flooding the blog with unwanted comments. Details of how the attack succeeded have not emerged but rumors suggest that this too resulted from guessed/stolen password credentials. Comments on the 4chan forum also suggest that members from that community were involved in the attack. That is the same forum where details of the attack on Sarah Palin's email account first emerged.
What should we learn from this? From a technology perspective, eyeballs are moving toward real-time content. Our society has long sought instant gratification and micro-blogging services such as Twitter are benefitting. What's more real-time than a quick comment from my phone letting the world know what I'm doing at every second of my exciting life that I'm sure people simply can't live without. From a security perspective it's sad to see that after decades we're still using the single factor authentication provided by passwords for sensitive accounts. To make matters worse, these passwords were obviously implemented with poor policies and perhaps even shared. These accounts deserved to be hacked and the attackers (hopefully) taught Twitter and MacRumors a needed and embarassing public lesson. Let's hope they learn.
- michael
Twitter saw 33 'celebrity' accounts hacked with content added that was either meant to be mischevious, such as the breaking Fox News report on Bill O’Reilly's sexual preference, or intended to generate revenue as did several which included links to affiliate sites. 'GMZ' a member of the Digital Gangster forum was reportedly responsible for the attacks and used a simple dictionary attack on the Twitter administrator account of a user named 'Crystal'. The attacks succeeded because Twitter did not lock out successive failed login attempts - something they have now implemented.
The MacRumors hack came at a most inopportune time - during live coverage of the annual Macworld Expo keynote. At 9:24 am, an unintended post, which obviously caught the bloggers by surprise, suddenly announced that Steve Jobs had died. Shortly thereafter the entire live blog had to be shut down as the attackers eventually began flooding the blog with unwanted comments. Details of how the attack succeeded have not emerged but rumors suggest that this too resulted from guessed/stolen password credentials. Comments on the 4chan forum also suggest that members from that community were involved in the attack. That is the same forum where details of the attack on Sarah Palin's email account first emerged.What should we learn from this? From a technology perspective, eyeballs are moving toward real-time content. Our society has long sought instant gratification and micro-blogging services such as Twitter are benefitting. What's more real-time than a quick comment from my phone letting the world know what I'm doing at every second of my exciting life that I'm sure people simply can't live without. From a security perspective it's sad to see that after decades we're still using the single factor authentication provided by passwords for sensitive accounts. To make matters worse, these passwords were obviously implemented with poor policies and perhaps even shared. These accounts deserved to be hacked and the attackers (hopefully) taught Twitter and MacRumors a needed and embarassing public lesson. Let's hope they learn.
- michael
Wednesday, January 7, 2009
Buffer Overflows Are Injection Vulnerabilities
I admit it: I have a hard time getting excited about 0-day. Defense against the concept is fascinating (trying to detect exploits for vulnerabilities that haven't been written yet, for example, is way cool). New attacks are important to respond to ASAP, and may change the current wisdom about what's safe, so security geeks (including me) need to pay attention to what's happening. It's just that the details of individual exploits of specific vulnerabilities in specific software are both soporific and depressing: after a while, all the different attacks and vulnerabilities start looking alike. How is it that we are still making the same mistakes, over and over? And how is it that we are continually astonished when the same attack techniques work on the same mistakes, over and over?
In the interests of making everyone else as bored & jaded as I am, and perhaps even helping increase common knowledge, let me start by explaining why vulnerabilities to cross-site scripting and buffer overflows are instances of the same abstract problem: injection vulnerability.
It's pretty common to categorize cross-site scripting (XSS) and, say, SQL injection or format string exploits as injection attacks. In all of these cases, Mallory puts control codes where the developer is expecting data. A system will be vulnerable to an injection attack if and only if all 3 of the following interrelated conditions hold:
a. A data and control channel are mixed in the same communications medium.
b. Untrustworthy data is added to the data channel.
c. The mechanism intended to separate data & control channels is either insufficient or (more frequently) insufficiently applied.
Here's the run-down of these conditions for XSS in HTML:
a. An HTML document contains interleaved tags and attribute labels (the control channel), and their values (the data channel).
b. In most if not all interactive Web applications, user input (always untrustworthy, whether it is taken from this request or some persistent store) is displayed in the HTML document.
c. The mechanism for separating data & control channels in HTML is encoding according to the HTML specification; HTML is well-defined and this mechanism is sufficient.
Since embedded markup is part of the fundamental nature and appeal of HTML, not to mention a long-standing standard, nobody is about to change (a) and the usual recommendations for avoiding vulnerabilities to XSS correspond to eliminating (b) and (c):
b. Validate input (i.e. ensure it is trustworthy).
c. Encode input for the appropriate context before displaying it (i.e. use the mechanism for separating the data channel from the control channel).
It's less common to think of a buffer overflow attack as an injection attack, but here's the run-down of the injection vulnerability conditions for a buffer overflow on the stack:
a. The stack contains interleaved stack frame structures (the control channel) and local variables, parameters and the like (the data channel).
b. Almost any application touches input from outside itself (untrustworthy data), and almost any application puts the input it is processing into function parameters and local variables.
c. The mechanism for separating data & control channels on the stack is size-based; the stack is well-defined and this mechanism is sufficient.
As you can see, it's a match. If any of these conditions does not hold, stack-based buffer overflows are not possible. For purposes of avoiding the vulnerability, the important thing isn't the kind of control information the attacker can insert (HTML vs. pointers and machine instructions), or the mechanism used to separate data & control channels (encoding vs. size), it's preventing the data channel from leaking into the control channel.
As one would expect, the usual recommendations for avoiding vulnerability to stack-based buffer overflows eliminate one or more of these conditions :
a. Separate data and call stacks. (Actually this is relatively uncommon recommendation, probably because calling conventions are a pretty low-level interface to be changing.)
b. Validate input, e.g. confirm that strings are actually null-terminated. (Of course, by the time it's input to a function that would want to do the validation, you frequently don't have enough information to tell whether the null terminator occurs within the bounds of the memory that was allocated for this variable, so in practice you need to decide on and check invariants at the time the data is output to the variable.)
c. Use safe functions, i.e. those that have length arguments or otherwise include length checking (i.e. use the mechanism for separating the data channel from the control channel).
b and c. Use an interpreted language. (Many interpreted languages put object IDs (frequently pointers) on the stack instead of the original data; if the object IDs are not controllable from outside, no untrustworthy data goes on the stack. Also, types in many interpreted languages do automatic bounds checking, i.e. use the mechanism for separating the data channel from the control channel.)
What about all the other stack-based buffer overflow recommendations you hear, like canaries, mirrored stacks, ASLR and non-executable stacks? They work by detecting the attack or reducing its possible consequences, not by avoiding the vulnerability to start with. So, they are worth doing, but if you don't address the conditions that make the attack possible to start with, the underlying vulnerability is still there.
Now that the conditions that enable injection attacks are clear, I hope you will see them everywhere they exist in your system, even if you are using proprietary data formats & protocols no one but you has ever heard of. It could be very instructive to make a quick table of data formats and network protocols used in each layer of your system, with columns for whether control is in-band, whether untrustworthy input appears in the data channel (remember that untrustworthy data inserted at a higher layer of the system is still untrustworthy when it is interleaved with a control channel at a lower layer), the mechanism(s) for separating the control and data channel, and whether each mechanism, if applied correctly, is sufficient.
With that, I'm relying on you to move on to bigger and better kinds of vulnerability in 2009!
-- Brenda
In the interests of making everyone else as bored & jaded as I am, and perhaps even helping increase common knowledge, let me start by explaining why vulnerabilities to cross-site scripting and buffer overflows are instances of the same abstract problem: injection vulnerability.
It's pretty common to categorize cross-site scripting (XSS) and, say, SQL injection or format string exploits as injection attacks. In all of these cases, Mallory puts control codes where the developer is expecting data. A system will be vulnerable to an injection attack if and only if all 3 of the following interrelated conditions hold:
a. A data and control channel are mixed in the same communications medium.
b. Untrustworthy data is added to the data channel.
c. The mechanism intended to separate data & control channels is either insufficient or (more frequently) insufficiently applied.
Here's the run-down of these conditions for XSS in HTML:
a. An HTML document contains interleaved tags and attribute labels (the control channel), and their values (the data channel).
b. In most if not all interactive Web applications, user input (always untrustworthy, whether it is taken from this request or some persistent store) is displayed in the HTML document.
c. The mechanism for separating data & control channels in HTML is encoding according to the HTML specification; HTML is well-defined and this mechanism is sufficient.
Since embedded markup is part of the fundamental nature and appeal of HTML, not to mention a long-standing standard, nobody is about to change (a) and the usual recommendations for avoiding vulnerabilities to XSS correspond to eliminating (b) and (c):
b. Validate input (i.e. ensure it is trustworthy).
c. Encode input for the appropriate context before displaying it (i.e. use the mechanism for separating the data channel from the control channel).
It's less common to think of a buffer overflow attack as an injection attack, but here's the run-down of the injection vulnerability conditions for a buffer overflow on the stack:
a. The stack contains interleaved stack frame structures (the control channel) and local variables, parameters and the like (the data channel).
b. Almost any application touches input from outside itself (untrustworthy data), and almost any application puts the input it is processing into function parameters and local variables.
c. The mechanism for separating data & control channels on the stack is size-based; the stack is well-defined and this mechanism is sufficient.
As you can see, it's a match. If any of these conditions does not hold, stack-based buffer overflows are not possible. For purposes of avoiding the vulnerability, the important thing isn't the kind of control information the attacker can insert (HTML vs. pointers and machine instructions), or the mechanism used to separate data & control channels (encoding vs. size), it's preventing the data channel from leaking into the control channel.
As one would expect, the usual recommendations for avoiding vulnerability to stack-based buffer overflows eliminate one or more of these conditions :
a. Separate data and call stacks. (Actually this is relatively uncommon recommendation, probably because calling conventions are a pretty low-level interface to be changing.)
b. Validate input, e.g. confirm that strings are actually null-terminated. (Of course, by the time it's input to a function that would want to do the validation, you frequently don't have enough information to tell whether the null terminator occurs within the bounds of the memory that was allocated for this variable, so in practice you need to decide on and check invariants at the time the data is output to the variable.)
c. Use safe functions, i.e. those that have length arguments or otherwise include length checking (i.e. use the mechanism for separating the data channel from the control channel).
b and c. Use an interpreted language. (Many interpreted languages put object IDs (frequently pointers) on the stack instead of the original data; if the object IDs are not controllable from outside, no untrustworthy data goes on the stack. Also, types in many interpreted languages do automatic bounds checking, i.e. use the mechanism for separating the data channel from the control channel.)
What about all the other stack-based buffer overflow recommendations you hear, like canaries, mirrored stacks, ASLR and non-executable stacks? They work by detecting the attack or reducing its possible consequences, not by avoiding the vulnerability to start with. So, they are worth doing, but if you don't address the conditions that make the attack possible to start with, the underlying vulnerability is still there.
Now that the conditions that enable injection attacks are clear, I hope you will see them everywhere they exist in your system, even if you are using proprietary data formats & protocols no one but you has ever heard of. It could be very instructive to make a quick table of data formats and network protocols used in each layer of your system, with columns for whether control is in-band, whether untrustworthy input appears in the data channel (remember that untrustworthy data inserted at a higher layer of the system is still untrustworthy when it is interleaved with a control channel at a lower layer), the mechanism(s) for separating the control and data channel, and whether each mechanism, if applied correctly, is sufficient.
With that, I'm relying on you to move on to bigger and better kinds of vulnerability in 2009!
-- Brenda
Tuesday, January 6, 2009
2009 Web Security Predictions
2009 is a year when some fundamental shifts in web technology will begin to take hold and attackers will adjust accordingly. With the emergence of revolutionary changes such as cloud computing, widespread adoption of next generation web application technologies and the ‘real’ web arriving on mobile devices, we must anticipate that attackers will adjust their tactics to leverage these shifts. From a corporate perspective, anticipating attack and business trends can make the difference between being prepared for an emerging threat or being blind-sided by a new attack. We have combined the wealth of knowledge shared among Zscaler researchers with our unique access to web traffic to assemble our top 10 web security predictions for the coming year.
1.) Cloud Computing Is Ready For Primetime
2008 was the year in which 'cloud computing' truly emerged on the public stage and gained acceptance as a force to be reckoned with. In the coming year the honeymoon period is over and it's time for cloud computing to prove it's worth. Now we’re obviously biased but I fully expect 2009 to be a critical year for security in the cloud. We've moved past peaked curiosity to detailed evaluations and bake-offs of the many competing solutions that are beginning to emerge. This is the year where the pretenders will quickly be relegated to the sidelines and by year-end dominant players will begin to emerge.
For this process to occur, companies are going to need to define criteria for assessing security in the cloud. It will require a different approach than traditional software assessments, as you don't get to hold and touch SaaS solutions. This in turn makes it even more important that evaluators hold SaaS vendor's feet to the fire. Just because a vendor says that a feature exists - ensure that you understand how and determine if it will meet your needs.
2.) The ‘Mobile Web’ Is No Longer A Separate Platform
Check historical security predictions and you'll see that every year for the past decade was labeled as the moment when mobile malware would explode. It made sense. After all more and more people were leveraging mobile devices so attackers needed to adjust their focus eventually...yet they didn't. The number of large-scale attacks on mobile devices has been minimal. How can this be and will 2009 be any different?
Mobile malware has largely remained on the sidelines for two reasons. First, the multitude of platforms has limited the payback from putting in the work to exploit vulnerabilities in a single implementation. Secondly, mobile applications have largely lacked the feature set of their desktop counterparts, which leads to limited use.
Thanks in part to the competitive innovation injected by Apple's iPhone, the ‘mobile web’ is no longer a separate platform. What do we mean by that? There is no longer a clear distinction between web content for mobile and traditional browsers. You don't need WAP, WML, etc. to access the web on your phone. Standard web applications are now realistically accessible despite the limited screen real estate on a mobile device.
What does this mean for mobile attacks? It means that 2009 will be a significant year, but not because attacks will suddenly shift to mobile platforms. Mobile attacks will finally become a mainstream problem because mobile devices are susceptible to traditional attacks. Browsers such as Mobile Safari, Internet Explorer Mobile, Mobile Opera, etc. now have full JavaScript engines and can generally accommodate Rich Internet Applications. This combined with the fact that they now drive a meaningful volume of Internet traffic means that they are susceptible to many of the non-browser specific attacks such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Clickjacking, etc. They also tend to share libraries with their oft-vulnerable desktop siblings, so also expect browser specific vulnerabilities to be on the rise.
3.) Is Client Side Browser Storage a Feature or a Ticking Time Bomb?
The line between web and native desktop applications is continuing to blur. Rich Internet Application technologies such as Flash and SilverLight and the emergence of development approaches such as AJAX have made web applications much more interactive and user friendly. However, despite these advancements, a critical differentiator between desktop and web applications remains the need for connectivity. Sure, Google Docs is a great alternative to Microsoft Office - until you board a plane. You can't use web applications unless you have access to them.
This too is starting to change as browsers are gaining access to client side storage solutions. Flash storage, Google Gears and Structured Client Side Storage, detailed in the HTML 5 specification all address this issue. While this opens up new doors for web applications, as with any new technology, if it is implemented insecurely, it can increase risk and create new headaches for corporate security staff. Our early review of these technologies suggests that they are not well understood and are indeed being poorly implemented. This is turn will lead to the leakage of sensitive information and client side equivalents of XSS and SQL injection. Stay tuned for further posts on this topic.
4.) Web API Vulnerabilities Lead to Mass Attacks
Code reuse has always been encouraged - why reinvent the wheel. It's also a good security practice as open, stable code has been scrutinized by many eyeballs and is therefore more likely to be secure. In web development however, that is not always the case. While we may leverage functionality created by others, the security of that code may not have been assessed by anyone other than the original creators. That occurs because we're not necessarily dealing with open source code or even compiled binaries but rather web based APIs. In this case, we're largely counting on the providers of a given service to ensure that it's secure. Google for example makes available a plethora of APIs for everything from maps to social networks and despite investing in securing code prior to release; they have seen their fair share of vulnerabilities. When a vulnerability is discovered in such an API, hundreds and thousands of sites can instantly be affected. Fortunately, patching can generally be completed quickly as only servers hosting the API need to be updated but this can also break associated applications. From an attacker's perspective, a web API vulnerability can signal a target rich environment with a small window of opportunity - a good reason to keep quiet once a vulnerability is discovered.
5.) Abusing the Architecture Of The Web As Opposed To Vulnerabilities In Specific Applications
Traditionally, vulnerabilities have exploited a specific error on a specific platform. The web however, has opened the door for attacks which are cross-platform simply because they abuse intended functionality. Let's face it - the web was designed to be open - not secure. Moreover, the interconnected nature of the web means that a vulnerability on one node (i.e. a web server) can indirectly lead to a compromise on another node (i.e. a web browser). We could argue that these facts of life on the web account for the majority of security incidents today and that the trend will only continue to escalate. XSS is an entrenched example of this fact. The web was designed to freely share content between browsers and servers and JavaScript was developed and adopted to extend the functionality of web browsers. The inventors did not however plan for a scenario whereby someone with less than honest intentions would leverage the power of JavaScript and browser/server trust (and lack of input validation) to attack unsuspecting users. Such attacks are not specific to any browser or server - all are affected equally as XSS abuses the infrastructure of the web not a specific vulnerability. We were provided with another example of this phenomena in 2008 when Clickjacking flew into the media spotlight. This time the attack focused on transparency and DHTML with a dash of social engineering to convince victims to make requests that they hadn't intended too. Expect such attacks to become the rule as opposed to the exception.
6.) Internet Explorer Gets Competition
We've often argued that vulnerability statistics are a poor indicator of the relative security of a product. Rather than providing insight into the relative security of products, they tend to instead reveal the popularity of products. Attackers/researchers want the biggest bang for their buck. If they're going to spend time looking for vulnerabilities in a certain product, they're more likely to focus on the one with the largest user base. Internet Explorer (IE) has held the browser crown for several years now and that in our opinion is why it has tended to see a more significant number of vulnerability reports. The landscape is however beginning to change. Not only are mobile browsers starting to take off (see prediction #2) but there are some interesting new challengers in the market such as Google Chrome. While we don't expect Microsoft to fall from the pole position any time soon, we do expect the focus to shift to some of these new and intriguing entrants. Expect to see a decreased number of IE vulnerabilities in 2009 and more from mobile browsers and especially Google Chrome. While Google has a decent security track record, they haven't faced the same difficult but important learning curve climbed by Microsoft over the years. Browser development is also a different game than web application development, Google's forté, so expect some tarnish on the Chrome in '09.
7.) Data Leakage Via The Web Reaches A Tipping Point
The Internet is converging on ports 80 and 443? Why? They're always accessible for outbound connections on corporate networks. Whether you're dealing with VoIP, P2P or malicious code, network aware applications are becoming increasingly intelligent. While they may initially attempt to connect via high-level ports using proprietary protocols for efficiency, they will often try a variety of approaches and ultimately regress to tunneling content through HTTP/HTTPS traffic. Combine this with the fact that users are increasingly encouraged to share content online (Facebook, Myspace, YouTube, etc.) and it's easy to see why data leakage via web channels is fast becoming a top priority for many enterprises. 2007 and 2008 were banner year for data leakage solutions in general (Vontu and Provilla acquired) but in 2009 the focus will shift to web based DLP.
8.) The Long Overdue Death of URL Filtering
Network administrators are finally starting to give up on managing web traffic through URL filtering. URL filtering is a dated technology, which tends to focus on blocking traffic at the domain level and leaves the administrator with a binary decision - allow or don't allow access to a given resource. This approach was reasonable when the web was dominated by static, corporate content. This is no longer the case. Today, content is extremely dynamic and often user generated and this changes the rules. A page that was good today may be bad tomorrow and while a domain such as Facebook.com may be perfectly acceptable, individual pages could contain objectionable or malicious content. In 2009, enterprises will seek solutions that support dynamic content filtering and page level reputation.
9.) Controlling Web Application Functionality, Not Just Content
It is no longer enough to block/allow access to sites. Administrators are demanding control over functionality, not just content. There may be perfectly legitimate reasons to permit access to a given resource but not want to permit specific functionality. Take YouTube for example. While it may be seen primarily as an entertainment site, many businesses have begun to leverage it as a marketing tool. If URL filtering is your only option for controlling access to YouTube (see prediction #8), you're stuck with allowing/disallowing access to the site as a whole. You may however wish to permit viewing videos to allow for competitive intelligence (or to avoid being the fun police) but not want to permit uploading content for fear of data leakage (see prediction #7). Administrators are increasingly demanding the ability to manage the - who, what, when, where and how much of web security. They want the granularity to determine that only the Marketing Department can upload videos during work hours to YouTube, so long as they don't use more that 5% of available bandwidth. Solutions need to understand not just the destination of a web request, but also the business logic of that destination in order to be able to permit the granular level of control required to manage third party web applications.
10.) Mobile Platforms Open Up For Developers…And Attackers
Desktops and mobile devices have evolved along nearly opposite paths - until now. Desktops have always been about an open architecture - you're free to add whatever applications you like, after all, you own it. Cell phones on the other hand have traditionally been black boxes - don't like a key feature? Buy a new phone. Much of this was driven by the control crazy mobile carriers who until recently have wielded the power. They didn't want you to be able to add features, as it would then be harder for them to differentiate their 'exclusive' handset offerings. This has changed however as device manufacturers have begun calling the shots and the carriers are now tripping over one another to argue about who is the most 'open'. While this overall is a positive thing, it does have security implications. The more freedom that you provide someone with the more likely that freedom will be abused. Providers are taking different approaches to an 'open' model. Apple for example allows you to install whatever you want, so long as they approve of it. Are they however, assessing submitted applications for security weaknesses, or just undesirable functionality? We suspect it's the later. Google on the other hand is taking a more 'pure' open source approach and not locking down as many portions of the O/S for developers. Will attackers abuse these new open platforms? You bet.
1.) Cloud Computing Is Ready For Primetime
2008 was the year in which 'cloud computing' truly emerged on the public stage and gained acceptance as a force to be reckoned with. In the coming year the honeymoon period is over and it's time for cloud computing to prove it's worth. Now we’re obviously biased but I fully expect 2009 to be a critical year for security in the cloud. We've moved past peaked curiosity to detailed evaluations and bake-offs of the many competing solutions that are beginning to emerge. This is the year where the pretenders will quickly be relegated to the sidelines and by year-end dominant players will begin to emerge.
For this process to occur, companies are going to need to define criteria for assessing security in the cloud. It will require a different approach than traditional software assessments, as you don't get to hold and touch SaaS solutions. This in turn makes it even more important that evaluators hold SaaS vendor's feet to the fire. Just because a vendor says that a feature exists - ensure that you understand how and determine if it will meet your needs.
2.) The ‘Mobile Web’ Is No Longer A Separate Platform
Check historical security predictions and you'll see that every year for the past decade was labeled as the moment when mobile malware would explode. It made sense. After all more and more people were leveraging mobile devices so attackers needed to adjust their focus eventually...yet they didn't. The number of large-scale attacks on mobile devices has been minimal. How can this be and will 2009 be any different?
Mobile malware has largely remained on the sidelines for two reasons. First, the multitude of platforms has limited the payback from putting in the work to exploit vulnerabilities in a single implementation. Secondly, mobile applications have largely lacked the feature set of their desktop counterparts, which leads to limited use.
Thanks in part to the competitive innovation injected by Apple's iPhone, the ‘mobile web’ is no longer a separate platform. What do we mean by that? There is no longer a clear distinction between web content for mobile and traditional browsers. You don't need WAP, WML, etc. to access the web on your phone. Standard web applications are now realistically accessible despite the limited screen real estate on a mobile device.
What does this mean for mobile attacks? It means that 2009 will be a significant year, but not because attacks will suddenly shift to mobile platforms. Mobile attacks will finally become a mainstream problem because mobile devices are susceptible to traditional attacks. Browsers such as Mobile Safari, Internet Explorer Mobile, Mobile Opera, etc. now have full JavaScript engines and can generally accommodate Rich Internet Applications. This combined with the fact that they now drive a meaningful volume of Internet traffic means that they are susceptible to many of the non-browser specific attacks such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Clickjacking, etc. They also tend to share libraries with their oft-vulnerable desktop siblings, so also expect browser specific vulnerabilities to be on the rise.
3.) Is Client Side Browser Storage a Feature or a Ticking Time Bomb?
The line between web and native desktop applications is continuing to blur. Rich Internet Application technologies such as Flash and SilverLight and the emergence of development approaches such as AJAX have made web applications much more interactive and user friendly. However, despite these advancements, a critical differentiator between desktop and web applications remains the need for connectivity. Sure, Google Docs is a great alternative to Microsoft Office - until you board a plane. You can't use web applications unless you have access to them.
This too is starting to change as browsers are gaining access to client side storage solutions. Flash storage, Google Gears and Structured Client Side Storage, detailed in the HTML 5 specification all address this issue. While this opens up new doors for web applications, as with any new technology, if it is implemented insecurely, it can increase risk and create new headaches for corporate security staff. Our early review of these technologies suggests that they are not well understood and are indeed being poorly implemented. This is turn will lead to the leakage of sensitive information and client side equivalents of XSS and SQL injection. Stay tuned for further posts on this topic.
4.) Web API Vulnerabilities Lead to Mass Attacks
Code reuse has always been encouraged - why reinvent the wheel. It's also a good security practice as open, stable code has been scrutinized by many eyeballs and is therefore more likely to be secure. In web development however, that is not always the case. While we may leverage functionality created by others, the security of that code may not have been assessed by anyone other than the original creators. That occurs because we're not necessarily dealing with open source code or even compiled binaries but rather web based APIs. In this case, we're largely counting on the providers of a given service to ensure that it's secure. Google for example makes available a plethora of APIs for everything from maps to social networks and despite investing in securing code prior to release; they have seen their fair share of vulnerabilities. When a vulnerability is discovered in such an API, hundreds and thousands of sites can instantly be affected. Fortunately, patching can generally be completed quickly as only servers hosting the API need to be updated but this can also break associated applications. From an attacker's perspective, a web API vulnerability can signal a target rich environment with a small window of opportunity - a good reason to keep quiet once a vulnerability is discovered.
5.) Abusing the Architecture Of The Web As Opposed To Vulnerabilities In Specific Applications
Traditionally, vulnerabilities have exploited a specific error on a specific platform. The web however, has opened the door for attacks which are cross-platform simply because they abuse intended functionality. Let's face it - the web was designed to be open - not secure. Moreover, the interconnected nature of the web means that a vulnerability on one node (i.e. a web server) can indirectly lead to a compromise on another node (i.e. a web browser). We could argue that these facts of life on the web account for the majority of security incidents today and that the trend will only continue to escalate. XSS is an entrenched example of this fact. The web was designed to freely share content between browsers and servers and JavaScript was developed and adopted to extend the functionality of web browsers. The inventors did not however plan for a scenario whereby someone with less than honest intentions would leverage the power of JavaScript and browser/server trust (and lack of input validation) to attack unsuspecting users. Such attacks are not specific to any browser or server - all are affected equally as XSS abuses the infrastructure of the web not a specific vulnerability. We were provided with another example of this phenomena in 2008 when Clickjacking flew into the media spotlight. This time the attack focused on transparency and DHTML with a dash of social engineering to convince victims to make requests that they hadn't intended too. Expect such attacks to become the rule as opposed to the exception.
6.) Internet Explorer Gets Competition
We've often argued that vulnerability statistics are a poor indicator of the relative security of a product. Rather than providing insight into the relative security of products, they tend to instead reveal the popularity of products. Attackers/researchers want the biggest bang for their buck. If they're going to spend time looking for vulnerabilities in a certain product, they're more likely to focus on the one with the largest user base. Internet Explorer (IE) has held the browser crown for several years now and that in our opinion is why it has tended to see a more significant number of vulnerability reports. The landscape is however beginning to change. Not only are mobile browsers starting to take off (see prediction #2) but there are some interesting new challengers in the market such as Google Chrome. While we don't expect Microsoft to fall from the pole position any time soon, we do expect the focus to shift to some of these new and intriguing entrants. Expect to see a decreased number of IE vulnerabilities in 2009 and more from mobile browsers and especially Google Chrome. While Google has a decent security track record, they haven't faced the same difficult but important learning curve climbed by Microsoft over the years. Browser development is also a different game than web application development, Google's forté, so expect some tarnish on the Chrome in '09.
7.) Data Leakage Via The Web Reaches A Tipping Point
The Internet is converging on ports 80 and 443? Why? They're always accessible for outbound connections on corporate networks. Whether you're dealing with VoIP, P2P or malicious code, network aware applications are becoming increasingly intelligent. While they may initially attempt to connect via high-level ports using proprietary protocols for efficiency, they will often try a variety of approaches and ultimately regress to tunneling content through HTTP/HTTPS traffic. Combine this with the fact that users are increasingly encouraged to share content online (Facebook, Myspace, YouTube, etc.) and it's easy to see why data leakage via web channels is fast becoming a top priority for many enterprises. 2007 and 2008 were banner year for data leakage solutions in general (Vontu and Provilla acquired) but in 2009 the focus will shift to web based DLP.
8.) The Long Overdue Death of URL Filtering
Network administrators are finally starting to give up on managing web traffic through URL filtering. URL filtering is a dated technology, which tends to focus on blocking traffic at the domain level and leaves the administrator with a binary decision - allow or don't allow access to a given resource. This approach was reasonable when the web was dominated by static, corporate content. This is no longer the case. Today, content is extremely dynamic and often user generated and this changes the rules. A page that was good today may be bad tomorrow and while a domain such as Facebook.com may be perfectly acceptable, individual pages could contain objectionable or malicious content. In 2009, enterprises will seek solutions that support dynamic content filtering and page level reputation.
9.) Controlling Web Application Functionality, Not Just Content
It is no longer enough to block/allow access to sites. Administrators are demanding control over functionality, not just content. There may be perfectly legitimate reasons to permit access to a given resource but not want to permit specific functionality. Take YouTube for example. While it may be seen primarily as an entertainment site, many businesses have begun to leverage it as a marketing tool. If URL filtering is your only option for controlling access to YouTube (see prediction #8), you're stuck with allowing/disallowing access to the site as a whole. You may however wish to permit viewing videos to allow for competitive intelligence (or to avoid being the fun police) but not want to permit uploading content for fear of data leakage (see prediction #7). Administrators are increasingly demanding the ability to manage the - who, what, when, where and how much of web security. They want the granularity to determine that only the Marketing Department can upload videos during work hours to YouTube, so long as they don't use more that 5% of available bandwidth. Solutions need to understand not just the destination of a web request, but also the business logic of that destination in order to be able to permit the granular level of control required to manage third party web applications.
10.) Mobile Platforms Open Up For Developers…And Attackers
Desktops and mobile devices have evolved along nearly opposite paths - until now. Desktops have always been about an open architecture - you're free to add whatever applications you like, after all, you own it. Cell phones on the other hand have traditionally been black boxes - don't like a key feature? Buy a new phone. Much of this was driven by the control crazy mobile carriers who until recently have wielded the power. They didn't want you to be able to add features, as it would then be harder for them to differentiate their 'exclusive' handset offerings. This has changed however as device manufacturers have begun calling the shots and the carriers are now tripping over one another to argue about who is the most 'open'. While this overall is a positive thing, it does have security implications. The more freedom that you provide someone with the more likely that freedom will be abused. Providers are taking different approaches to an 'open' model. Apple for example allows you to install whatever you want, so long as they approve of it. Are they however, assessing submitted applications for security weaknesses, or just undesirable functionality? We suspect it's the later. Google on the other hand is taking a more 'pure' open source approach and not locking down as many portions of the O/S for developers. Will attackers abuse these new open platforms? You bet.
Friday, January 2, 2009
Breaking Down Broken SSL
Update [01/06/09]: I discussed this topic with Dan Kaplan on his SC Magazine podcast.
On December 30, 2008 at the 25th Chaos Communication Congress (CCC) in Berlin, seven researchers presented a talk entitled 'MD5 Considered Harmful Today: Creating a Rogue CA Certificate'. In essence, they made the theoretical practical by building on recent research which detailed how chosen-prefix collisions for MD5 could be used to create two x.509 certificates with identical signatures despite having different content. The CCC presentation has taken this work a step further to actually produce an intermediate CA certificate signed by a trusted root CA. This certificate can then be used sign any website certificate. A website certificate created by the team can be seen in the image below. Note that Internet Explorer in this case considers the certificate to be legitimate.
As you can imagine, the ability to create fake SSL certificates is a phisher's dream come true. An attacker possessing such a rogue certificate could produce fake SSL certificates for phishing sites which would be indistinguishable from their legitimate counterparts. However, before we conclude that the sky is falling it's important to understand that while such attacks have now been proven to be possible, it would still be difficult to an attacker to successfully mount a successful attack.
Ingredients For a Successful Attack
1.) Knowledge - While the CCC researchers have published a detailed paper to discuss their findings, they will thankfully "for the time being not release the full details of how [they] have been able to obtain the rogue Certification Authority certificate". While their research is based on past work that is now public, they confess that the "publicly known techniques have been improved at crucial points". In short - simply reading their paper/slides will not be enough to conduct a successful attack, additional research would be required. That said, you can bet that the race is now on for the bad guys.
2.) Computing Power - In order to calculate the MD5 hash collisions to produce the rogue CA certificate, the team employed a cluster of 200 PlayStation 3 consoles. While such technology is readily available, there is a real cost associated with acquiring the necessary computing power to replicate their work.
3.) Traffic Redirection - This is the biggie. Producing a rogue SSL certificate for say bankofamerica.com is of little value if it is not hosted at bankofamerica.com. Hosting the certificate at any other domain will result in a warning message from any visiting web browser indicating that the certificate does not match the domain name. The necessary traffic redirection is realistic on a LAN segment, but would be very difficult to accomplish on the Internet as a whole. Attacks such as Dan Kaminsky's DNS cache poisioning attack would provide the critical missing piece of the puzzle but fortunately this vulnerability has aged to the point where it has primarily been addressed.
Why This Was Possible
The CCC researchers largely credit the work of Marc Stevens , Arjen Lenstra and Benne de Weger on chosen-prefix collisions for MD5 which was released in 2007. However, their success was also made easier by less than perfect processes at a number of Certificate Authorities. Certificates do not have to be signed using MD5. In fact, MD5 was shown to be vulnerable to attack as early as 2004 and yet a number CAs still employ MD5 for certificate signatures. The worst offender turned out to be RapidSSL (owned by VeriSign), which was responsible for 97% of the MD5 signed certificates that the researchers looked at. The team also faced other challenges such as predicting the validity period and serial numbers of the certificates issued by the CA that was being targeted. This was made much easier by the fact that certain CAs are apparently using sequential serial numbers.
What Needs To Be Done
So, what can you do to protect your users from falling victim to phishing attacks on sites that may have rogue certificates? Unfortunately, there isn't a good answer to that question. If someone were to successfully create a rogue certificate it would be difficult evn with manual inspection to identify it as rogue. The researchers took the approach of developing an intermediate CA certificate which could then be used to sign any website certificate, therefore you could identify/block any web certificates signed by an intermediate CA which is not specifically trusted but that could also block some legitimate sites. It should be noted that it is not enough to block sites with MD5 signed certificates (unless MD5 was not used for signing at any point in the chain of trust). While MD5 collisions were used to develop the rogue CA certificate, once it is developed, MD5 does not need to be used for signing subsequent website certificates.
The fix really lies with the CAs. The fact that some have continued to use MD5 instead of a more secure alternative such as SHA-2 for signing certificates some four years after real weaknesses in the algorithm were demonstrated, is inexcusable. They also need to inject randomness into the signature generation process, most notably in the serial number field. Hopefully this research will force CAs to quickly phase out the use of MD5 for developing certificate signatures and improve their procedures overall.
Happy New Year!
- michael
On December 30, 2008 at the 25th Chaos Communication Congress (CCC) in Berlin, seven researchers presented a talk entitled 'MD5 Considered Harmful Today: Creating a Rogue CA Certificate'. In essence, they made the theoretical practical by building on recent research which detailed how chosen-prefix collisions for MD5 could be used to create two x.509 certificates with identical signatures despite having different content. The CCC presentation has taken this work a step further to actually produce an intermediate CA certificate signed by a trusted root CA. This certificate can then be used sign any website certificate. A website certificate created by the team can be seen in the image below. Note that Internet Explorer in this case considers the certificate to be legitimate.
As you can imagine, the ability to create fake SSL certificates is a phisher's dream come true. An attacker possessing such a rogue certificate could produce fake SSL certificates for phishing sites which would be indistinguishable from their legitimate counterparts. However, before we conclude that the sky is falling it's important to understand that while such attacks have now been proven to be possible, it would still be difficult to an attacker to successfully mount a successful attack.
Ingredients For a Successful Attack
1.) Knowledge - While the CCC researchers have published a detailed paper to discuss their findings, they will thankfully "for the time being not release the full details of how [they] have been able to obtain the rogue Certification Authority certificate". While their research is based on past work that is now public, they confess that the "publicly known techniques have been improved at crucial points". In short - simply reading their paper/slides will not be enough to conduct a successful attack, additional research would be required. That said, you can bet that the race is now on for the bad guys.
2.) Computing Power - In order to calculate the MD5 hash collisions to produce the rogue CA certificate, the team employed a cluster of 200 PlayStation 3 consoles. While such technology is readily available, there is a real cost associated with acquiring the necessary computing power to replicate their work.
3.) Traffic Redirection - This is the biggie. Producing a rogue SSL certificate for say bankofamerica.com is of little value if it is not hosted at bankofamerica.com. Hosting the certificate at any other domain will result in a warning message from any visiting web browser indicating that the certificate does not match the domain name. The necessary traffic redirection is realistic on a LAN segment, but would be very difficult to accomplish on the Internet as a whole. Attacks such as Dan Kaminsky's DNS cache poisioning attack would provide the critical missing piece of the puzzle but fortunately this vulnerability has aged to the point where it has primarily been addressed.
Why This Was Possible
The CCC researchers largely credit the work of Marc Stevens , Arjen Lenstra and Benne de Weger on chosen-prefix collisions for MD5 which was released in 2007. However, their success was also made easier by less than perfect processes at a number of Certificate Authorities. Certificates do not have to be signed using MD5. In fact, MD5 was shown to be vulnerable to attack as early as 2004 and yet a number CAs still employ MD5 for certificate signatures. The worst offender turned out to be RapidSSL (owned by VeriSign), which was responsible for 97% of the MD5 signed certificates that the researchers looked at. The team also faced other challenges such as predicting the validity period and serial numbers of the certificates issued by the CA that was being targeted. This was made much easier by the fact that certain CAs are apparently using sequential serial numbers.
What Needs To Be Done
So, what can you do to protect your users from falling victim to phishing attacks on sites that may have rogue certificates? Unfortunately, there isn't a good answer to that question. If someone were to successfully create a rogue certificate it would be difficult evn with manual inspection to identify it as rogue. The researchers took the approach of developing an intermediate CA certificate which could then be used to sign any website certificate, therefore you could identify/block any web certificates signed by an intermediate CA which is not specifically trusted but that could also block some legitimate sites. It should be noted that it is not enough to block sites with MD5 signed certificates (unless MD5 was not used for signing at any point in the chain of trust). While MD5 collisions were used to develop the rogue CA certificate, once it is developed, MD5 does not need to be used for signing subsequent website certificates.
The fix really lies with the CAs. The fact that some have continued to use MD5 instead of a more secure alternative such as SHA-2 for signing certificates some four years after real weaknesses in the algorithm were demonstrated, is inexcusable. They also need to inject randomness into the signature generation process, most notably in the serial number field. Hopefully this research will force CAs to quickly phase out the use of MD5 for developing certificate signatures and improve their procedures overall.
Happy New Year!
- michael
Microsoft Internet Explorer dips below 70% market share
I ran across this article by Net Applications that shows their recent browser tracking data. According to their stats, Microsoft Internet Explorer (MSIE) browser has finally dropped below 70% of the overall browser market share, and Firefox has risen above 20%.
Overall, this is nice for Firefox and alternative browsers, but it does have both positive and negative security implications. For a period of time, it felt like the world wide web was a homogenous environment of MSIE browsers everywhere (and before that, it was Netscape browsers). Now we're finally at a point where the numbers may start supporting the notion that we have a true heterogeneous environment blossoming. Heterogeneous environments, whether it be a computer network or a biological system, are often much more robust and stable than a homogeneous environment simply because a homogeneous environment is susceptible to a single incident (such as an eruption of a pathogen, or a browser exploit in our case) wiping out the entire environment in one fell swoop. So the growth of browser alternatives is actually good for web browser security overall, because it means not all systems will be p0wn3d by the next devastating MSIE vulnerability.
There is also a downside of this too. With the rise of active use of alternative browsers, there is now enough incentive for attackers to take the time to attack/exploit the alternatives. We kind of already knew this, and it was largely already happening in the real world, but the numbers help to support the idea. Simply put: if no one is using a browser, there isn’t much blackhat value in finding a vulnerability in it to exploit...you’d essentially have a specialized weapon with a lack of targets to use it upon. But once there is a moderate/sizable population of those targets, the effectiveness of that specialized weapon (i.e. exploit) increases. We’ve seen this before with the Apple Mac platform: many people claimed it was more secure than Windows because it had fewer publicized security vulnerabilities. There's even the claim that Macs don't need anti-virus software because there are no viruses for Macs. Of course, Mac popularity grew, the number of deployed systems rose, and that caused the attackers to take notice. Now we have active research and exploitation of OSX and its components, and a host of malware specific to the Mac platform (for the skeptical: OSX.Leap.A, OSX.Exploit.Launchd, OSX.Macarena, OSX.Inqtana.A, etc.)
Overall this is the right direction for things to be heading. However, those trying to fly under the blackhats' web exploitation radars by using an alternative/obscure browser may find their days of obfuscated safety are numbered. As soon as the obscure browser you are using jumps into the limelight, attackers are sure to pounce on it eventually as well.
Side note: I've encountered many individuals that have employed this 'security through obscure browser' tactic. The issue is that they were using browsers like Maxthon, NeoPlanet, Avant, etc. What they didn't realize is that all of these browsers were just different UI shells on top of the MSIE web layout engine (called 'Trident'). In other words, they often just as vulnerable as if they were directly running MSIE—there was no security advantage gained. Overall there currently four major web browser 'engines': Trident (MSIE), Gecko (Firefox), WebKit (Safari), and Presto (Opera). Most browsers on the market today use one of those engines (or a derivative), and that means any vulnerability that affects the engine will affect any browser built upon it. So you might hear of a vulnerability in Firefox, but the bug could truly be in the Gecko engine and thus other browsers like Flock, Camino, Epiphany, Galeon, SeaMonkey, and Songbird (all Gecko-based) could be vulnerable as well. Therefore if you are looking to differentiate yourself by using an obscure browser for security purposes, you should do some research to ensure the browser you are running is not running the same (vulnerable) web engine as the more popular browsers.
Until next time,
- Jeff
Overall, this is nice for Firefox and alternative browsers, but it does have both positive and negative security implications. For a period of time, it felt like the world wide web was a homogenous environment of MSIE browsers everywhere (and before that, it was Netscape browsers). Now we're finally at a point where the numbers may start supporting the notion that we have a true heterogeneous environment blossoming. Heterogeneous environments, whether it be a computer network or a biological system, are often much more robust and stable than a homogeneous environment simply because a homogeneous environment is susceptible to a single incident (such as an eruption of a pathogen, or a browser exploit in our case) wiping out the entire environment in one fell swoop. So the growth of browser alternatives is actually good for web browser security overall, because it means not all systems will be p0wn3d by the next devastating MSIE vulnerability.
There is also a downside of this too. With the rise of active use of alternative browsers, there is now enough incentive for attackers to take the time to attack/exploit the alternatives. We kind of already knew this, and it was largely already happening in the real world, but the numbers help to support the idea. Simply put: if no one is using a browser, there isn’t much blackhat value in finding a vulnerability in it to exploit...you’d essentially have a specialized weapon with a lack of targets to use it upon. But once there is a moderate/sizable population of those targets, the effectiveness of that specialized weapon (i.e. exploit) increases. We’ve seen this before with the Apple Mac platform: many people claimed it was more secure than Windows because it had fewer publicized security vulnerabilities. There's even the claim that Macs don't need anti-virus software because there are no viruses for Macs. Of course, Mac popularity grew, the number of deployed systems rose, and that caused the attackers to take notice. Now we have active research and exploitation of OSX and its components, and a host of malware specific to the Mac platform (for the skeptical: OSX.Leap.A, OSX.Exploit.Launchd, OSX.Macarena, OSX.Inqtana.A, etc.)
Overall this is the right direction for things to be heading. However, those trying to fly under the blackhats' web exploitation radars by using an alternative/obscure browser may find their days of obfuscated safety are numbered. As soon as the obscure browser you are using jumps into the limelight, attackers are sure to pounce on it eventually as well.
Side note: I've encountered many individuals that have employed this 'security through obscure browser' tactic. The issue is that they were using browsers like Maxthon, NeoPlanet, Avant, etc. What they didn't realize is that all of these browsers were just different UI shells on top of the MSIE web layout engine (called 'Trident'). In other words, they often just as vulnerable as if they were directly running MSIE—there was no security advantage gained. Overall there currently four major web browser 'engines': Trident (MSIE), Gecko (Firefox), WebKit (Safari), and Presto (Opera). Most browsers on the market today use one of those engines (or a derivative), and that means any vulnerability that affects the engine will affect any browser built upon it. So you might hear of a vulnerability in Firefox, but the bug could truly be in the Gecko engine and thus other browsers like Flock, Camino, Epiphany, Galeon, SeaMonkey, and Songbird (all Gecko-based) could be vulnerable as well. Therefore if you are looking to differentiate yourself by using an obscure browser for security purposes, you should do some research to ensure the browser you are running is not running the same (vulnerable) web engine as the more popular browsers.
Until next time,
- Jeff
Subscribe to:
Posts (Atom)
Posts
