Defacing Acme Travel, Inc. s Web Site

Defacing Acme Travel, Inc.'s Web Site

ACME Travel, Inc., is a small Houston travel agency. It has been in business for years, catering to business travelers and vacation seekers. The company carries out almost all of its business over a toll-free phone number. In early 2000, the owners decided to get their own domain, www.example.com, and Web site from the site-hosting company AcmeHosting.net, based in Chicago. The company's jack-of-all-trades computer maintenance guy, Rob, doubled as the Web site manager for Acme. He had a good working knowledge of Linux and had set up a Linux proxy server for the company's employees, enabling them to share Internet access via a DSL connection. Rob also set up an Apache server on the proxy system to let Brooke, the receptionist/graphics artist, maintain a "staging" copy of the company's Web pages.

Acme's Web site had only eight static HTML pages and a few images. The only purpose for having the example.com domain name was to present Acme Travel's "electronic brochure" to Internet users. The most important bit of information it carried was the firm's toll-free phone number. Figure 9-1 shows what Acme Travel, Inc's Web site looks like.

Figure 9-1. Acme's Web site at www.example.com/acmetravel/

graphics/09fig01.gif

The firm's other purpose for having example.com was to provide Acme Travel's employees with e-mail addresses so that they could correspond with their clients via e-mail. Rob configured the Linux proxy with SMTP, fetchmail, and POP3 to provide this capability.

It was one such e-mail message that Mallory was gazing at, late one night in November, after having returned from visiting his family in Indiana. The e-mail was an itinerary of his trip sent to him by Acme Travel, Inc. His trip had been miserable. Instead of getting an aisle seat, he got a middle seat at the very rear of the plane. His request for a vegetarian meal had also not been communicated to the airline. What bothered Mallory the most was the extra $30 handling fee that Acme Travel had levied for processing his reservation. And it hadn't saved him much money either. He could have obtained the same fare from the airline directly.

Being a security geek, Mallory decided to teach Acme Travel, Inc., a lesson. An IP trace and quick portscan of www.example.com showed that the site was actually being hosted by acmehosting.net, and he found nothing of interest on its servers. Other than SSH and HTTP, no ports were open and nothing but static HTML pages and image files appeared. Looking at the e-mail, something dawned on him. The company obviously had some sort of Internet access for sending and receiving e-mail, and it must have a small network, an intranet, in the office. Apparently, there was no way to locate Acme Travel's Internet presence. The e-mail header read:

X-Apparently-To:mallory21@netmail.com via web13508.netmail.com
Return-Path:<service@example.com>
Received:from server326.ord.acmehosting.net (EHLO example.com) by mta497.netmail.com
with SMTP
Received:from [10.3.2.1] by example.com (8.8.8/8.8.5) with ESMTP id RAA08342 for
<mallory21@netmail.com>
Message-ID:<3C93CC2F.83281269@example.com>
Date:17 Aug 2001 04:20:23 +0530
From:"Acme Travel Service" <service@example.com>
Organization:Example.com
To:mallory21@netmail.com
Subject:TICKET CONFIRMATION
 
________________________________________________________
  EXAMPLE.COM
  T I C K E T  C O N F I R M A T I O N
TEL (800) 555-ACME  www.example.com

The "Received:from [10.3.2.1] by example.com" line gave away Acme Travel's IP address. Mallory immediately ran a portscan on 10.3.2.1. Nmap came back with the following open ports:

Port  State  Service
22/tcp  open  ssh
25/tcp  open  smtp
80/tcp  open  http
110/tcp  open  pop-3
8001/tcp  open  http-proxy

Mallory found that ports 22, 25, and 110 were blocked by TCP wrappers. The only points of attack would be port 80 and port 8001. Other than a DSL router, no IP addresses adjoining 10.3.2.1 were active.

Mapping the Target Network

Mallory now had a reasonably good idea of what the network looked like. In fact, his guess was quite close to the actual network implementation. Figure 9-2 shows the network layout.

Figure 9-2. Acme Travel, Inc.'s office network and hosted Web site

graphics/09fig02.gif

Acme's employees can surf the Web through the HTTP proxy server via port 8001 on 10.3.2.1 and send e-mail through the SMTP daemon running on the same machine. A cron script invoked fetchmail every five minutes to retrieve e-mail from example.com and distribute them to the local intranet mailboxes on the Linux server. Incoming traffic, except SSH connections from Rob's cable modem IP at home, was blocked by TCP wrappers. Apache was used as both the internal Web server, running on port 80, and the HTTP proxy server, running on port 8001. Apache had been configured to allow addresses only within the 10.0.1.x range and from 127.0.0.1, the local loopback address. Rob had no intention of letting anyone else into the network.

Mallory tried to access both ports 80 and 8001 from his browser. His requests were met with a "403 Forbidden" response each time, as shown in Figures 9-3(a) and (b).

Figure 9-3. HTTP requests on ports 80 and 8001 denied

graphics/09fig03.gif

Mallory didn't give up. He wanted to try one final attack before sleep took over and hopes of revenge faded.

Throwing Proxy Servers in Reverse

Mallory's last try was to see if the Apache server on 10.3.2.1, running on port 8001, was configured improperly. If it allowed inside addresses to send HTTP proxy requests out, it might also allow HTTP proxy requests in.

Using netcat, Mallory sent "GET http://127.0.0.1:80/HTTP/1.0" to port 8001. This HTTP proxy request asked the proxy server on port 8001 to open an HTTP connection to 127.0.0.1 on port 80, retrieve the HTTP response and the data, and send it back to the requesting client. The following output shows that this trick worked!

C:\hack\acme>nc 10.3.2.1 8001
GET http://127.0.0.1:80/ HTTP/1.0
HTTP/1.0 401 Authorization Required
Server: Apache/1.3.12 (Unix) PHP/4.0.6
WWW-Authenticate: Basic realm="special directory"
Content-Type: text/html; charset=iso-8859-1
 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>401 Authorization Required</TITLE>
</HEAD><BODY>
<H1>Authorization Required</H1>
This server could not verify that you are authorized to access the document
requested. Either you supplied the wrong credentials (e.g., bad password),
or your browser doesn't understand how to supply the credentials required.<P>
<HR>
<ADDRESS>Apache/1.3.12 Server at redproxy Port 80</ADDRESS>
</BODY></HTML>

Mallory got one step farther. Instead of receiving an HTTP 403 "Forbidden" response, he received an HTTP 401 Authorization Required response. This response was issued by the Apache server running on port 80, not port 8001. The reverse proxy technique had worked! Let's pause for a moment to figure out how exactly this attack worked. Figure 9-4 is a pictorial representation of what happened.

Figure 9-4. Using and abusing an HTTP proxy server

graphics/09fig04.gif

If users of the company's intranet wanted to access Web sites on the Internet, their browsers had to be configured to use http://10.0.1.1:8001/ as an HTTP proxy server. In Figure 9-4, the user on 10.0.1.12 is making an HTTP proxy request for fetching pages from http://www.yahoo.com/. This request is directed at the server 10.0.1.1 on port 8001. The proxy server then sends an HTTP request to www.yahoo.com, receives the data sent back to it, and passes it on to the client at 10.0.1.12.

The proxy server is a dual-homed system, with one intranet interface 10.0.1.1 and one external intranet interface 10.3.2.1. When Mallory tried to access http://10.3.2.1:80/ or http://10.3.2.1:8001/, he received an HTTP 403 Forbidden response code. The server was configured to reject incoming HTTP requests from any IPs other than 10.0.1.1-254 and 127.0.0.1. However, the fact that HTTP proxy requests were allowed for any IP address had been completely overlooked. Rob may well have left it out unintentionally while configuring the proxy server. Hence when Mallory sent an HTTP proxy request for http://127.0.0.1/ to 10.3.2.1, port 8001, the proxy server diligently carried out the request. It established a connection with the Web server running on port 80 on the same system, gathered the HTTP response, and passed it back to Mallory's Web browser. The "craftiest hack of them all" discussed in Chapter 6 is a similar attack.

The next step for Mallory was to set up the browser to automatically proxy all requests through 10.3.2.1, port 8001. Figure 9-5 shows Netscape being configured to use 10.3.2.1 as a proxy server.

Figure 9-5. Configuring Netscape for proxy use

graphics/09fig05.gif

Now, all that Mallory had to do is request the URL http://127.0.0.1/ in the browser and the request would be proxied off 10.3.2.1:8001, but he didn't expect to see an HTTP 401 Authorization Required response. The site administrator really wanted to keep users off the Web server! However that didn't stop Mallory, as you'll soon see.

Brute Forcing HTTP Authentication

Of all the application layer protocol authentications, perhaps HTTP authentication is the easiest to crack by using brute force. Three types of HTTP authentication are currently in use: Basic, Digest, and NTLM. Basic authentication was the first attempt at protecting areas of a Web site with a password. Whenever a browser encounters an HTTP 401 response, it pops up a dialog box requesting a username and a password from the user. When the user enters the appropriate credentials, they are encoded by the Base64 encoding scheme and sent along with new HTTP request to the server for the same resource. The server decodes the Base64 encoded string and verifies the credentials against those stored on it. If the username and password match, the server sends an HTTP 200 OK response, along with the data of the resource requested. If the credentials don't match, the server sends an HTTP 401 response again.

NTLM authentication is used on Microsoft IIS to authenticate users with Windows NT accounts. Digest authentication involves hashing the credentials with MD5 and a nonce. Digest authentication isn't supported by Netscape or Internet Explorer and hence hasn't gained popularity. Opera is the only popular browser that supports Digest authentication.

Upon encountering the HTTP 401 response, Mallory dug through his Perl scripts directory to find his old HTTP brute-forcing script. Mallory had thrown together this script by using the Library for WWW access with Perl (LWP). The Perl script needed two files, users.txt, containing a list of usernames, and words.txt, containing a list of passwords. Mallory had written a subroutine, "permute()" to permute passwords, using various techniques such as changing the case, reversing the letters, appending numbers and symbols, and even transforming the word into "hacker speak," which involves replacing certain letters such as "e," "l," and "t" with "3," "1," and "7," respectively. The script had to be modified to accommodate brute forcing over an HTTP proxy, which ended up being done with ease because LWP has methods that support HTTP proxies.

The following code is the modified version of Mallory's HTTP brute forcer Perl script:

01: #!/usr/bin/perl
02:
03: use LWP::UserAgent;
04:
05: open(USERS, "users.txt") || die("Cannot open username file");
06: open(WORDS, "words.txt") || die("Cannot open password file");
07: @users = <USERS>;
08: @words = <WORDS>;
09: close(USERS);
10: close(WORDS);
11: permute(@words);
12: $ua = new LWP::UserAgent;
13: $ua->proxy(['http'] => 'http://10.3.2.1:8001');
14: $request = new HTTP::Request 'GET',"http://127.0.0.1:80";
15: $i = 0;
16: $flag = 0;
17:
18: foreach $user (@users) {
19:  chomp($user);
20:  foreach $word (@words) {
21:  chomp($word);
22:  printf("\n%5d Trying $user,$word ", ++$i);
23:  $request->authorization_basic($user, $word);
24:  $result = $ua->request($request);
25:  if($result->is_success) {
26:  $flag = 1;
27:  print "Success!!!\n";
28:  last;
29:  }
30:  }
31:  last if $flag;
32: }
33:
34: sub permute {
  :  ...
  : }

The script is straightforward. Lines 5 through 10 load the usernames and passwords into arrays. Line 11 invokes the "permute()" routine on the array "@words" to permute the passwords. Lines 12, 13, and 14 create an LWP object and initialize it with the HTTP proxy address and port and the target URL as http://127.0.0.1:80. The two nested loops between lines 18 and 32 cycle through each combination of a username and a password. Line 23 generates the appropriate HTTP Basic authentication request and line 24 issues the request to the proxy server. Line 25 checks whether the request results in an HTTP 200 OK response, which would then terminate the brute forcing.

After running this script on the target server, Mallory managed to crack a username and password combination on his 386th attempt! The last few lines of output from this script are:

  364 Trying admin,6acme
  365 Trying admin,7acme
  366 Trying admin,8acme
  367 Trying admin,9acme
  368 Trying admin,0acme
  369 Trying admin,10acme
  370 Trying admin,12acme
  371 Trying admin,123acme
  372 Trying admin,123acme
  373 Trying admin,#acme
  374 Trying admin,!acme
  375 Trying admin,abcacme
  376 Trying admin,passacme
  377 Trying admin, acme
  378 Trying admin,travel
  379 Trying admin,TRAVEL
  380 Trying admin,levart
  381 Trying admin,Travel
  382 Trying admin,trav3l
  383 Trying admin,trave1
  384 Trying admin,7ravel
  385 Trying admin,trav31
  386 Trying admin,7rav3l Success!!!
 
C:\hack\acme>

The username "admin" had succeeded with a password of "7rav3l," which is "travel" in hacker-speak. Mallory had loaded the password file with "acme," "travel," and some other commonly used passwords.

Mallory had overcome the authentication hurdle. He can now use the Netscape browser configured with 10.3.2.1:8001 as a proxy and the "admin/7rav3l" user account to poke into the Web site on 10.3.2.1, port 80. Figure 9-6 shows Mallory entering the user credentials in the browser when requesting http://127.0.0.1/ through the proxy server.

Figure 9-6. Successful HTTP authentication clearing following 401 response

graphics/09fig06.gif

Directory Browsing

What happened next was quite unexpected. After Mallory figured out a way to use reverse proxy requests and brute forced the HTTP authentication, the server lay exposed. Too exposed, in fact. Instead of coming up with a Web page, the server displayed a list of the Web document root directory. This result was indeed a stroke of luck for Mallory because it eliminated a lot of guesswork and made poking around the site easy, directory by directory. Figure 9-7 shows the directory listing on the server.

Figure 9-7. Directory listing appearing in the browser

graphics/09fig07.gif

Directory listings are usually shown when there is no default document, such as index.html, that the Web server can locate. If the default document doesn't exist, the server will display a directory of contents unless explicitly configured not to do so. Rob hadn't turned off directory listings.

Three directories appear in the browser: /admin/, /images/, and /stage/. Mallory decides to look at the /stage/ (staging) directory first, the contents of which are shown in Figure 9-8.

Figure 9-8. The staging directory on the proxy server

graphics/09fig08.gif

Voila! The staging directory contains an exact copy of the Web site www.example.com. Mallory now understands that the site would have been designed by some folks in the office and pushed out to the hosted Web server as needed. Now, Mallory's attention turns towards the /admin/ directory. Browsing it produces yet another directory listing, as shown in Figure 9-9.

Figure 9-9. Directory listing of the /admin/ directory

graphics/09fig09.gif

There seem to be two scripts here. One of them, replicate.sh, appears to be a Unix shell script instead of a CGI script. The other one, sitemgmt.php is a PHP script for some sort of site management. Requesting replicate.sh returns the entire contents of the script. To the Web server, a shell script is the same as a text file and it gets returned as is. The contents of replicate.sh are:

#!/bin/sh
#
# Replication script for uploading to hosting site
# maintained by rob@example.com
# Script invoked from crontab to sync web pages
 
scp -qCr -i /home/rob/.ssh/rsa_keys ../stage/* \
  example@server326.ord.acmehosting.net:/example/
 
# add an entry in the log that replication was successful
 
date >> /tmp/replication.log

This script is actually called to replicate the Web site on the staging directory to the server hosted by acmehosting.net. Rob uses SSH's scp with RSA keys to copy the /stage/ directory on server326.ord.acmehosting.net, which is where space for the www.example.com site is allocated. This server holds a user account called "example," and all Web pages for www.example.com are kept in a directory called /example/. This server seemingly hosts many more sites than www.example.com. Rob's use of RSA keys with scp foils Mallory's plans to login directly on the hosting server.

However, all is not lost for Mallory. As the site is replicated regularly via cron, if the Web pages on the staging directory can be modified, these pages would be replicated on www.example.com. All that is left is for Mallory to find a way to modify the content on Acme Travel, Inc.'s proxy server.

The next script in the /admin/ directory, sitemgmt.php, helps Mallory do just that. Figure 9-10 shows the sitemgmt.php page.

Figure 9-10. The sitemgmt.php page

graphics/09fig10.gif

What does Mallory see here? A Web-based interface to manage the Web pages on the staging directory. Rob had created these pages so that Brooke, the receptionist and graphics artist, wouldn't need to learn how to use scp to copy pages from her workstation to the Linux server. Previously Rob had instructed Brooke on how to use FTP to copy Web pages to the Linux server, but after discovering vulnerability upon vulnerability with wu-ftpd, Rob decided to put an end to FTP once and for all.

Uploading the Defaced Pages

The site management interface was all that Mallory wanted! It couldn't get much easier than this, he thought. Pleased with tunneling his way through the proxy and brute forcing a user account with his own script, he set to work to exact his revenge. An hour later, he had two files ready index.html, which would replace Acme Travel's default Web page, and allyourbase.jpg, which came from his obsession with a particular phrase in an old arcade game that had turned into a phenomenon.

Figures 9-11 and 9-12 show screen shots of Mallory's uploading of the two files on 10.3.2.1.

Figure 9-11. Uploading defaced page index.html, using sitemgmt.php

graphics/09fig11.gif

Figure 9-12. Uploading defaced page allyourbase.jpg, using sitemgmt.php

graphics/09fig12.gif

Pleased with himself, Mallory decided to preview the newly uploaded Web pages on the staging area before deciding to call it a day. Once the cron daemon has executed replicate.sh, the Web pages would be copied to http://www.example.com/ and he would have his revenge.

Sure enough, at 4:00 A.M., the cron daemon kicked in and executed replicate.sh. Mallory's Web pages, along with the rest of the example.com Web site, were copied onto the Web site's hosting server. Figure 9-13 summarizes the entire attack.

Figure 9-13. Steps taken to deface www.example.com

graphics/09fig13.gif

Users who accessed http://www.example.com/ that day were greeted with the Web page shown in Figure 9-14.

Figure 9-14. Defacement of www.example.com

graphics/09fig14.gif

What followed was pandemonium at Acme Travel, Inc.'s office. Rob was busy trying to figure out how it all had happened. Fortunately Mallory hadn't been able to gain user-level or administrative access to the server he could have if he had uploaded some PHP or CGI scripts to give him shell access via the Web. The log files were still intact, and the attack was traced back to a small ISP in San Francisco. The least expensive fix was to replace the Web pages from a backup archive and lock down the proxy server thoroughly by modifying the Apache configuration and using Linux's iptables packet filtering rules to drop any incoming TCP traffic from an unestablished connection.

 



Web Hacking(c) Attacks and Defense
Web Hacking: Attacks and Defense
ISBN: 0201761769
EAN: 2147483647
Year: 2005
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net