Back in July I went to the Idaho Department of Transportation's website with the intent to renew my car registration. I was rather surprised that the connection was "reset by peer". OK, their site is having trouble. I'll just come back later, right? Next day, same thing. That's when I got suspicious. I played around for a while and discovered that by changing the browser identification string, I could get in. Well, that was good because I was rather uninterested in getting arrested for driving illegally.
Once things settled down, I wrote to their webmaster and complained. I was a little rude the first time, yammering on about tax dollars and discriminating. I knew that would get their panties in a wad, and it worked. They responded and asked for clarification. I provided them with quite detailed info (maybe too detailed) and offered to work with them to get it resolved. They never wrote back and I forgot about it.
Well flash forward to this evening when the same thing happened again, this time on Idaho Public Television's website. I knew it couldn't be a fluke that I'd get the same reaction with the same workaround. One difference is that I've been to Idaho PTV's website on this computer before, using this same browser, so they must have changed something on their end to cause it.
First I eliminated Cold Fusion which Idaho PTV is using but IDT isn't. Then I looked at the web servers, Idaho PTV is IIS 5.0 and IDT is IIS 6.0. Well I had assumed they must be running IIS because what other crack pot web server out there would do something so inane?
Finally I stumbled upon the perfect test: grab a capture of the headers that Firefox sent and make slight alterations until I figured out the exact character or combination of characters to break their site. And that is what I did. I saved the headers to a text file and piped them to netcat, that most useful of network tools. Here is the browser string as it appeared unaltered:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20061201 Firefox/18.104.22.168 (Ubuntu-feisty)
Starting from the end, I removed "(Ubuntu-feisty)" from the browser and tried it out. VoilÃ ! That was the offending part. Lucky for me I got it on the first try.
I narrowed it down by process of elimination to the four characters "isty". They can appear anywhere in the User-Agent header and it will immediately cause IIS to send a TCP reset. Not even an HTTP error code, but a RST. I tried it in other headers and there was no problem (e.g. X-Linux-Distro: Ubuntu-feisty).
The only sense I could make out of this behavior is some sort of security setting in IIS. It's doing some sort of content analysis and determining that anybody who uses the letters "i", "s", "t" and "y" in the User-Agent header is a bad guy. With logic like that, you'd think the IIS team was working for the TSA. Hmm, a conspiracy maybe? Anyway, I remember when I was a lowly IIS admin that there was some security lockdown tool that Microsoft recommended. I wonder if that's what's doing it. Or maybe it's an antivirus software. It's hard to say. I think I have a good lead with Idaho PTV since it just started happening. Surely they must remember the changes they've made to their production web server. I might just write to them and find out.
In the mean time, I smell some sort of nefarious hack here but I can't come up with anything good. Somehow you've got to be able to leverage this bug to bring doom upon unsuspecting IIS users. If you've got any ideas, please post them in the comments.