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.

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

Let's say you've established some security objectives, including "Keep an attacker who controls Internet web sites my employees visit from denying my employees access to my corporate information." How can you tell whether the product you're considering will help you meet your goal?

In theory, it's pretty simple: for a set of controls to give you the security benefit you are looking for, there needs to be at least one control blocking every possible path from what the attacker can do before he attacks (control Internet web sites your employees visit) to the thing you really don't want him to do (stop your employees from accessing your corporate information). If there is a path on which nothing stops the attacker, you have a security vulnerability, which means you need to change either your goals (maybe they're too aggressive for current technology to support), the system architecture, or the set of controls you're using. If there are paths on which multiple controls stop the attacker, you have defense in depth; how much depth is good depends on your level of paranoia and the performance, administrative and financial costs you are willing to put up with.

In practice, when you're trying to use security controls to meet a minimum bar, the hard part is knowing what paths are available for an attacker to take. Each path is made up of individual steps, each of which has starting and ending privileges. There are 3 kinds of steps to consider:

• By Design: the system is designed to provide someone with privileges S with privileges E.
  
• Design Side-Effects: it didn't necessarily need to be this way, but the system is designed such that someone with privileges S can automatically get privileges E.
  
• Implementation Flaws: someone with privileges S can get privileges E even though the design of the system does not allow this step
  

I find it quickest and most enlightening to start at both ends (the attacker's starting privileges and your anti-goals for the attacker), and enumerate the endpoints of steps in each category.

Let's start at your anti-destination for the attacker, denying employees access to corporate information. You may think that because this is a denial of service threat, you didn't design your system to enable it at all, but chances are good you can get a pretty good list from your departing employee process.

My system is designed to prevent [ex-]employees access to corporate information when:
The user's account is deleted from LDAP.
The user's account is deleted from the 'employee' group.
The user's password is changed.
Ownership of a file formerly owned by the user is changed.
Files owned by the user are deleted.
...

Because these things have to work for your sysadmin when an employee leaves, they would also work for an attacker, if an attacker could do them.

To get a list of design side-effects an attacker could use to prevent an employee from accessing corporate information, try inverting the table of contents of your disaster recovery plan (or, if you don't have one, the categories in your IT help desk ticketing system). You know if any of these conditions are true, your IT crew is going to scramble because employees won't be able to get the information they need. This is true whether it happened by accident or an attacker did it to you on purpose.

This leaves us with implementation flaws. You can't really list these unless you are running known-vulnerable software. Presumably if you knew you were running vulnerable software, you would patch it, so let's not try to create this list directly. Instead, list the components which have the permissions to do things in the first 2 lists. If these components were vulnerable (in the right ways), an attacker who got far enough to reach the vulnerable interface could exploit them and presumably accomplish the original threat.

An attacker may be able to prevent access to corporate information when:
A vulnerability in the LDAP server allows an attacker to delete user accounts, change group membership, ...
A vulnerability in the file server allows an attacker to delete files, change file permissions, overwrite files, ...
A vulnerability in the user's desktop allows an attacker to prevent the machine from booting, delete applications, delete files, change file permissions, overwrite files, change the user's password, ...
...

Now, start from the other side. If an attacker can control an Internet site your employees visit, what can he do by design?

A web site my employee visits can:
Set or delete cookies for that site on my employee's desktop.
Redirect the employee's browser to another Web site.
Run javascript in the user's web browser in the context of that site.
Run java applications, signed ActiveX controls, …
...

What can he do as a design side-effect?

A web site my employee visits can also:
Respond to a single request with more than one response.
Persuade my employee to run damaging commands or executables.
…

What could he do as a result of implementation flaws?

A web site my employee visits can:
Take advantage of any security flaw in the employee's web browser or plugins.

In the middle, for any given potential connection you can have one of three things: a working path for the attacker, a control that blocks the attacker's path to your anti-goal for the attacker, or something more fuzzy (usually including the word "may"). If there are any working paths for the attacker that traverse only steps that are by design, you have a requirements conflict and it will not be possible for technological controls to meet the security objective you have in mind unless you change your requirements. For any other working path, you need to find a control that will break a link. Or, going the other way, to be complete, the set of controls you are considering must break at least one link in each otherwise-working path. Probably to get this effect, you will need to combine controls from multiple sources. If a set of controls doesn't break any links in any attack paths you care about, don't buy it.

From the above partial lists, there is a pretty clear connection between an attacker being able to take advantage of security flaws in the employee's web browser and the consequences of a vulnerability in the user's desktop: the web browser runs on the user's desktop, so a security flaw in the browser would mean the attacker with control of a web site visited by the employee can deny the employee access to corporate information, violating this security objective. There is an equally clear connection between social engineering the employee into opening malware and violating this security objective. The latter connection, because it doesn't involve any implementation flaws, is more serious, and it would be prudent to mitigate it. You could, say, compare the effectiveness of user-education programs, desktop anti-virus, and an HTTP malware scanner (my money, hopefully obviously, is on combining the desktop AV and the HTTP scanner, because people will click on anything).

Because the fuzzy paths say "may", you get some leeway in deciding whether you think there is a working path for the attacker to follow from his starting privileges to the things you don't want him to do. If you have no known working attack paths, you might consider reducing risk in these areas (e.g. by instituting an aggressive monitoring & patching policy, or buying a product which attempts to defend against relevant 0-day attacks) before adding depth to your defenses in other areas.

--Brenda