.NET Rocks talks security with Carl, Richard and Troy

Yep, this Troy! Right at the tail end of my Christmas holidays a couple of weeks back I had the pleasure of having a great chat with these guys:

In case you’ve been living under a rock (no pun intended), for the last nine and a half years, .NET Rocks is without doubt the foremost .NET themed podcast in the universe. By the time they got to me, there had already been 734 prior episodes (frequently running for an hour or more), so the series has well and truly become ingrained in the psyche of many a .NET developer. How many developers? Apparently about 250,000; yes one-quarter-of-a-million-.NET-developers. Wow!

For me, over the last few years it’s been one of the very, very few podcasts where I’ll religiously listen to every episode, regardless of the content. Carl and Richard have become a part of my daily drives, long flights and exercise regimes on a pretty regular basis.

My talk came at a good time for application security (depending on your perspective). We’d just capped off a year of unprecedented website hacking and just when we thought it was all over, along came Stratfor and then the hash DoS situation. During this time I also wrapped up the OWASP Top 10 for .NET developers series, packaged it all into a nice little eBook and launched ASafaWeb.

In the show we talk about each of the OWASP Top 10 web application security risks and how to mitigate them in .NET plus head off on a few tangents about some recent hacks, password management and the all-important pronunciation of “ASafaWeb” and “OWASP”. I had a ball recording the show (despite my internet failing and having to resort to Skype on iPhone over 3G), and every impression I had of Carl and Richard was reinforced both on and off the air. Great guys who love their technology and are passionate about sharing it with anyone who’ll listen.

So here it is, enjoy!

Episode 735 – Troy Hunt Secures ASP.NET

Breaking CAPTCHA with automated humans

We’re all familiar with CAPTCHA right? That impenetrable fortress of crazy squiggly characters that only a real human can decipher. Whilst they tend to drive us a bit nuts, they do actually provide a valuable function in that they prevent the automation of requests against online services. For example, you can’t get yourself a Google account without first wrapping your head around what on earth this one says:

Why does Google do this? Well, once you create yourself a Google account you’ve now got GMail and G+ and all sorts of other platforms which could be used to perform such nefarious activities as generating spam, distributing malware or creating false identities. Once you can automate this, these activities can be performed en masse.

It’s a similar deal with Western Union:

It’s easy to imagine that being able to automatically create accounts at a financial institution might open the gateway to all sorts of monetary shenanigans. And if you’ve already been able to create a GMail account, you’ve got everything you need to begin batching the creation of identities at Western Union.

So CAPTCHA prevents all this, right? Only humans can break the code and complete these signup processes, right? But what if we could automate the humans; I mean what if we could take CAPTCHAs and solve them at such a rate that these registration processes could be easily automated? Well it turns out you can and it will only cost you a couple of bucks.

Zappos, Stratfor, Sony, Gawker; Got your attention? Good, now start using a password manager!

Another week, another major security incident with a significant website. So the news this time is that Zappos – those guys who sell shoes (among other things) – to folks in the US may have, uh, accidentally disclosed somewhere in the order of 24 million user accounts. Bugger.

Now of course at the root of this is inevitably yet more evildoers intent on breaking through website security for financial gain, activism or just plain old kicks. Regardless of the modus operandi of these incidents, the fact remains that a significant number of accounts have been exposed and there’s now the real possibility that usernames and passwords – perhaps your username and password – are going to be floating around the internet being seen by who knows how many people.

This, of course, is a problem because statistically there’s a better than average chance you’ve used that password in a number of other locations. Did you use it for eBay? Was it the same one you used for Amazon? Or even worse, is it your Gmail password and it can now be used to reset all your other passwords? If you’re asking yourself any of these questions right now, it’s time for a password manager which makes it dead easy to create strong, unique passwords across all your accounts so that the next time this happens – and there will be a next time – your credential exposure and your risk won’t go beyond that single site.

ASP.NET session hijacking with Google and ELMAH

I love ELMAH – this is one those libraries which is both beautiful in its simplicity yet powerful in what it allows you to do. Combine the power of ELMAH with the convenience of NuGet and you can be up and running with absolutely invaluable error logging and handling in literally a couple of minutes.

Yet, as the old adage goes, with great power comes great responsibility and if you’re not responsible with how you implement ELMAH, you’re also only a couple of minutes away from making session hijacking of your ASP.NET app – and many other exploits – very, very easy. What’s more, vulnerable apps are only a simple Google search away. Let me demonstrate.

Update: I want to make it clear right up front that the out of the box ELMAH configuration does not make any of what you’re about to read possible. It’s only when ELMAH is configured to expose logs remotely and not properly secured that things go wrong.

Has the hash DoS patch been installed on your site? Check it right now with ASafaWeb!

Back in September last year we saw the emergence of the padding oracle vulnerability which suddenly got a whole lot of ASP.NET developers very nervous. The real concern with this vulnerability was that there really wasn’t much you could do at the code level beyond a couple of little tweaks – what was really needed was for patches to get installed on servers and fast.

The problem back then was that, well, you couldn’t always trust your hosting provider. Hosting providers take all sorts of different shapes; corporate servers managed by IT groups, dedicated machines with dedicated hosts, shared co-tenanted machines and now more and more frequently, cloud based solutions. But one thing remained constant and that was that the patch Microsoft had quickly released needed to get onto the machine.

Back then I talked on my blog about how to remotely detect the patch. But what I didn’t talk about was that I’d written an app to automate this check. Like many with responsibility for a number of sites, I was too busy making sure things were patched to get that little piece of software into a form suitable for sharing. Today, things are a little different…

5 website security lessons courtesy of Stratfor

Just when you start thinking we’ve seen out the last of the major security breaches for 2011, Christmas day brings us one final whopper for the year: Stratfor. Much has already been said about why they might have been hacked and who might (or might not) have done it, but the fact remains that there are now tens of thousands of customer passwords and credit card details floating around the web. Oh, and apparently about 5 million internal emails ready to be released.

So what do we take from this as website builders? The benefit of hindsight gives us a good opportunity for reflection as we watch the fallout unfold from the last major breach of the year. Let me share the 5 lessons I’m taking away from this.

Free eBook: OWASP Top 10 for .NET developers

Writing this series was an epic adventure in all senses of the word:

Duration – 19 months to complete a blog series, for crying out loud!

Content – approaching 50,000 words, not including all the discussion in comments.

Effort – some of the posts, such as transport layer security, probably approached 100 hours of reading, trialling, experimenting and finally, writing and proofing. This is why there was a four month “hiatus” before that post!

But most of all, it was an epic learning adventure for me. Writing the series forced me to know this content in depth, not just the depth that facilitates casual conversation and allows me to send people off to figure out how to fix their flaws, but the depth to really get to grips with these risks, ensure I could exploit them and then make sure I could fix them again.

For example, I knew – and many of us know – that unsalted hashes are vulnerable to a rainbow attack but I’d never actually executed one of these attacks myself. So I did. Same again on sniffing packets; knowing that lack of transport protection leaves network traffic vulnerable is one thing, sitting in the car outside McDonald’s and actually capturing wifi traffic and hijacking the session (my own, that is!) is another thing altogether.

Looking back on it, I’m really happy with what I’ve produced. It’s been a great experience for me and by all accounts, it’s been very well received by the .NET and OWASP communities as well. It turns out I might have actually produced something pretty useful!

So I decided to turn it into an eBook. Oh – and give it away for free. No strings attached. So here it is, 255 pages of .NET web development security goodness. Please share it generously, chuck it on your eBook reader, email it to your mates, quote me, force your developers to print and read every page – whatever – it’s all yours:

[ click to download ]

If you find it useful, leave me a comment, flick me an email or fire me through a tweet as the feedback really is appreciated. Happy reading and happy holidays everyone.

OWASP Top 10 for .NET developers part 10: Unvalidated Redirects and Forwards

This entire series is now available for download as a free eBook.

In the final part of this series we’ll look at the risk of an unvalidated redirect or forward. As this is the last risk in the Top 10, it’s also the lowest risk. Whilst by no means innocuous, the OWASP Risk Rating Methodology has determined that it takes last place in the order.

The practice of unvalidated redirects and forwards, also often referred to as an “open redirect”, appears fairly benign on the surface. However, it can readily be employed in conjunction with a combination of social engineering and other malicious activity such as a fraudulent website designed to elicit personal information or serve malware.

What an unvalidated redirect does is allows an attacker to exploit the trust a user has in a particular domain by using it as a stepping stone to another arbitrary, likely malicious site. Whilst this has the potential to do considerable damage, it’s also a contentious vulnerability which some organisations consciously choose to leave open. Let’s take a look at how it works, how to exploit it then how to protect against it.

Beyond YSlow - Squeeeezing out website network performance

I’ve had a lot of conversations with folks recently about web app performance. Often these conversations have been around the assertion that a content distribution network (here forth referred to as a CDN), is something you need to deploy early on in the optimisation process of a website. Personally, I see a CDN as a last resort; it’s what you turn to when all other performance tuning alternatives have been exhausted and you need to eke out that last little bit of latency by moving the content closer to the audience. It’s not a replacement for good website optimisation, it’s an enhancement.

One of the main problems with a CDN is simply this: people still have crap connections. It doesn’t matter if I can put the content in the same city as the audience, if they’re in a location where “broadband” is a 1Mb connection or even if they’ve got a super-fast service but the 3 kids are all simultaneously downloading torrents, you’ve got a problem. How well optimised the site is now matters a lot more than how close the content is to you.

The point I’m making is this: well optimised content is king. If you can get that video down from 2Mb/s to 500Kb/s (sounds like a lot but I frequently see this sort of scenario), or dramatically slash the number of HTTP requests and the content size on a web page, you’re going to reap those benefits under any circumstances. This is where you have to start; get this right first because it’s the fastest, cheapest way to add performance.

So it got me thinking: how much improvement can be made on an already well-optimised site, I mean one that scores very well against existing performance yardsticks? How much faster can you go without spending dollars on a CDN? Turns out there are big gains to be made very quickly – and it costs just a tiny bit of development time.

Welcome to ASafaWeb

Websites get hacked. Lots. This year alone we’re looking at some absolute whoppers; Sony, EVE Online, Sony, pron.com, Sony, MySQL.com, did I mention Sony?

Many times, the gateway to successful website exploits is simple misconfiguration. Custom errors were left off and thus leaked internal code. Or request validation was turned off which opened up an XSS flaw. These risks are often then leveraged to do other nasty stuff.

The thing is, many of these are also easily remotely detectable – certainly the bad guys know this. What I mean is that configuration vulnerabilities are apparent just by making the right requests to the website. Not “hacking” it in any sort of malicious context, just simply making some innocuous requests and inspecting the responses. This is what ASafaWeb does – the Automated Security Analyser for ASP.NET Website - and I’m very happy to now introduce it at asafaweb.com