Jeremiah from WhiteHatSec has just written a quick piece on how to find your websites. Now Footprinting is obviously dear to our hearts, with 3 Blackhat talks on it (or applications of it) (“Automation – Deus ex Machina or Rube Goldberg Machine?“, “Putting The Tea Back Into CyberTerrorism“, “The Role of Non Obvious Relationships in the Foot Printing Process“), a commercial tool almost dedicated to it, and a full blown chapter on it in Open Source Penetration Testing by charl and gareth. Footprinting is a genuinely important part of a companies security assessment, cause it doesn’t matter if they have multi-layer firewalls and WAF’s protecting the web app on their www.company.com, and an old barely used sql-injectable form on their community.company.com site that lets you grab SA on their SQL server anyway..
(Now that the shameless self promotion is over..) i wanted to touch on an interesting aspect of webserver discovery that is often skipped, and thats the issue of multiple websites running as name based virtual hosts on the same web-server. There was a time (not so long ago) when all of the popular scanning tools, failed to take into account that scanning 209.61.188.39 was not the same as scanning www.sensepost.com (or hackrack.sensepost.com which happens to be on the same ip address).

Quick Virtual Host Refresher:

An HTTP/1.1 compliant browser (you will struggle to find one that is not) sends along an additional required field when requesting a website, the Host: header.

So.. while a GET on our website looked like this using HTTP/1.0:

haroon$ telnet www.sensepost.com 80
Trying 209.61.188.39...
Connected to www.sensepost.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 200 OK
With HTTP/1.1 you also have to specify a host-header:

haroon$ telnet www.sensepost.com 80
Trying 209.61.188.39...
Connected to www.sensepost.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.sensepost.com

HTTP/1.1 200 OK

This allows the web-server to correctly route the request to the name based virtual host running on it.What should be obviously apparent is that in the above example, attacking 209.61.188.39 != attacking www.sensepost.com != attacking hackrack.sensepost.com

There is every possibility that a highly vulnerable CGI exists on www.sensepost.com/scripts/vuln.cgi which will not exist under 209.61.188.39/scripts/vuln.cgi or hackrack.sensepost.com/scripts/vuln.cgi

Therefore, if you _were_ running a cgi scanner like nikto or wikto against the IP, you would probably miss the cgi that (in many cases) would have allowed you to compromise the host.

So.. 3 quick tips on this..

1. use one of the many online sources that attempt to map ip addresses to other websites running on them [www.domaintools.com, www.iptoolbox.fr] (you might just find test.company.com and get the beta version of their website prior to them turning on their sanitization features)
2. if you are using a scanner, make sure you are aiming it right..
3. if you are hosting your site at some ISP, ensure that you know who are hosted with. You could get owned just because someone else on the same box happened to have sloppy code (and the web-server setup doesn’t segregate you properly).