HTTP (80 TCP)

HTTP (80 TCP)

Webservers are interesting beings - they are the most common service on the Internet - there are many of these running around. The two most common webservers 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 webserver - it is thus, in terms of control, a less "vulnerable" service as telnet. The problem nowadays with webservers are that they serve a whole lot of data- this is, a lot of them contains data

- 38 - Breaking into computer networks from the Internet

that is just as sensitive as the data that you will find on a corporate internal fileserver. The attacks to webservers 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 webservers. 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 webserver somewhere. Lets begin with straightforward IIS webserver -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 whisker that 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.com is virtually hosted. The forward entry for www.sensepost.com is 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
- Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
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 whisker manual? 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's attacks in many ways