Hardening Windows Server 2008/2012 and Azure SSL/TLS configuration

I guess it was long overdue for me to follow up on my Hardening Windows Server 2003 SSL/TLS configuration and Windows server 2003 vs 2008, SSL/TLS comparison posts. They were two of my very first blog posts and they still receive a decent amount of traffic. The world has fortunately moved forward since then, so in this blog post we’ll have a look at the default configuration of recent Windows Server (WS) versions in light of the latest recommendations from SSL Labs. We’ll keep the discussion at a reasonably high level, but I’ve included references to more in-depth information along the way for those who want to dig into the details. We’ll finish off with an announcement (Hint: it might have something to do with TLS configuration and Windows Azure).

Ramping up ASP.NET session security

OWASP recently released their Top Ten 2013 list of web application vulnerabilities. If you compare the list to the 2010 version you’ll see that Broken Authentication and Session Management has moved up to second place, pushing Cross Site Scripting (XSS) down to third place. Apparently authentication and session related issues are moving up in the world!

It’s not that surprising, there’s so many things that can go wrong. It seems that authentication and session management is so difficult to get right that even the big players occasionally get in trouble. I’ve blogged earlier about a Google 2-step verification vulnerability I discovered back when they were rolling out the system (yes, I admit it took more patience than effort to find that one), and if you do a Google search for "authentication flaw" you’ll get plenty of hits for many high profile sites. This indicates that we need to tighten up our authentication and session management. In this post we’ll focus on some issues related to session management, and at the end I have an announcement to make!

OWASP has a great guide on what you should test for in your session management. If you’re familiar with the Microsoft SDL you’ve probably noticed that it also has a set of recommendations for session management. We’ll dig into some of the details of ASP.NET session management to see how it fares against some of these requirements.

First things first, we’ll need to set the scene with an overview of how ASP.NET handles identities and sessions and then we’ll return to the requirements.

Some important ASP.NET 4.5 security improvements

The .NET 4.5 framework was released a couple of months ago and it included several improvements in the security area. To benefit from these improvements you need to do a few changes to you application's configuration file. The documentation is a bit scattered over MSDN and MSFT blogs, I figured I'd collect them here for easy reference.

The ASP.NET team published a nice article on What's New in ASP.NET 4.5 and Visual Studio 2012. There you'll learn that:

• There are changes to the ASP.NET request validation, it now supports deferred (lazy) validation, as well as giving the option to fetch data unvalidated.
• The AntiXSS library is included in the framework.

However, there's no mention of two other important changes:

• There are significant Cryptographic Improvements in ASP.NET 4.5. Read it! This is important stuff!
• Windows Identity Foundation is now included in the framework, referred to as WIF 4.5.

To take advantage of these new bits you'll have to do a bit of configuration, we'll get into that right away.

How to encrypt a custom configuration section in ASP.NET

Recently I wrote a piece of software that needed some configurable secrets — and they needed to be VERY secret. Consequently, I had to encrypt a custom configuration section. Unfortunately, I quickly ran into trouble and got an error message along the lines of:

Encrypting configuration section...
An error occurred creating the configuration section handler for myConfigSection: Could not load file or assembly 'MyAssembly, Version=2.0.0.0, Culture=neutral' or one of its dependencies. The system cannot find the file specified.
...
Failed!

Disheartening, eh? I looked to the Internet and the advice seemed to be to copy the "missing" assembly to the .NET framework folder. I strongly suggest you don't do that, messing around in the framework's folder is not recommended. That folder belongs to Microsoft.

Fortunately I found a much easier workaround. I'll give an example where I encrypt the configuration section for the NWebsec security library, in the DemoSiteWebForms project that's part of the project's solution.

Security through HTTP response headers

Security headers in an HTTP response

There are many things to consider when securing a web application but a definite "quick win" is to start taking advantage of the security HTTP response headers that are supported in most modern browser. It doesn't matter which development platform you use to build your application, these headers will make a notable difference for the security of your website anyway!

The screenshot shows what the security headers look like. The security headers are included in the web server's response to a browser — instructing the browser to enable (or disable) certain security features. They're invisible to the user, but you can have look at them with tools such as Fiddler or the developer tools that are built into the major browsers. In IE or Chrome press F12, in Opera (Ctrl+Shift+i), in Firefox (Ctrl+Shift+k), for Safari have a look here to enable the developer tools.

A great thing about these response headers is that they're very easy to get started with. In many cases you might not even have to change a single line of code in your application as you can set the headers either through your application's configuration, or they can likely be set by whatever web server you use.

If you're building ASP.NET applications I would like to point you to NWebsec, an ASP.NET security library that lets you easily configure these headers for your application. Go and have a look at the documentation, it explains how you can configure the headers through web.config. Don't worry, if you're the MVC kind of person you can use filter attributes instead. You'll find the library on NuGet so you'll be up and running in a matter of minutes! Disclaimer: I built it, so I think it's pretty cool.

A quick note: Last year, I gave a lightning talk at the ROOTs conference about the role browsers play for your online security. There I also discussed security headers. Slides and video are online if you want to check them out: "The browser - your best friend and worst enemy" (slides / video).

Now let's have a look at the headers and how they can improve the security of your website.

Generating secure Guids

Guids are used extensively throughout Microsoft systems and developers tend to turn to Guid.NewGuid() whenever they need to create a value to uniquely identify something. Guids might also be used as keys or identifiers in security critical operations — under the assumption that they are hard to guess for an attacker. I've been looking around the Internet to see if I could find some guidance on Guid security along with details on how they are generated in the .NET framework. I couldn't find much information, but I did find that Eric Lippert from the C# team recently raised some concerns about the Guids on his blog. So I started digging around to see what more I could find out.

First of all a quick background. Microsoft's Guid is their implementation of the Universally Unique IDentifier (UUID) outlined in RFC 4122. UUIDs are 128 bits, and the Guid class generates version 4 UUIDs, meaning that all bits except those defining the version and variant of the UUID are "random." Please note that 4 bits are used for the version number, and two bits are used for the variant — so it's not a 128 bit random number, it's a 122 bit random number.

How to enable WIF token replay detection

Windows Identity Foundation (WIF) is vulnerable to replay of security tokens in its default configuration. The "Replay Detection" article on MSDN presents a good example of how things can go wrong without the replay detection (why do everyone have to use online banking as their example?):

As another example, suppose that a user opens a browser on a public kiosk, logs on to a bank account using the bank’s Web site, logs off and leaves, but does not close the browser. The response to the user’s logon page, which contains the STS token, is still in the browser’s history. Another person could then browse back to that response page and replay it, which would repost the STS token to the bank’s Web site.

This scenario is very much real and it does not involve any fancy hacking techniques. All you need is a browser and a "back" button. You'll find some scattered references on the Internet to the solution of the problem, the tokenReplayDetection configuration setting. You'll find a mention of the configuration element in the WIF FAQ on Technet and in the WIF book, but you'll find the most helpful explanation in the ACS security guidelines.

I'll cut to the chase, here's the config to enable the token replay detection. Please don't use the parameters as is, read the security considerations and tweak the values accordingly. Seriously.

How not to hash passwords in .NET

In connection with a bug in TransformTool, I've been looking into how text encoding is handled in the .NET framework. Turns out there are some caveats that can affect the correctness of a program, and when used in e.g. password validation they might turn out to be severe security issues.

This post assumes you are somewhat familiar with how character encodings work. You might want to check out my Introduction to character encoding if you're not. I wrote it mainly because I didn't want to explain the basics of encodings in this post.

The encoding issues/features I discuss here are all well documented in the article Character Encoding in the .NET Framework, but I believe that the issues aren't that well known. Stack overflow, blogs, and discussion forums are riddled with insecure code samples. Do a Google search for "ASCII.GetBytes" password, and you'll get a lot of results. I even found insecure code examples in a text book, the C# 2008 Programmer's Reference (page 344). So I definitely believe we need to raise awareness of these issues in the .NET community.

Encoding subtleties
In the MSDN article on character encoding you'll find that the first suggestion on how to use the encoding objects in .NET is: 

Use the static properties of the Encoding class, which return objects that represent the standard character encodings available in the .NET Framework (ASCII, UTF-7, UTF-8, UTF-16, and UTF-32). For example, the Encoding.Unicode property returns a UnicodeEncoding object. Each object uses replacement fallback to handle strings that it cannot encode and bytes that it cannot decode.

And people love to use the static properties! But if you don't read this carefully and pause with the "replacement fallback", you might get into trouble. "Replacement fallback" means that every character that cannot be encoded to bytes will be replaced with the "?" character silently. But what does that mean? Time for a demo using the ASCII encoding:

Base64 decode online — are you sure?

Are you using one of the many web pages that let you base64 decode data? In that case you should take a moment to think about the nature of the data you want to decode and what those pages could be doing with the data — apart from showing you the decoded version.

tl;dr: Check out transformtool.codeplex.com for an offline alternative to the online Base64 decoders.

Google's keyword tool reports 9,900 monthly searches for "base64 decode online". How many of these searches lead to disclosure of sensitive business information, or personal information (PII) to one of the Base64 decoding webpages? None of these searches are from IT-professionals trying to figure out what's wrong in a production system, right?

Top Google results for "base64 decode online" at time of writing

Update Java — or just remove it

Oracle recently released an update to its Java software, fixing more than 20 critical security issues in the software. Krebs has a good post on the update, briefly discussing the vulnerabilities and the fact that Java vulnerabilities are exploited for real.

I have to say that in recent years I've installed Java more due to habit than because of an actual need for the software. So when I got the update bubble in the corner of my screen, I figured "of course". I knew they, among other things,  fixed the same-origin-policy bypass used in the BEAST attack (You'll find a straight forward explanation of the Java vulnerability here, and links to resources on BEAST here). So I started the update process, and this was one of the first screens I was presented.

A Google 2-step verification vulnerability

Early this year Google started rolling out their new two-factor authentication procedure, which they refer to as 2-step verification. On their corporate blog they provided a few hints on why they were rolling out a new authentication procedure — mentioning risks associated with password reuse and phishing attacks. 2-step verification is now widely deployed, by June it was available in 150 countries, and in 40 different languages.

Of course, I took interest in how the two-step verification was designed and I discovered a couple of design issues. In addition I discovered a security flaw that qualified for Google's vulnerability reward program, so I engaged in a responsible disclosure process with Google. Now they've fixed the bug, my reward has been donated to charity, and I've received my 19 bytes of fame, so I guess it's time to blog about this. I'll focus on the security bug here, and blog about the design issues later. I need to do some investigation to see whether Google fixed any of them or not, as they reported that they were re-evaluating some of their design decisions.

If you're unfamiliar with how the two-step verification works, see Google's video below (borrowed from Getting started with 2-step verification).

Now, straight to the point.

Bugs get fixed

My bug reporting has been on fire lately. This week I received confirmation from the Google security team that a security bug I reported was found worthy of a reward (a couple of weeks ago Google fixed some issues in their two-step verification procedure). I'll be blogging the details on the security issue anytime soon.

Just now, my hotmail told me that the Visual Studio 2010 firewall setup bug I blogged about last month will be fixed in the next major release of Visual Studio. Cool!

Now, if I could only find and fix my own damn bugs. :)

Sneaking into Google+ uninvited

After seing reports on Twitter that "everyone" now was on Google+, and not having received an invite e-mail myself, I had an intense feeling of being left out. So yesterday, I started tinkering.

There's been several ways into Google+, just after the launch the reports were that a Google+ user could share something with you, and you were offered to join Google+ to see the shared content. Along came also the possibility for Google+ users to invite people directly (which led to people selling their invites). To get in line for Google+, you could also sign up at the Google+ website. I had signed up, and turns out I had also been invited by two friends (I was in their circles already), but without receiving a notice from Google. I was curious to find out what was behind the signup screen shown below, so I had to do something!

Norwegian Facebook users first victims of automated attack?

Norwegian media reports of a supposedly attack on Norwegian Facebook users, here's a link to the Norwegian news article.

Facebook users are calling their local police about the incident, phones started ringing at 22:15 CEST. At the time of writing, reports indicate that users near the city Haugesund were first affected. Users have explained the attack to the police as follows:

First you receive a "message" (unclear if it's a message or a wall post), stating: "You are next." Then your profile picture is changed to some sort of animation. Finally, the attackers change your password, and you lose access to your account.

An enjoyable statement from the police: "There's little we can do. We can't just send a patrol car into Facebook."

I'm logged into Facebook right now and haven't noticed anyting unusual, and I'm unable to find similar stories on the Internet. Have Norwegian Facebook users gone crazy (or the police), or are we seeing the start of a potent attack on Facebook users? Judging from the news article, the attack does not necessarily require user interaction. It could be a Facebook worm. I'll be interesting to see tomorrow how the situation develops.

And for the record: The article is dated April 5, so this should have nothing to do with April  fools' Day.

***Update*** April 7.
I contacted the journalist who wrote the story, they hadn't followed up on the matter. But if this was a real attack, I bet it was one of the password stealing apps on Facebook.

Why security questions are not

The other day, I received an "encrypted e-mail" through the Cisco Registered Envelope Service. Their "about" page states:

If the envelope is password-protected, it can only be opened by authorized recipients who authenticate themselves. If you are a first-time recipient receiving a password-protected secure envelope, you will be asked to register with the service to set the password which will be used to authenticate you.

I had never used the service, so I had to register before I could get access to the e-mail. To my surprise, I had to choose three security questions and provide an answer to them before the registration could be completed.

Introduction to authentication

The last couple of months large players such as Microsoft, Google, and Facebook have announced changes to their login procedures and how they authenticate their users. Facebook and Hotmail offer single-use codes to avoid compromise of users' regular passwords. Google has rolled out a new (optional) two-step verification for access to Google accounts. These are interesting changes in functionality to increase the security for users on the Internet.

I'll be blogging about some of these authentication procedures. To lay the foundation for my upcoming blog posts on authentication I figured it would be a good idea to give a quick rundown of what authentication is, just to get the basics out of the way. Here it goes:

Authentication defined
If you consult the Oxford dictionary on your iPhone you'll learn that:

authenticate:
prove or show (something) to be true, genuine, or valid;

When we authenticate users of computer systems, what are we trying to prove? In short, that the correct people are logged in to the correct user accounts. So, for computer systems we'll see that it makes sense to use the following definition:

Authentication is the process carried out to show that a user is who she claims to be

To explain what this means we'll break a typical authentication procedure into two phases: the user claims to be the owner of a digital identity, and we need to verify that the claim is true before the user is allowed to assume the claimed identity.

Even more Android security issues

Researcher Jon Oberheide explains on his blog how users can be tricked into installing apps on their Android phones — through an XSS vulnerability! This tops of the last weeks fuzz about Android security.

On Saturday, the Google mobile team blogged about how they would deal with the malware spread through their Android Market — the same day they confirmed that there were 58 different malicious apps that had been downloaded onto around 260,000 Android devices.

At the beginning of February I blogged about the dangers rising from the Android market's web driven installation routine. Oberheide now showed one scalable way to take advantage of the market store. Others remain.

Steal a Google account and get a free OTP device!

I just read an interesting article on the Naked Security blog: New Android Market web store could open backdoor for phone hackers. Turns out, you can trigger installation of applications from the store and the installation procedure will silently complete on the Android phone. This could be a cool feature — but it comes with severe security implications for login procedures relying on mobile phones.

How to give IIS access to private keys

If one of your ASP.NET applications need to access to a certificate from the certificate store along with its private key, you'll probably run into trouble. The private key is saved in a special file with an unguessable name. It's not readable for everyone (for obvious reasons). The lack of file access is not very intuitive, as you can see the certificate in the Certificate MMC snap-in, and it will claim that "this certificate has a corresponding private key". You'll still have to give the application pool's user read access to the key.


There are some differences in how to do this for the 2008 R2 and the 2003 server, here's a short explanation and some useful resources for both versions.

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.