Web Server Defacements (Part 1)
There was a large commotion last year over the web server defacement contest, which was to be held by various online miscreants. The act of defacing a company's web site is one that has been going on for some time now. In reality this has been practiced largely by the bottom feeders of the internet community. To actually go out, and place your own index.html file into a compromised web server does not take a great deal of talent I assure you. Where the talent lies is with the coder who discovered a web server exploit, and coded a way of leveraging it in the first place. Once this exploit developer has publicly released the code is when the script kiddies step in. What the script kiddies lack in talent they make up for in numbers.
These types of attacks are relatively commonplace today. Personally speaking I work in the network security industry, and have heard many of my peers write off these attacks as "script kiddie" stuff. While I would agree with them on that statement the problem is that these very same peers of mine don't know how to do a web page defacement themselves.
To defend you must learn to attack
This brings me to another favorite whipping horse of mine. If you are going to defend your computer networks from various attacks it then behooves you to learn how they are attacked in the first place! Not all of my peers agree with this assessment, but I most certainly do. It is hard to grasp something if you yourself have not done it is my opinion. In this specific case it would help to understand just exactly how does one deface a web page. I say this because if you were studying the packets logged by your intrusion detection system it would be helpful to recognize the packets you are looking at as being someone uploading a new index.html page would it not? Otherwise you might just write it off as someone requesting a web page.
If one were to do this act of electronic vandalism then there are certain conditions, which must be met. What do I mean by that? Well simply put you need to have a way of compromising that web server, whether it be IIS or Apache. Having a firewall in place is not going to be much help in this case for the company is offering the web server, as a service for their clients, and potential clients to view. For these clients to do so the port must be open in the firewall thereby allowing them access to the web server. You could have an application layer firewall in place to help protect this service, but that is another issue entirely.
Let's set the stage
Well we now know that for an exploit to work certain criteria must be met. Call it a series of if's if you like. If the service is vulnerable, and if it is exposed to the web, and if..... Well you get the picture. What we shall do is actually go through all of the steps necessary to compromise a web server, and then upload our own version of the index.html page. To that end let me list what we shall be using operating system wise as well as what type of web server.
I performed this defacement in my home lab using two laptops. One of them had SuSE Linux installed on it, and the other laptop had Windows 2000 Professional on it. On the W2K laptop I had also installed the open source Apache web server specifically version 1.3.17. There are vulnerable versions following the release of 1.3.17 but we will be using this one for our recreation purposes. Why am I using this specific version of Apache you may be asking right now. Good question! I would refer you back to my earlier assertion that to exploit something there is always a set of criteria to fulfill. In this case this version of Apache for Windows was vulnerable to the apache chunked encoding vulnerability.
Details, details, details...
This is all fine and lovely but just where do you get the exploit code yourself then? Not only that, but how do you know that there are no "added value" features in this exploit code? Well to simplify our life I used the Metasploit Framework. This framework was put together by HDM and spoonm, and not only that it was released freely for the public to use. The advantage in using this tool is that you can safely use all the accompanying exploits without fear of any backdoors. Lastly the framework can be used in either Linux or a win32 environment. Pick your poison as it were. In my case I ran it under Linux seen as this is where I have my tftp server running, which will be used during the course of this endeavor.
Well our list of requirements to perform our own web page defacement is filling out nicely.
Metasploit Framework to actually launch the exploit
Windows 2000 Professional with Apache 1.3.17 installed on it
Two laptops connected via a switch
Bring on Metasploit!
To wrap up part one of this article series we will have a brief look at Metasploit itself. I will in part two walk you through step by step on how to use it, but will show some of it below to give you a sneak peek. What I won't be covering is the actual installation of it as it is really rather straightforward. Please bear in mind once again that I have used it within Linux.
The below noted shows all the directories and files created once the Framework has been uncompressed.
[email protected]:~/framework-2.2> dir
drwxr-xr-x 2 500 10000 112 2004-08-07 17:50 data
drwxr-xr-x 2 500 10000 744 2004-08-07 17:50 docs
drwxr-xr-x 2 500 10000 280 2004-08-07 17:50 encoders
drwxr-xr-x 2 500 10000 1288 2004-08-07 17:50 exploits
drwxr-xr-x 2 500 10000 144 2004-08-07 17:50 extras
drwxr-xr-x 6 500 10000 208 2004-08-07 17:50 lib
-rwxr-xr-x 1 500 10000 4687 2004-07-29 23:41 msfcli
-rwxr-xr-x 1 500 10000 22975 2004-07-29 23:41 msfconsole
-rwxr-xr-x 1 500 10000 5744 2004-07-05 06:52 msfdldebug
-rwxr-xr-x 1 500 10000 5639 2004-07-29 23:41 msfencode
-rwxr-xr-x 1 500 10000 1538 2004-08-07 17:58 msflogdump
-rwxr-xr-x 1 500 10000 2104 2004-07-29 23:41 msfpayload
-rwxr-xr-x 1 500 10000 9361 2004-07-27 03:38 msfpayload.cgi
-rwxr-xr-x 1 500 10000 6952 2004-07-29 23:41 msfpescan
-rwxr-xr-x 1 500 10000 12096 2004-08-08 04:37 msfupdate
-rwxr-xr-x 1 500 10000 16116 2004-08-07 18:31 msfweb
drwxr-xr-x 2 500 10000 120 2004-08-07 18:17 nops
drwxr-xr-x 3 500 10000 1664 2004-08-07 17:50 payloads
drwxr-xr-x 3 500 10000 168 2004-08-07 17:50 sdk
drwxr-xr-x 3 500 10000 80 2004-08-07 17:50 src
drwxr-xr-x 2 500 10000 216 2004-06-07 04:21 tools
The below noted shows how to invoke the Framework and specifically the msfconsole
[email protected]:~/framework-2.2> ./msfconsole
__. .__. .__. __.
_____ _____/ |______ ____________ | | ____ |__|/ |_
/ \_/ __ \ __\__ \ / ___/\____ \| | / _ \| \ __\
| Y Y \ ___/| | / __ \_\___ \ | |_> > |_( <_> ) || |
|__|_| /\___ >__| (____ /____ >| __/|____/\____/|__||__|
\/ \/ v2.2 \/ \/ |__|
+ -- --=[ msfconsole v2.2 [30 exploits - 33 payloads]
Now we can see from the above that the Metasploit Framework actually has 30 exploits and 33 payloads available. Very impressive I must say, and not only that it is free to use unlike some other similar commercial offerings. With this teaser in hand we will break here and resume in part two with further Metasploit usage to achieve our goals; furthering our knowledge computer security. See you soon!