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.