The first step for Phoenix is to enumerate the Web site for PDXO Financial Bank. Contrary to what you might think, he does not start with pulling up the Web site. That is not going to help him with his first step of enumeration. Instead, he needs to discover the operating system and Web server version running on the site. One excellent means of accomplishing this is to examine the HyperText Transfer Protocol (HTTP) header. HTTP is a request/response standard between a client and a server. When you connect to a Web server with your browser, an HTTP request is sent. Every Web server returns HTTP response headers formatted according to Request for Comments 2616 (RFC 2616). Valuable information is found inside this response, such as the Web server version. Knowing the Web server version helps the hacker because it allows the hacker to know which exploits to try based on the Web server version. For example, after the hacker knows it is a Microsoft IIS server, the hacker can use the vulnerabilities associated with that server. It makes no sense to try an exploit designed to attack an Apache Web server when the target server is running Microsoft IIS (and vice versa).

Normally you never see what is sent in an HTTP response. Your browser merely receives the information from the Web server, interprets it as necessary, and displays the Web site in your browser. Phoenix needs to see this response so that he can know which Web server version is running. He begins by going to a command prompt on his computer. Next he connects to the Web server using Telnet. Instead of using the standard Telnet TCP port of 23, however, he connects to the Web server on the HTTP port of 80 by typing the following:

This command connects Phoenix directly to the Web server. Nothing will be returned however when this command is entered because Phoenix has not yet sent an HTTP request. To get the response Phoenix needs he sends an HTTP HEAD command to view the HTTP header. The HTTP header reveals information as to the type of Web server software used by PDXO Financial Bank. Phoenix types this command followed by two carriage returns (cr):

The response comes back as follows:

From this output Phoenix discovers that the bank is using Microsoft IIS v5.0 server. This helps Phoenix as he now knows that he needs to look for ways to exploit an IIS 5.0 server.

Phoenix thinks about what else he knows about PDXO Financial Bank. He remembers that it recently sent out a notice that it had just merged with a bank in Chicago. Bank mergers inevitably mean changes to a bank’s Web site. Often, companies make the mistake of leaving on the Web server development sites that might not be as secure as the production site. Phoenix begins to look for these development sites. He tries entering the following addresses in his browser:

This last one worked! It pulls up the page shown in Figure 1.1. The page is simple and is used by Web developers for testing code. Bank users should not be able to access this developer site, but chances are the developers were not careful in locking it down.

Figure 1.1 Developer Web site

The developer site has a form for logging in to the bank. Phoenix smiles because he knows that this form might just give him the access he needs to get the credit card information.

The next step for Phoenix is to enumerate the database used to store the account information. The login form will connect to the database that he needs information from. So, by using the username field, he can attempt to enter Structured Query Language (SQL) commands to discover the name of the database. This requires several weaknesses in the Web site to line up, so Phoenix is crossing his fingers that the developers left the vulnerabilities on the site. These weaknesses include

Because the Web site is running Microsoft IIS Server (discovered earlier in Web site enumeration), it is likely that the database is Microsoft SQL Server. The other weaknesses are probably present because the site is for developers only and therefore might not be as secure as a production site.

SQL injection is a technique of entering SQL commands directly into a SQL server from a Web site. Normally, this developer Web site should not allow any SQL commands to be entered in the form. Instead, only usernames and passwords should be allowed. However, unless code is entered to sanitize the input, a hacker could potentially send SQL commands directly to the database. This is dangerous because it allows hackers to grab all data from your database.

The first step Phoenix takes is to discover a list of databases on the server. On Microsoft SQL Server there is a default database called Master. Each database has several tables that consist of columns and rows that store data. Inside the Master database is a table called sysdatabases that lists all the databases on the server. The command to view a list of all databases is

Unfortunately for Phoenix, he cannot just enter the command and view the output. Instead, he needs to trick the server into allowing him to enter this command. Currently the Web site is expecting a username to be entered in the first form field. Phoenix needs to enter a new command that the server is not expecting. In SQL, a semicolon is used to end a command. Phoenix will trick the server into thinking a previous command is over and a new command is about to be entered by preceding his SQL command with a semicolon:

To ensure that no other commands are entered after his SQL command, Phoenix needs to comment out the rest of any remaining SQL code programmed on the Web site. By commenting out the remaining code following his SQL command, it will trick the SQL server into thinking that any code following his command is strictly comments written by a SQL developer and not actual code to be executed. To comment out any code following Phoenix’s SQL command he follows his command with two dashes as follows:

Although this command would work it will not generate any output on the screen. Phoenix will need to send output to another file on the Web site that he can retrieve. One method of sending this data to a file is to use the command-line utility OSQL. OSQL is included with Microsoft SQL Server and allows you to enter SQL commands from an MS-DOS command prompt. By entering commands from a command prompt you can then pipe, or send, the output to a text file. The OSQL command-line options are shown here:

The parameters Phoenix will use and their explanations are shown in Table 1.1.

Phoenix will attempt to send his output of his command to a new text file on the server. The default location of a Web site on Microsoft IIS 5.0 Server is c:inetpubwwwroot. Phoenix will send the output of his command to a new file that he will store in this directory so that he can view it in his Web browser. His complete OSQL command is

Phoenix is not done yet though. OSQL is a command-line utility and therefore needs to be entered from an MS-DOS command prompt. However, Phoenix is not on a command prompt on the server. Instead, he is accessing a Web form on a developer Web site. Luckily for him, Microsoft includes stored procedures, which are a precompiled set of SQL statements. One such stored procedure is xp_cmdshell, which allows you to enter a command from a command prompt from within SQL. To execute this stored procedure, Phoenix would type

Putting the command all together, Phoenix types the complete command as follows in the username field:

There are a lot of components in this command. Figure 1.2 summarizes the process Phoenix is taking to enumerate the database. Phoenix accesses the developer Web site, which allows him to enter SQL commands. He enters the xp_cmdshell stored procedure, which allows him to use the OSQL command-line utility. He uses OSQL so that he can enter a SQL command and send the output to a text file. The output is sent to a text file accessible from his Web browser.

Figure 1.2 Logic summary of enumerating SQL databases

Phoenix clicks the Login button. A few seconds later a Web page is returned saying The page cannot be displayed. Phoenix doesn’t worry, though, because he knows that his command was executed successfully. The Web site returns this page because it was expecting a username and password and not the SQL command Phoenix entered. Phoenix changes the URL to http://www.pbxofinancial.com/output.txt to view the output of his SQL command. Here is a partial output:

Phoenix found what he was looking for. There is a database called creditcards. In fact, the output even tells Phoenix that the path to the database file is C:Program FilesMicrosoft SQL ServerMSSQLdatacreditcards.MDF.

Phoenix now needs to determine the list of table names within this credit card database. The command to enumerate the table names is

Phoenix returns to the login page and enters the complete command to enumerate the tables and output the results to a text file:

After clicking Login, Phoenix waits a few seconds for the command to complete. As before, nothing will be shown on his screen but a Page Not Found message, but he knows that the output is sent to tables.txt. He pulls up the page www.PDXOfinancial.com/tables.txt in his Web browser. A few pages of output fill his screen. He scrolls through it looking for anything that might contain the actual credit card numbers. Eventually he comes across the following output:

His eyes fall on the table named cardnumbers. This is his jackpot. What he needs to do now is extract the credit card values from this table.

Each row in a table is one credit card account. Therefore the first step to stealing the credit card information is to select all the rows in the credit card table. To select all rows, his command would be

Returning to the login page, he enters the following command to send the information stored in the cardnumbers table to a file called cards.txt:

Phoenix lets out a slight smile as he prepares to view his results. He navigates in his Web browser to www.PDXOfinancial.com/cards.txt. What he finds is astonishing; the output contains not only the numbers, but also the names of the account holders, the expiration dates, and the credit card verification (CCV) codes on the back of the cards! Here is a partial output that appears on his screen:

Phoenix saves this file on his local hard drive.

With the credit card numbers in his possession, Phoenix now can start looking for a prospective buyer for these account numbers. He launches NewsRover, a common newsgroup-viewing application, and logs in to the alt.2600 newsgroup. This newsgroup is for readers for 2600 magazine (http://www.2600.com), a popular magazine that discusses telephony hacking (called phreaking) and computer hacking. Phoenix is going to post a message about his cards here because he knows it will reach the highest number of people who might be looking for this kind of information.

Phoenix is concerned, however, that with the newsgroup being public it may catch the eye of law enforcement. He certainly cannot use his real e-mail address, so he quickly sets up an anonymous Gmail account called [email protected]. He knows he cannot simply offer to sell credit cards because law enforcement would quickly spot that. Instead, he visits the site www.spammimic.com. This is a site that will disguise a message into what looks like a spam advertisement but in reality contains your message. Figure 1.3 shows the Spammimic Web site. It gives you the additional options of encoding the message with a password, encoding as a fake PGP message, or encoding as fake Russian text.

Figure 1.3 Spammimic

After clicking the Encode button, he is shown the output in Figure 1.4. Although it looks like a typical spam advertisement, those familiar with this site will know to take the message and decode it on Spammimic’s Web site.

Figure 1.4 Encoded message

Phoenix copies the encoded message and posts it in the alt.2600 newsgroup.

Now Phoenix sits back and waits for someone to view his posting and respond. He isn’t worried that it looks like spam because he knows that people who browse these types of newsgroups know to copy the spam message into Spammimic’s Web site. As soon as someone copies the text into the Spammimic Web site and clicks the Decode button he will see this message:

The next day, Phoenix checks his e-mail account and discovers four e-mail messages from people who want to purchase his stolen credit card numbers. He responds back to the first one and arranges payment to an offshore bank account in Switzerland. Within a few hours the money is transferred and Phoenix has $12,000. That $12,000 is enough to pay off his bill, so he writes PDXO Financial Bank a check for $12,000. He also realizes that he just gave his credit card number away to a stranger so he immediately cancels his card.

Although Phoenix could have made off with a lot more money by using the stolen credit cards, it is much easier to track down the person using the stolen credit cards than it is the one who sold the cards in the first place.

Now that Phoenix has sold the credit card information, he wants to deface the bank’s Web site to teach the bank a lesson. His goal in defacing the Web site is to send a message to the bank that it should not raise interest rates because there will be consequences. Defacing a Web site is a common attack used by malicious hackers when they want to get a message across. Often it is a form of hacktivism, where malicious hackers want to deface a site for political or religious reasons. But in this case Phoenix is doing it to protest the recent rise in the credit card interest rate.

Phoenix returns to the bank’s Web site. At this point he already knows the following about the site:

In the previous attack Phoenix used the xp_cmdshell stored procedure to copy the credit cards to a text file. Now, Phoenix will attempt to use the same stored procedure to overwrite the default home page on the site. By default the home page is installed on Microsoft IIS 5.0 in the c:inetpubwwwroot directory and is called default.asp. It is good practice to change the default home page to a different directory because leaving it in the default location makes it easier for malicious hackers to deface the site. Considering the other weaknesses in the site, including installing Microsoft SQL Server on the same computer as IIS 5.0, keeping the credit card database on the C partition instead of a separate partition, and using the default install path of c:inetpubwwwroot, Phoenix knows that defacing the site will be easy. All it takes is a single command in the username prompt on the Web site.

On the Web site Phoenix types the following command in the username box.

This command overwrites the default.asp page with a new page that says “You’ve-been-hacked!” Phoenix cannot believe how easy this is.

The following are the steps Phoenix took in this chained exploit:

Earlier in the chapter Phoenix was able to determine that the target Web site was running Microsoft IIS. This helped him to make an educated guess that the database server was running Microsoft SQL Server (it is common in Microsoft-based environments to use IIS with SQL Server). Phoenix grabbed this information by sending an HTTP HEAD request to the Web server and reading its response. You can change this response on your Web server so that incorrect information is given back to potential hackers to confuse them. You can use URLScan, which allows you to remove the default Server HTTP header and substitute a custom entry. URLScan is a Microsoft utility that you can download from Microsoft’s Web site. To view more information on this useful utility, visit http://support.microsoft.com/support/kb/articles/q307/6/08.asp.

In this chapter Phoenix was able to hack into the bank using the developer site. It is common for developers to set up staging sites for testing before updating the code on a production site. The danger lies in the possibility that a developer site might not implement the same level of effective security controls to protect against attacks. You should never allow public access to any developer staging sites. All development sites should be on a separate network internal to an organization. Furthermore, the development site should not be attached to the corporate network to prevent against insider attacks. Ideally, you should have a separate network for development/staging work, one for quality testing prior to production, and a third for your production site.

Phoenix was able to execute the commands in this attack because the SQL Server installation was on the same computer as the IIS Web server. SQL Server should be installed on a separate computer to make it more difficult for attackers to enter SQL commands through a Web site.

Phoenix entered SQL commands directly through a Web form. This is very dangerous. A Web form should be programmed to allow only a certain number and type of characters. For example, it would have made Phoenix’s attack much more difficult if the form field still allowed only up to eight characters and those eight characters could be only letters or numbers. There are ways for Phoenix to get around this limitation, but this countermeasure would make it more difficult for him.

This example had IIS installed in the default location of c:inetpubwwwroot. This is dangerous because it is too predictable for hackers to deface Web pages and create new pages because they know the path to the Web site. Never install IIS in this location. Also, install it on a partition separate from the C partition. This prevents hackers from some directory traversal attacks (not discussed in this chapter).

If possible, make your Web site read-only. Phoenix was able to send the output of his SQL commands to new files that he created. By making the directories of your Web site read-only, Phoenix would not have been able to create new files.

Phoenix used the xp_cmdshell stored procedure to execute his attack. If you do not need the default Microsoft stored procedures, remove them from your database. This is a minor countermeasure, however, because there are commands you can enter to re-create the default stored procedure. It is also unrealistic in many environments that have come to depend on Microsoft stored procedures for managing their database. Nevertheless, it is an option to consider.

Phoenix was able to hack the database because it used the default username of SA with the default blank password. In later versions of SQL Server this is removed, and you are forced to enter a username and password. But earlier versions defaulted to SA with no password. When you install SQL Server, make sure that you always use a secure password.

In addition to these countermeasures for companies, there are also some considerations for the customers. None of these would prevent the attack performed in this chapter, but they are useful tips to help you be a smart consumer.