Introduction

Introduction

Databases (and SQL in specific) have long been an integral part of doing business. Whether it was the first flat file database or today's advanced object-oriented databases, the need for storing and accessing information rapidly is crucial to any business or application and the Web is no different.

Current Web applications are tightly coupled with the database. They are used for everything from storing usernames and passwords for authenticated access, to storing a users' mailing address and credit card information for product shipment and payment. As a result, a thorough understanding of Web security must include the database layer and, more important, how attackers attempt to bypass an application's constraints on the data to gain access to parts of it.

In this chapter we discuss the interaction between the Web server and the database. We highlight the weaknesses in application design that allow an attacker to disclose sensitive information, or worse, allow remote command execution.

Direct SQL Attacks

Although it isn't the primary thrust of this chapter, we need to note that Microsoft SQL Server and Oracle both can be accessed via network by default. In other words, if your firewall isn't configured correctly, you may be allowing attackers to brute force your database connection without ever going through a Web application.

Although this opportunity rarely presents itself outside an internal network, it is the ideal form of database hacking: in the raw. To perform some basic remote hacking of a database in this manner, follow a few simple steps. Find a system with any port open, such as TCP and UDP 1434 (Microsoft SQL Server) or TCP 1521 (Oracle). You can do so by using any of myriad port scanning tools, including Fscan from Foundstone (http://www.foundstone.com). In addition, you can use a tool such as SQLPing2 from Chip Andrews (http://www.sqlsecurity.com) to search for Microsoft SQL Servers within a range of IP addresses. As Figure 11-1 shows, when we applied SQLPing2, it discovered two SQL servers: 192.168.0.8 and 192.168.0.9.

Figure 11-1. Results of applying SQLPing2 to scan ports for servers

Once you know the server on the network, you can attempt to gain access to it. You can do so in a number of ways, but one of the simplest is to use osql.exe, which comes with any SQL Server 2000 or Desktop Engine (MSDE). The syntax looks something like this:

C:\> osql -S 192.168.0.8 -U sa -P ""

Login failed for user "sa."

By using osql parameters S (server), U (username), and P (password), you can try to brute force your way into the database servers. As you can see, the prior attempt using "sa" with no password (the most common of passwords, we assure you!) was wrong and resulted in an error. However, if you attempt a correct username/password combination with osql, you'll get a 1> prompt, meaning that you can type any database command:

C:\> osql -S 192.168.0.8 -U sa -P password

1> select count(*) from syscolumns

2> go

  -

4683

(1 row affected)

1>

With an authenticated user on the database, you can now try a few techniques to learn more about the databases and their table structures. The first step in taking on a Microsoft SQL Server is to run the sp_helpdb stored procedure (assuming that the network administrator hasn't removed it in an attempt to secure the database). It will show you all the existing databases and their names, sizes, owners, and database IDs (dbid):

C:\> osql -S 192.168.0.8 -U sa -P password  Q "use master; exec sp_helpdb"

Next, you can enumerate all the objects in the particular database with the sp_help stored procedure. It will detail each object in the database, including each view, user table, table function, system table, stored procedure, scalar function, inline function, and extended stored procedure:

C:\> osql -S 192.168.0.8 -U sa -P password  Q "use master; exec sp_help"

You can identify all the tables within a particular database with the information_shema function:

C:\> osql -S 192.168.0.8 -U sa -P password  Q "use master; select * from

information_schema.tables"

Or, you can use the best of all extended stored procedures to execute anything on the remote system. For example, we simply output a directory listing to a file in the C:\directory, "owned.txt" to obtain:

C:\> osql -S 192.168.0.8 -U sa -P blah -Q "exec

master..xp_ cmdshell'dir> c:\owned.txt'"

You can choose from among many other SQL statements and functions to enumerate and eventually own the database server. Review Chapter 2 for more details.

You may consider what we just showed you about direct SQL attacks to be cheating. Well, it is. But it also is reality. Demonstrating and practicing these techniques can help you understand what we're going to show you next: SQL exposure via a Web application.