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.

Towards more secure password hashing in ASP.NET

A couple of weeks ago I was remotely involved in a discussion on password hashing in .NET with @thorsheim, @skradel, and @troyhunt. (Follow them if you're on Twitter). The background for the discussion was that password hashing using MD5/SHA-1/SHA-256 isn't quite the state of the art anymore. All the recent password breaches have triggered recommendations to make password cracking harder. The algorithms that are usually recommended are PBKDF2 (Password based key derivation function), bcrypt, or scrypt. So which of these should you choose if you're working with .NET?

I'm a conservative guy. Cryptographic algorithms are very hard to get right, as there's all sorts of things that can go wrong when you implement them. Consequently, I prefer to use whatever is available in the .NET framework. That's because Microsoft have crypto-experts on staff, and they've also pioneered the SDL which means you should expect high quality implementations of their (security critical) software. So it's really a trust thing. At the time of writing, PBKDF2 is the only algorithm of the three mentioned that's readily available in the framework. You probably see where this is leading: bcrypt and scrypt are disqualified in my book. When it comes to cryptographic functions, stick with the framework! PBKDF2 is the best alternative for now.

Following the discussion on Twitter, @skradel shared a library where he had wrapped the built-in PBKDF2 as a HashAlgorithm. That way, PBKDF2 (through his wrapper) could easily be used by other parts of the framework, such as the SqlMembershipProvider. It really was an elegant solution. He blogged about it in: Strong Password Hashing for ASP.NET, you should check it out (@thorsheim was so delighted that he had to blog about it too :).

When you're dealing with PBKDF2, you'll see that it takes a couple of parameters. @skradel's already chosen some reasonable defaults in his implementation so it's all hidden and taken care of there. But if you were to implement this yourself and explain to someone how you chose those parameters, what then?

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:

IE auto-upgrades, plugins next?

Last week the IE team announced that they'll soon start to automatically upgrade IE across Windows 7, XP, and Vista through Windows Update. A follow up from Microsoft's IT pro team details that IE 6 and IE 7 will be upgraded to IE 8 on Windows XP, while Vista and Windows 7 users will get IE 9. With Microsoft joining the herd of auto-upgraders the final pieces of the puzzle start to fall into place, now "everybody" does it. Other major browser manufacturers (Opera, Chrome, and Firefox) have been auto-upgrading their installations for some time already. Apple's Safari now stands out in the crowd and it will be interesting to see whether they'll stick to their current update regime.

For Microsoft, this is yet another important step to kill of IE 6 which still has a considerable user base. Up til now they have been running campaigns urging users to upgrade their browsers. They actually have a website dedicated to kill of the browser, www.ie6countdown.com (I have to point out that Norway is leading the pack, with only 0.2% IE 6 users). Hopefully the automatic upgrades will have a notable impact on the remaining IE 6 installations.

In two earlier posts (one and two) I've advocated silent auto-upgrades as an important strategy to keep Internet users safe by providing them with timely security patches. Recently I came across an interesting study on the effectiveness of different Web browsers update mechanisms. It's definitely worth a read. (*Surprise*, it aligns just fine with my views so I can safely link to it).

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.

Making the web even safer: From auto-upgrade to silent updates

Mozilla now aims to add silent updates to Firefox — much like Chrome and Opera already does — as summarized in this Computerworld article. This marks an important milestone, and is an important follow up to Mozilla's decision back in June to auto-upgrade the then soon-to-be unsupported Firefox 3.5. Back then, I blogged about the importance of the bold decision to NOT leave users behind on an unsupported version.

Later in June when Firefox 5 was released, Firefox 4 users where prompted to update to the new version. I was so excited, I had to blog about that too.

Now Mozilla has decided to introduce silent updates to Firefox. From Mitchell Baker's blog we can learn that:

Before Mozilla instituted the rapid release process, we would sometimes have new capabilities ready for nearly a year before we could deliver them to people.  Web developers would have to wait that year to be able to make their applications better.

And why is that a problem?

A browser is the delivery vehicle for the Internet. And the Internet moves very, very quickly.

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. :)

Firefox 5 is out and #4 wants to upgrade

Following up on my recent blog post on how auto-upgrade as opposed to auto-update of web browsers can help make the Internet a safer place, here is the prompt I just got from Firefox 4:

Gotta love it! Firefox 5 is a "security and stability update". No lengthy explanations on why version 5 is better than 4, and an "Upgrade Now" button. User's would want to install this! I also like the prompt I get when one of my add-ons won't work with the new version.

Making the web safer: From auto-update to auto-upgrade

The Firefox team has decided to stop supporting Firefox 3.5. They've put a great deal of thought into how they will handle the ~12 million Firefox 3.5 installations around the world. Firefox 3.5 will be updated to the latest 3.6 version, through the auto-update system — which really makes it an auto-upgrade. The plan is to start pushing the upgrade on June 21st, in conjunction with the release of the new Firefox 5. The team has shared their assumptions and rationale for the decision in a Firefox 3.5 EOL article on the Mozilla wiki.

The decision to upgrade users' soon to be outdated and unsupported browsers is important. Home users' computers are under constant attack. The stream of software updates is both endless and rapid, especially when taking into account that there are updates to the operating system, web browsers, and commonly installed software such as Adobe Acrobat and the Java Runtime. The average user should be relieved from having to deal with all the different update notifications and procedures. Apple have been leading the way here for many years already. If you do a Google search for "security update" flash you'll see why: They've been supplying updates to the Flash player for many years through their update system. The Chrome team chose the same route in April when they included an updated version of Adobe Flash with their latest Chrome release — fixing a vulnerability in the Flash plugin in addition to three in Chrome. The simpler the job for users to keep their systems up-to-date, the more users will be running the latest, greatest, and safest software.

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.

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.