- Introduction
- Building an Electronic Store
- Evolution of Electronic Storefronts
- Robbing Acme Fashions, Inc.
- Overhauling www.acme-fashions.com
- Postmortem and Further Countermeasures
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Overhauling www.acme-fashions.com
After the application security assessment team presented its findings, Acme's management decided to make radical changes in the company's e-business application, it hired a new team to look at the existing system and rewrite the code as necessary. The older commercial shopping cart system, ShopCart.exe, didn't allow product and pricing information to be stored in a database, so the team decided to develop its own shopping cart system. At the same time, it also decided to move the servers from Windows NT4.0 to the newly released Windows 2000 platform, running IIS 5.0 and ActivePerl. This time, the developers used a modified version of a shopping cart written in Perl, which was freely available on the Internet.
All client-side validation routines and improperly used hidden fields were removed. Care was taken to ensure that all the other mistakes made previously were not repeated. The new system went online August 1, 2001.
Facing a New Problem with the Overhauled System
On September 15 Acme's accounting department received a call from a credit card agency that was trying to trace the sources of credit card fraud. It so happened that most of the customers of the credit card agency who reported incidents of fraud had made purchases on Acme Fashions, Inc.'s Web site between August 1 and September 1. The credit card agency was convinced that the customer credit card information had somehow been stolen from Acme.
Acme's management already had faced and solved problems involving customers' tampering with prices during the preceding holiday season shopping. As if that weren't enough, now they had to deal with possible credit card theft. Management called in yet another top-notch computer forensics team to help evaluate the situation.
The team discovered that, in all the Web server logs for the month of August, there wasn't a single entry for August 29. This gap led the team to believe that a hacker must have wiped out the file C:\WINNT\System32\LogFiles\W3SVC1\ex20010829.log, which would have contained log data for that date. The file size had been reduced to 0 bytes, so the hacker must have had some way of getting administrative control of the server in order to wipe out the IIS Web server's logs.
Because there was no log data to go by, the team could only speculate on the possible cause of the attack. A thorough investigation of the system's hard drive showed that a file called “purchases.mdb” was present in two directories:
C:\>dir purchases.mdb /s
Volume in drive C is ACMEFASHION
Volume Serial Number is 48CD-A4A0
Directory of C:\ACMEDATA
08/29/2001 08:13p 2,624,136 purchases.mdb
1 File(s) 2,624,136 bytes
Directory of C:\Inetpub\wwwroot
08/29/2001 11:33p 2,624,136 purchases.mdb
1 File(s) 2,624,136 bytes
Total Files Listed:
2 File(s) 5,248,272 bytes
0 Dir(s) 111,312,896 bytes free
How did purchases.mdb end up getting copied from C:\ACMEDATA to the C:\Inetpub\wwwroot directory? The system administrator at Acme Fashions confirmed that purchases.mdb was used to hold customer order information, which included the customer's name, shipping address, billing address, items bought, and the credit card used to pay for the items. The application designers assured management that the database files lay outside the Web server's document root (C:\inetpub\wwwroot). The forensics team therefore concluded that, because a copy of purchases.mdb was created at 11:33 P.M. on August 29, 2001, fraud had occurred and it was the work of a hacker. The hacker must have copied the file from C:\ACMEDATA to C:\Inetpub\wwwroot and downloaded it with a browser by making a request to http://www.acme-fashions.com/purchases.mdb. Most likely, the hacker forgot to delete the copied file from the C:\Inetpub\wwwroot directory after downloading it.
Remote Command Execution
The fact that files were copied from one location to another and that the Web server logs were deleted suggested that the hacker had a means of executing commands on www.acme-fashions.com and had “super-user” or “administrator” privileges. After thoroughly evaluating the operating system security and lockdown procedures, the team concluded that the vulnerability was most likely an error in the Web application code. The problem was narrowed down to lack of proper input validation within the shopping cart code itself. Figure 10-16 shows how the shopping cart interacts with various elements of the Web application.
)
Figure 10-16. Components of the new www.acme-fashions.com
The shopping cart is driven by a central Perl script, mywebcart.cgi. All client-side sessions are tracked and managed by mywebcart.cgi. The shopping cart pulls product information from the products.mdb database and interfaces with a checkout station module that handles the customer payments, which are stored in purchases.mdb.
Figure 10-17 shows a page generated by mywebcart.cgi. Note the way that the URL is composed, especially keep in mind the ideas presented in Chapter 3 concerning poorly implemented shopping carts.
)
Figure 10-17. Page generated by mywebcart.cgi
The URL is:
http://www.acme-fashions.com/cgi-bin/mywebcart.cgi?cust=0873&nextpage=shirts3.html&cid=03417
The most interesting elements of this URL are the parameters passed to it, along with their values. Note that the parameter nextpage is passed a value of “shirts3.html.“ In the Perl code of mwebcart.cgi, the following line is responsible for the vulnerability:
$file = "c:\inetpub\wwwroot\catalog_templates\" . $input{'nextpage'} ;
open(FILE, $file) || die "Cannot open $file\n";
The fate of mywebcart.cgi is sealed. The parameter nextpage is passed to the Perl's open() function without any input validation. As discussed in Chapter 3, an attacker can insert the pipe symbol “|” at the end of the value assigned to nextpage and cause the open() function to execute arbitrary commands.
The following request would cause mywebcart.cgi to execute the “dir c:\” command on www.acme-fashions.com:
http://www.acme-fashions.com/cgi-bin/mywebcart.cgi?cust=0873&nextpage=;dir+c:\|&cid=03417
Figure 10-18 displays the results in the browser window.
)
Figure 10-18. Executing arbitrary commands with mywebcart.cgi
At this point, we can assume that the hacker must have performed a full directory listing, using the “dir c:\/s” command. From the results, he noticed the presence of the file purchases.mdb in the C:\ACMEDATA directory. Next, he copied it to c:\inetpub\wwwroot and then downloaded it, using http://www.acme-fashions.com/purchases.mdb. Figures 10-19 and 10-20 show how the file was copied and eventually downloaded.
)
Figure 10-19. Copying purchases.mdb to c:\inetpub\wwwroot
)
Figure 10-20. Downloading purchases.mdb
This demonstration by the forensics team exposed a serious security breach in mywebcart.cgi. Even today, many publicly and commercially available shopping carts are rife with such vulnerabilities.