Scanning Virtual hosts For CGI holes - By Rapture

Ever scanned a domain name, found a hole and when you try to exploit it, it doesn't excist? Wondering how so many domain names can all be on the same IP address?

Most webservers nowadays (especially Apache with it's Virtualost directive, and IIS with its virtual host setup wizards) allow you to assign many actually domain name/websites to the same IP.

Well, hell...how does the server know which site you want when you connect?
Well, browsers give a second piece of information, the 'Host' directive.
So, a request may look like: GET /~rfp/index.html HTTP/1.1 Host: www.el8.org
So say we have SlikWilly Virtual Hosting, they run off RedHat Linux using Apache. They setup their only IP (as that's all they could afford for their £15/month shared DS0) to host the site www.slikwilly.com. Now, on the actual box, the location for their files are in /home/httpd/html/ for html files, and /home/httpd/cgi-bin/ for, whatelse, but their CGI apps. So a request to www.slikwilly.com/index.html is going to be pulled from /home/httpd/html/index.html. So far, so cool.

Well the powers that be at Defcon decide that they've had it with catalog.com, since ADM hacked their webpage there. They want to move over to SlikWilly.com in hopes that it will keep those ADM people from changing the site. So Slik Willy himself hops into his httpd.conf and adds a VirtualHost directive for www.defcon.org. He sets up the html directory to be /home/defcon/html/, so that those Defcon people can ftp in via his nifty wu-ftpd-2.4.2(beta 18). So that means that www.defcon.org/index.html should be pulled from /home/defcon/html/index.html. Slik Willy also gives them their own cgi-bin, located in /home/defcon/html/cgi-bin/ (which means it's no silly aliased directory, since Slik doesn't understand all that stuff). So, now, in this situation, www.defcon.org is a *virtual* site off of www.slikwilly.com (the root site). What exactly does that mean will happen? Well, let's see:

If I give the request: GET /index.html HTTP/1.0

I will get back the file at (assuming it exists): /home/httpd/html/index.html

which is Slik Willy's file (www.slikwilly.com)If I check for:
GET /cgi-bin/test-cgi HTTP/1.0

I will be checking for:
/home/httpd/cgi-bin/test-cgi

which is again Slik Willy's file (www.slikwilly.com)

Now, if I check for:
GET /index.html HTTP/1.0 Host: www.defcon.org

I will get back:
/home/defcon/html/index.html

which is the www.defcon.org homepageSimilarly:
GET /cgi-bin/test-cgi HTTP/1.0 Host: www.defcon.org

I will be checking:
/home/defcon/html/cgi-bin/test-cgi

which is in www.defcon.org's cgi-bin.
Now, why does any of this matter whatsoever? Well, imagine you wanted to be like ADM, and try to hack www.defcon.org again. So you whip out your trusty cgichk.c CGI scanner (oooh, you hacker you) and rev it up against www.defcon.org. Well, guess what--the scanner connects to Slik Willy's box, does generic requests (no Host), and winds up scanning Slik Willy's cgi-bin for cgis, not the actual www.defcon.org's cgi-bin. And there exists the possibility that www.defcon.org had way cooler stuff than Slik Willy.

But lemme just make it known, this usually works in your favour. For instance, on IIS, the virtual hosts will *NOT* (unless specifically added) have /scripts mapped to them--but the root site will. So, trying to GET /scripts will work off the main (generic) site, but if you try a virtual host with Host directive, most likely /scripts won't be mapped over. Same for Slik Willy. test-cgi comes by default in /home/httpd/cgi-bin/, not /home/defcon/html/cgi-bin. So scanning the root site is better to find the 'default' install CGIs.