HTTP 80 TCP

Web servers are interesting beings - they are the most common service on the
Internet - there are many of these running around. The two most common
web servers are Microsoft IIS and Apache. They run respectively on Windows
and UNIX (although Apache is available from Windows as well)...but you knew
this right? In most cases (except for one) one generally cannot get full
control over a web server - it is thus, in terms of control, a less
"vulnerable" service as telnet. The problem nowadays with webs ervers are
that they serve a whole lot of data- this is, a lot of them contains data that is just as sensitive as the data that you will find on a corporate
internal file server. The attacks to webs ervers can be categorized- attacks
that returns data that the server should not be returning (e.g. Abusing your
rights on the server), executing commands on the server (even taking control
of the server) and stopping the server (denial of service attacks). There
are many tools out there that will scan a server for exploitable CGIs (these
includes PERL scripts, DLLs, EXEs, PHPs and others) as well as looking for
interesting directories or files. The tool we prefer (and we think a lot of
people will agree) is something called whisker (by Rain Forrest Puppy, get
it here http://www.wiretrip.net/rfp/p/doc.asp?id=21&iface=1). The latest
version of whisker is version 1.4. Whisker is a PERL script that does
intelligent scanning of web servers. We don't want to go into too much detail
of the inner workings of the scanner - there is plenty of documentation on
RFP's site - the bottom line is that whisker is highly configurable, and
very effective. One of the more useful features of whisker is that it uses a
vulnerability "database" - thus the engine uses "plugins", and the plugins
can be updated. The security community adds new "signatures" every now and
again to the database - this keeps the scanner current with all the new
vulnerabilities that are discovered.
How do we use whisker? Give me a practical example! OK - let us assume that
we want to scan a web server somewhere. Lets begin with straightforward IIS
web server -no authentication, no SSL, no special cleanup, and no IDS - just
static pages. We start whisker as follows:
perl whisker.pl -h 196.xxx.183.2
This host happens to be the primary MX record for the domain xxx.co.za. If
we can control this host, we can probably also get some interesting data.
The server was chosen because it does not facilitates virtual websites, and
is a stock standard IIS version 4.0 server - with no additional data. Its
prima function is that of mail serving - not serving webpages. The output
looks like this:
-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net --
= - = - = - = - = - =
= Host: 196.xxx.183.2
= Server: Microsoft-IIS/4.0
+ 200 OK: GET /msadc/Samples/selector/showcode.asp
+ 200 OK: GET /msadc/samples/adctest.asp
+ 200 OK: GET /iisadmpwd/aexp4b.htr
+ 200 OK: HEAD /msadc/msadcs.dll
+ 200 OK: HEAD /_vti_inf.html
+ 200 OK: HEAD /_vti_bin/shtml.dll
+ 200 OK: HEAD /_vti_bin/shtml.exe
We can see that this host has a few vulnerabilities - maybe the most serious
of them is that it hosts "msadcs.DLL". Abusing this DLL one can gain
complete control of the server. The "Showcode.asp" ASP can be used to view
any file on the same drive as the webroot, and the "aexp4b.htr" can be used
to do brute force password attacks on the server. The scope of paper is not
to describe every one of the 300 odd vulnerabilities that whisker tests for.
We will rather concentrate on different scan types, bypassing IDS systems,
connecting to SSL-enabled servers, and brute forcing authentication systems.
Lets look at some of the parameters that can be passed to whisker, and how
we would use them (at this stage of the discussion the reader should REALLY
try to read RFP's whisker documentation - get it here:
http://www.wiretrip.net/rfp/bins/whisker/whisker.txt. We will only look at
the common switches). One of the switches that is very useful is the "-V"
switch - his tells whiskerthat the target is a virtually hosted site, and
it will thus add the "host: XXX" entry in the HTTP header. But - how do we
know if a site is virtually hosted? Let us assume that I want to find out if
the site www.sensepost.comis virtually hosted. The forward entry for
www.sensepost.comis 216.0.48.55. When I open a browser and enter the IP
address 216.0.48.55 I get to a totally different website. The webserver
running on 216.0.48.55 thus looks at the HTTP header and decides what page should be served - a virtually hosted site. Should I test for URLs (say
brute forcing URLs) with whisker, we would thus add the -V switch, and
specify the DNS names - not the IP number. If we should spec the IP number
we will not be looking at the website www.sensepost.com, but at the
underlying webserver - which might not be a bad idea, but maybe not the true
intention. Hey - did I mention to read the whiskermanual? Another switch
that is used frequently is the -I switch. The -I switch fires up whisker's
stealth mode - the IDS bypassing module. How does an IDS work - it looks for
patterns or signatures. If we can disguise our patterns the IDS may not
detect it. The -I switches disguise whisker'sattacks in many ways - making
it hard for an IDS to find us.