Cenzic 232 Patent
Paid Advertising
web application security lab

Finding 404s despite ErrorDocuments and fingerprinting IIS6.0

I happened upon an interesting way to detect 404 ErrorDocuments under Apache a few days ago that I thought might be relevant to the SEO (Search Engine Optimization) community. For those who don’t know know what ErrorDocuments are, they are catch alls that attempt to capture any traffic that is going to the wrong page and sends them to a known page that lets them know that “hey, you screwed up and here is an error page telling you that.” This is particularly useful for things like httprint that use server signatures to tell what a server is.

Anyway, the simple way to create an ErrorDocument under Apache is to create a .htaccess file in the root directory with something like this:

ErrorDocument 404 http://ha.ckers.org/

Here’s what a typical HTTP 404 page looks like:

HTTP/1.1 404 Not Found
Date: Mon, 26 Jun 2006 20:34:30 GMT
Server: Apache
Content-Length: 202
Connection: close
Content-Type: text/html; charset=iso-8859-1

Which accompanies text that says:

Not Found
The requested URL /BLAH was not found on this server.

Now that page will never appear if they are using an ErrorDocument, which screws up HTTP fingerprinting techniques. Instead you’ll see wherever they were sending you. That is, unless of course, you use a little trick. I found that if you include a NULL character along with the URL, you actually get another page (something like http://ha.ckers.org/BLAH%00 with the null at the end). Here is what you see:

HTTP/1.1 404 Not Found
Date: Mon, 26 Jun 2006 20:54:45 GMT
Server: Apache
Content-Length: 202
Connection: close
Content-Type: text/html; charset=iso-8859-1

With the text:

Not Found

The requested URL /BLAH was not found on this server.

Then I tried against an IIS6.0 server and got:

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Mon, 26 Jun 2006 20:51:11 GMT
Connection: close
Content-Length: 34

With the text:

Bad Request (Invalid URL)

As you can see, they are wildly different, despite the fact that the Apache instance above had an ErrorDocument. I have not been able to validate against the same type of error handling under IIS but based on this, I don’t believe IIS would handle the request at all, seeing it entirely as invalid (a 400 error instead of a 404 error). This could easily allow you to fingerprint a machine between IIS and Apache alone on a single malformed request, which could easily be built into httprint, xprobe or nmap or other similar tools.

Comments are closed.