Free Azure for MSDN subscribers

Well, som terms apply:

Windows Azure Platform Benefits for MSDN Subscribers

And also a notice of warning:

You'll need your credit card to sign up. If you use more than the amount of services included with your MSDN subscription, we'll bill your card for these overages.

I'll probably take my chances on testing the cloud next year, despite the credit card warning...

All Windows Azure offers can be found here.

A month or two ago I investigated the possibilities for testing out Azure, but I somehow managed to not stumble upon the MSDN subscription option. Either this is a new offering, or my Google skillz were seriously off at the time.

A while ago one of my colleagues tried an Azure subscription, but he quickly realized that the prizing followed the idea of a hotel room. He was charged for the room per its availability, not for its actual use. Not very developer friendly.

For Azure to become a smashing success, it's important that developers get a chance to play with the technology — without committing to a significant bill. I really hope that this Azure subscription is a permanent offering, and that there are controls in place to protect developers from getting burnt on their credit card bills.

I'll start tinkering in the cloud next year — pretty soon that is!

Happy new year! :)

Digging into WIF, or not.

A couple of weeks ago I attended a great talk by Dominick Baier on WIF (Windows Identity Foundation) at an NNUG meeting. I've been contemplating for some time to dig into WIF and learn first hand how just how beneficial the framework is. Mr. Baier's excellent presentation was the final push I needed to start investigating. But behold, WIF is nowhere to be found on my computer (XP, with VS2010). Intense googling revealed that the WIF SDK cannot be installed on Windows XP. From the download page at the Microsoft Download Center:

Supported Operating Systems: Windows 7;Windows Server 2003 Service Pack 2;Windows Server 2008 R2;Windows Server 2008 Service Pack 2;Windows Vista

Too bad. No WIF for me. Time to upgrade from XP I guess.

Please replace the floppy disk

I was typing away in a word document opened directly from my home directory over VPN. Then I got an amazingly cool error message! Apparently I was thrown "offline" for a minute:

"Please restore the network connection or replace the floppy disk and retry."

Nuff said.

Who framed Roger Badbit?

I recently blogged how to mitigate the clickjacking vulnerability with the X-Frames-Options HTTP header. Then XSS-track came to my attention, so I figured it would be a good idea to blog more in general about attacks employing frames. A general post mandates a general and catchy title (you have to agree that it is).

First, a few comments on the idea behind XSS-Track. In general, an XSS vulnerability lets you inject script into a particular webpage. If the user navigates away from this page, you've "lost" her. XSS-track injects script to load the attacked website in an iframe, which then becomes the user's view of the website. The user is left navigating the website in the iframe, which means that the XSS script survives in the parent page — a very elegant trick. By owning one vulnerable page, the clever attacker can gain access to all pages the user visits during a session on the targeted website.

Now to more general considerations on attacks that load your site in an iframe, and how the X-Frames-Options HTTP header can help.

Defeating Clickjacking

The clickjacking vulnerability is receiving an increasing amount of attention. There has been some interesting advances in exploitation techniques, as explained in this video: Next generation clickjacking by Paul Stone at the Blackhat Europe 2010 security conference.

Let's first summarize the basic properties of a clickjacking attack:

1. The attacker can load a page from your website in an iframe
2. The attacker can have the user perform mouse operations on your webpage, i.e. clicking buttons, dragging and dropping content etc.

If we can prevent a webpage from being embedded in an iFrame, the clickjacking vulnerability will be mitigated. Framebusting is the traditional approach to prevent clickjacking attacks — a javascript embedded in a webpage to detect framing and try to "bust out" of the frame.  However, a recent study by researchers at Stanford summarizes common framebusting efforts and concludes that framebusting fails to mitigate the risk.

Lesson learned: HTTP modules can also affect WebResource.axd

HTTP modules can be very useful. In fact, I love them. The scope of this post is unfortunately not to explain what they are or what they do. If you're not familiar with what a HTTP module is, get an overview here and see how to create one here.

ASP.NET features some built in handlers: WebResource.axd and ScriptResource.axd. You'll see requests to these in any ASP.NET application, as they're used to serve builtin scripts for e.g. postback or client side form validation. By default, the ASP.NET application will configure these to expire from cache after a year.

Today I discovered a side effect I had not thought about. HTTP modules are loaded by the application, and are hooked into the event pipeline for each and every request handled by the ASP.NET application. In fact, this also includes requests to the WebResource.axd and ScriptResource.axd handlers!

How to secure ASP.NET cookies

The release of Firesheep a week ago brought a lot of attention to a problem that has been known for many, many years: cookies sent over both secure and insecure connections to the same site. Why all the fuzz now? Well, first of all, "regular" people (as in non-geeks) can install Firesheep and start stealing Facebook sessions. With such a demonstration, people realize just how easy it is to "hack" another user's account. Secondly, we're all on Facebook, so we all feel that this affects us personally. We can relate to the risk, and it stirs our emotions. Thirdly, the media loves these kinds of demonstrations and can capitalize on the fear factor. This hack was simple enough and scaled nicely, which made it a good sell.

Now the debate goes on about Firesheep, here's a good blog post on the ethical aspects. In this post I also found a link to Microsoft's Malware center, their antivirus software apparently detects Firesheep as a hacktool. Like it really matters. Firesheep clones will pop up all over the Internet. The only viable path forward is to build websites not vulnerable to trivial eavesdropping attacks.

Firesheep has raised the bar for baseline security in web applications. Before Firesheep, you would be regarded as sloppy or lazy not to have secured your website's cookies. After the release of Firesheep, you're essentially committing a crime against your users — because now you (and they) know that cookies can easily be stolen.

If you need a basic introduction to what cookies are, check out the cookie article on Wikipedia.  The rest of this post discusses more technical aspects of cookie security.

Catch unhandled exceptions in ASP.NET

I came across an interesting article about errors occurring outside the context of a request. Apparently, such errors will put an end to your worker process. Source code for a module to catch and log such errors are included in the article, check it out!

Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0.

Some highlights from the RSA Euro conference '10

I just got back from London and the RSA Europe conference, I've had a great week! In addition to a solid program, the conference is a hotspot of highly skilled professionals. I ended up in a lengthy discussion at the Microsoft stand on the possibilities of the new Forefront Threat Management Gateway (TMG), and the Unified Access Gateway (UAG). One chat with a Microsoft professional, and I learned that the UAG is much more versatile than the official webpages indicate. Of course, I had many more interesting conversations with both sponsors and visitors to the conference. I have to mention that I was fortunate enough to bump into Steve Lipner from Microsoft while I was on my way from one session to another. I happened to be carrying around my SDL-book, he was kind enough to sign it. Good stuff!

I'll summarize some of my favorite sessions from the conference:

Keep ASP.NET error pages out of search engines

In a production environment, users should not be presented the default ASP.NET error pages. Instead they should be offered clean, understandable error pages giving them a sensible explanation of the error, along with suggestions to continue their journey on the website. Besides usability concerns, it's also an important security practice to not leak details about application details to those who might tinker with your application!

In ASP.NET, the customErrors configuration element is used to handle error situations. However, the behaviour of the custom errors is somewhat counterintuitive, as you might end up with your error pages indexed by search engines.

ASP.NET padding vulnerability explained and exploited

First of all, the ASP.NET padding oracle patch is now available through Microsoft Update. Patch your servers before you keep on reading!

The saga goes on as lots of information on the ASP.NET padding oracle vulnerability is becoming available around the Internet. Many articles surface that range from days to weeks old. One example is this very detailed explanation of the padding oracle attack, dated September 14th. Linked in the article is the Padbuster tool, which was updated to attack ASP.NET sites in version 0.2 quite recently. Others have also released tools, like the one at Minded Security Blog, dated Tuesday 28th. Note the fortnight in between these two posts. Looking at the first one, no wonder Microsoft was in a hurry to get a patch out!

With the current state of affairs, it would be reckless to not patch Internet facing servers. New tools to exploit ASP.NET are popping up rapidly around the Internet. Web application scanners will be updated to check for the vulnerability. If you still haven't patched your servers, start reading this post from the top again — but this time read the first sentence!

ASP.NET security patch, what's changed

I've snooped around with fiddler to see what changes have been introduced by the patch release today for the ASP.NET framework.

I've seen to notable differences in the behaviour of webresource.axd:

1. The d parameter is now set to a value much longer than before, it seems it's 50 bytes longer
2. Tampering with this parameter will not trigger a 500 server error and an entry in the application event log. A regular 404 error is returned to the browser, and nothing is logged in the event log.

My guess is that they have included an integrity check of some kind. Also, they've fixed the problem with error messages distinguishing between the different errors occuring. Now, it's all 404 errors.

Anyhow, it's time to go home from work. Unfortunately, my local time is quite far from PDT. Happy patching!

ASP.NET padding oracle, check your logs!

Microsoft has now released a patch for the padding oracle attack, but most system owners will still need some time to test the new patch before going live with it. Until the patch is applied we need to keep an eye on our logs in order to detect potential attacks.

In ScottGu's FAQ post he informs that an attack attempt would generate a large amount of entries in the application event log. In the subsequent update he presents a revised workaround to block requests with an aspxerrorpath parameter. To detect attacks involving this parameter, we also need to look at the IIS logs.

ASP.NET security updates are available

*Update 2* ScottGu's blog was once again the best source of information on the new developments, and on which updates to install for a particular system!


*Update* But of course. Links are included in Microsoft's security bulletin. 

For some reason the updates are somewhat hidden at the Microsoft download center. Anyhow, here they are:

• Microsoft .NET Framework 4
• Microsoft .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 
• Microsoft .NET Framework 3.5.1 on Windows 7 SP1 Beta and Windows Server 2008 R2 SP1 Beta
• Microsoft .NET Framework 3.5 Service Pack 1, Windows Vista Service Pack 2, and Windows Server 2008 Service Pack 2
• Microsoft .NET Framework 3.5 Service Pack 1 on Windows Vista Service Pack 1 and Windows Server 2008
• Microsoft .NET Framework 3.5 Service Pack 1 and .NET Framework 2.0 Service Pack 2 on Windows Server 2003 and Windows XP  
• Microsoft .NET Framework 3.5 Service Pack 1 on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
• Microsoft .NET Framework 3.5, Windows Vista Service Pack 1 and Windows Server 2008
• Microsoft .NET Framework 3.5 on Windows Server 2003 and Windows XP 
• Microsoft .NET Framework 3.5 on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
  
• Microsoft .NET Framework 1.1 Service Pack 1 and Windows Server 2003 Service Pack 2 (32-bit)
   

 Happy patching! :)

ASP.NET vulnerability gets fixed!

There has been quite some discussion (and speculation!) about the ASP.NET padding oracle vulnerability on various blogs around the Internet the last couple of days. After Microsoft published an advisory on it, the ASP.NET community has been following ScottGu's blog closely.

The issue has seen increasing attention. Yesterday the vulnerability was mentioned on Schneier's blog, where he provided a link to a Threat Post from Kaspersky where the guys behind the exploit were interviewed. The vulnerability and exploit tools were also discussed. The threat post was dated September 13, four days before Microsoft released the first security advisory on the issue. Since then, the amount of information on the vulnerability has only increased throughout the Internet. Now, there's so much information available from different sources that there's not much security through secrecy left.

ASP.NET padding oracle vulnerability, the video

A video of the POET-tool — used to exploit the ASP.NET padding oracle vulnerability — have been published to show the tool in action. The video shows the steps taken by the tool to compromise the web.config file of the application, which in this example contains the ASP.NET machine keys.

On the new ASP.NET vulnerability

Last Saturday (European time), Microsoft released the first version of a security advisory stating that a vulnerability in ASP.NET could allow information disclosure. In the initial report it seemed that a vulnerability had surfaced in a cryptographic function in ASP.NET. The risk appeared to be leakage of information from encrypted viewstate, but there was also a mention of the possibility to disclose files on the IIS. It was unclear whether these were combined or separate issues, but the issue seemed to be viewstate specific.

Windows server 2003 vs 2008, SSL/TLS comparison

There are many differences between the Windows server 2003 and the 2008 version. We'll focus on the SSL/TLS support in 2003 vs 2008, there are important differences in both default configuration and cryptographic support.

Hardening Windows Server 2003 SSL/TLS configuration

Though Windows Server 2003 has been around for a while, we'll still see them around the Internet for many years to come. Despite their usefulness, there are some important security considerations to make when running an Internet facing 2003 server.

SSL/TLS configuration, figure it out!

There are several ways to figure out  the SSL/TLS configuration of a webserver. If you're dealing with an Internet facing server, the quickest solution is to use a webpage like www.ssllabs.com or www.serversniff.net (Webserver -> SSL Info). SSLLabs will give a "management friendly" presentation of a server's SSL/TLS configuration, underlining that you need not be all l33t H4x0r to uncover a lax security config.