Remember hash DoS? This was that very clever yet equally nasty little attack which meant that if you formatted the parameters in a post request juuuuust right you could take down an ASP.NET website with a mere single request. Bugger.

This made for a rather unpleasant Christmas and New Year period for a number of people at Microsoft as well as sys admins the world over. Microsoft had rapidly released a the MS11-100 critical patch or in other words, the stop-what-you’re-doing-and-install-it-RIGHT-NOW patch.

But it wasn’t really a patch per se in that it didn’t fix the underlying vulnerability which was related to hash collisions. Instead, it stopped an attacker from posting more than 1,000 form parameters to a website so think of it more as a pre-emptive defence rather than a fix.

I also had a bit of a rush around this time because I wanted to get ASafaWeb scanning for the presence of the patch. Oftentimes developers do not have direct visibility into the patch level of the infrastructure they’re running on so I wanted a means of self-assessment. It was easy too – all I had to do was post 1,001 form parameters and if the website returned an error, the patch was installed. If it didn’t then it meant the request was being processed and the patch wasn’t present. There were a couple of twists and turns (such as the request object needing to be accessed in an MVC app for it to work), but for the most part, it all went swimmingly.

Now Microsoft has gone and broken my scan – and I couldn’t be happier. Today I ran all my ASafaWeb integration tests which checks the scan results against a number of sites and suddenly my test against the deliberately insecure ASafaWeb test site at notasafaweb.apphb.com was failing. I mean the formal unit test was failing because it expected the hash DoS scan to pass (the AppHarbor infrastructure it runs on was patched very quickly), but for some reason the hash DoS scan was now failing.

The other component of the integration test that was failing was that it expected the ASP.NET version of the website to be 4.0.30319.272 yet it was coming back as 4.0.30319.17929. This is the version number you get back at the bottom of a stack trace and it includes the last segment of digits (the version returned in the X-AspNet-Version header does not). Coincidence? I think not, and here’s why:

As many readers and followers will know, I’ve had a bit of fun with scammers in the past. Remember those guys who call you up while you’re sitting down for dinner and tell you your computer has all sorts of nasties in it? Yeah, those guys.

The blog posts I’ve made have been part of the story and inevitably the one most people are familiar with, but there are a few other things happening which I think some of you would be interested in, particularly as it helps understand the bigger picture.

The catalyst for this post came after getting some good airtime last week. One thing that can be easily done and has a very significant impact is to raise peoples’ awareness (stick around – I’m going to ask for some help with this). Last week I was interviewed by Today Tonight (a national Aussie current affairs show) which aired at 6:30pm on Friday. I don’t know exact viewer numbers, but I assume its seven figures. Here’s the video (click through to their website):

As a result of that show, numerous people realised they’d been had and promptly cancelled payments. I’ll come back to some examples of this shortly, but first, let me try and shed some light on the tactics these guys are using as its a little cleverer than what many people are giving them credit for.

It was three weeks ago now that I wrote about Lessons in website security anti-patterns by Tesco where I pointed out a whole raft of basic, flawed practices which jeopardised the security and privacy of shoppers. These practices in and of themselves were (are) bad, but what really seemed to fire up a lot of people was Tesco’s response when I first flagged it with them:

1,883 retweets later, numerous media articles and a chorus of software and security professionals decrying Tesco’s approach to security (and customer service, for that matter) including one of the industry’s most preeminent security brains referring to their password security as “lousy”, and nothing has changed. One of the things that hasn’t changed is their continued assertion that there’s nothing to see here – no security problems, move along now“

It happened again. After 6pm, unlisted number, foreign accent. I’ve heard this before. And again before that. And again before that too. And again a bunch of other times where I either didn’t record it, came on a bit strong or, uh, tried to teach them some new words they may not have heard before.

I’ve also interviewed the man behind one of the original scams (it has undoubtedly been copied by other scammers) and petitioned LogMeIn to stem the spread of the scam (also had a very nice chat with them – but to no avail). In short, I’ve given this some thought before.

But there was something very, very different about tonight’s call; the scammers were (allegedly) only a few k’s away from me. They also left a Sydney phone number (which I verify at the end of the video) and they knew my surname when they called. Oh – and another unusual trait – they were polite. Even when confronted, Austin (yes, as in The Spy Who Shagged Me) kept it cool so bully for you, Mr. Powers.

Here’s what happened:

I had an interesting question pop up on my “SSL is not about encryption” blog post this weekend:

I have a question about logging to site like StackOverflow which doesn't use SSL at all.

If I am login to SO via Google. Is this secure in this case?

This is actually a very good question for a number of reasons so I thought it deserved a little more attention than just the short response I gave on the blog. The question implies there is some sort of absolute state to security (probably unintentionally) where a site such as Stack Overflow is deemed to be either “secure” or “insecure” (hence the quotes in the title).

The reality is that there are a few more twists to it than that and Stack Overflow in particular is an interesting case study due to their use of a third party authentication provider. What this blog post will show you is that in this particular case, we’re really looking at two different security domains with different levels of protection and in the case of Stack Overflow, yes, it’s kind of secure – but then it’s also kind of insecure too…

I started building ASafaWeb – the Automated Security Analyser for ASP.NET websites – about a year back to try and automate processes I found I kept manually doing, namely checking the security configuration of ASP.NET web apps. You see, the problem was that I was involved in building lots of great apps but folks would often get little security configurations wrong; a missing custom errors page, stack traces bubbling up or request validation being turned off among numerous other web app security misdemeanours.

The thing is, all these things are very easily detected remotely without any access to the source code, you just need to make a few HTTP requests and draw some conclusions based on the structure of the responses. I wanted to make it dead easy for people to run these scans on their sites so I built ASafaWeb, put a great big text box on the front page to take a URL and said “Here you go”. This was – and still is – ASafaWeb on demand:

Since December 2011 when I began logging de-identified data, ASafaWeb has racked up over 27,000 on demand scans. When I analysed the scan results a few months ago, two thirds of websites were found to have serious configuration vulnerabilities. Clearly ASafaWeb was finding a lot of problems with ASP.NET websites.

But one thing that continued to nag me was that websites aren’t static; a website passing a scan today in no way guarantees it will pass tomorrow. The ease of configurability in ASP.NET remains both a strength and weakness and every time we release there’s that risk that a change in configuration has introduced a vulnerability. This is why today I’m releasing the next phase of ASafaWeb beta to the public – scheduler:

It should be apparent by its name, but my intention with the scheduler is to not only make sure a site is “safe” today, but that it remains that way. That’s my need, and I believe it’s the need of many others too.