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: