What is a database and how does it differ from a database management system? A database is a structured collection of related information that is organized in a manner that is easily accessed, managed, and updated. A database management system is a computer program used to access, manage, and update the information within a database. From this point forward, we will use the terms database and databases interchangeably to refer to both the database and the database management system.

Database management systems are categorized according to the data model used to organize their internal structure. Of the various data models, the relational data model is the most common, and it will be the focus of this chapter.

The relational data model represents information as a collection of tables. You can think of a table as a large spreadsheet with rows and columns. The intersections of the rows and columns are called fields. The fields are specific bits of data about a specific subject.

A customer contact information table may look like Table 5.1.

In Table 5.1, the fields are CustomerID, LastName, FirstName, StreetAddr, City, State, and ZipCode. Each field stores specific data about the customer, identified by the CustomerID field. Each table has a field, or fields, that uniquely identify the records and enable those records to be referenced throughout the database, maintaining database integrity and establishing a relationship with other tables within the database. This field is called the primary key, and in this case, the CustomerID is the primary key. You can use it to relate customer information to other tables that contain customer orders or payment history or any other information about the customer.

You can access and manipulate information within a database through the use of a query. A query is a structured question you ask of the database management system. Using Table 5.1 as an example, if you want to see the information contained in the database about Scott Bilyeu, his orders, and his account standing, you would construct a query to gather the records from each table containing the desired data. You can use this data to produce a physical report, or you can save it as a view, which is a virtual table that contains no data, but knows from where to retrieve the data once it is requested.

Queries are constructed in Structured Query Language (SQL), which is a command language that relational database management systems (RDBMSs) use to retrieve, manage, and process data. The most basic command within the SQL language is probably the SELECT statement, which is used to retrieve information from the database. Study outside this book will be required if you want to learn how to write complex SQL statements. One starting point is the free tutorial provided at http://sqlcourse.com.

Let there be no doubt, the science of databases delves much deeper than we'll touch upon here, but for our purposes, this introduction to database storage components should suffice.

Understanding what happens when database software is installed is important in understanding how to approach testing that database. Installing a database is similar to installing any other software. The needs of the database are unique, and often the database software is the only application installed on the server or workstation. The creation of the actual database requires special considerations. Although installation instructions are beyond the scope of this chapter, we are going to cover some of the installation results that are important to the penetration tester.

Both Oracle and SQL Server have functions to create a database through a wizard, using scripts, or manually, once the initial software is installed. When the database is created, default users, roles, and permissions are created. The database administrator (DBA) has the opportunity to secure many of these default users at the time of creation. Others must be secured after the database has been created. Additionally, default roles and privileges must be secured after the database is installed.

When Oracle and SQL Server databases are created, default users and roles are created. Some of these users are administratively necessary for the function of the database, and others are used for training. Default users are one of the most common weaknesses in insecure databases as they are often forgotten or are secured with default or weak passwords.

Much like users in a domain, users of a database can be assigned permissions and those permissions can be grouped for ease of administration. In the database world, Microsoft uses the term permissions where Oracle refers to actions that can be performed as privileges. While Microsoft and Oracle define privileges and roles a little differently, for the most part a privilege is the ability to perform a specific task (insert, update, delete) on objects that are assigned to individual users, and roles are privileges that can be grouped together and assigned to users or groups. The SQL standard defines grouped permissions as roles and both Microsoft and Oracle follow that standard. We will not cover all of the roles and privileges in this chapter, only the ones important to understanding the databases.

It should be noted that security is harder to retrofit into a database system than most other systems. If the database is in production, the fix or security implementation may cause the application to no longer function properly. It is important to ensure that security requirements are built into the system at the same time as the functional requirements.

Additionally, enterprises that rely on the DBA to build a secure application are doing themselves a disservice. People are often the weakest link in computer security. If a developer or administrator simply builds a database from a default configuration without any guidance from security requirements, the database may be built in such a way that implementing security fixes may impair functionality. Then the enterprise will have to make a business decision to rebuild the database to meet the security requirements or accept the risk.

It is always a good idea to create a standard configuration guide for the creation of all databases that addresses security and functionality. With a secure baseline configuration of the database, it is easier to ensure that security is built into the database and will help when additional security requirements must be added to upgrades or fixes.

After the database is installed, users must be able to connect to the application to use it. Default Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports are associated with each database application. You can change the ports to any available port, but we are going to concentrate on the defaults. In the Case studies section later in this chapter, we will cover some ways to find databases on servers using user-defined ports.

By default, Microsoft SQL Server uses TCP port 1433 for connections to the database. As mentioned previously, this port can be changed, but usually it is not. Most penetration testers can tell you what the default TCP port is for SQL Server, but many do not know that a UDP port is also associated with the database. UDP port 1434 is the SQL Server listener service that lets clients browse the associated database instances installed on the server. This port has become the target for many worms and exploits because of buffer overflows associated with the service behind it. Microsoft has issued a patch to fix the problem, but you can still find this vulnerability in the wild.

Oracle, like SQL Server, can host multiple databases on a server. By default, Oracle uses TCP port 1521 for its listener service, although it can be user-defined as well. Additionally, Oracle uniquely identifies each database instance through a System Identifier (SID). To connect to and use an Oracle database instance, you must know the SID and the port number associated with that instance. This is not necessarily the case for an attacker or penetration tester. We will discuss discovering the SIDs on a database server later in this chapter in the Open source tools section for Oracle databases.

As we said earlier, databases are usually the only application running on a server. This is because they use a lot of the system resources. Although it is possible to install a database server and meet the minimum system requirements set by the vendor, doing so is not realistic. In fact, when considering real-world deployments of databases, the hardware requirements are often as much as four times the minimum system requirements. Again, the database requires most, if not all, of the system resources to operate and provide information.

Surely system requirements are beyond the scope of the assessment, right? Sometimes they are, but security implications concerning certain system requirements do exist. Just like most applications, databases have the capability to audit actions performed on the database to a central log. These audit log files can grow quickly and can also use up system resources—mostly hard-drive space. For a database with static information, this is not much of an issue because any leftover disk space can be used for auditing. But if the database is composed of dynamic data that grows over time, auditing can become a problem. It is not uncommon, therefore, to see databases in the real world that do not have auditing enabled. Oftentimes, system administrators assume that audit logging on the server operating system will be enough to cover both the server and the database. This is incorrect. In fact, it is entirely possible to connect to and exploit the database without triggering any server audit logs. This can become important if you are on a “red team” or an unannounced penetration test and you need to avoid detection.

By default, SQL Server creates the “sa” account, the system administrator of the SQL Server instance and database owner (DBO) of all the databases on the SQL Server. The “sa” account is a login account that is mapped to the “sysadmin” role for the SQL Server system. This account, by default, is granted all privileges and permissions on the database, and it can often execute commands as SYSTEM on the server depending on the server-side account setup.

You can configure SQL Server user authentication to use Windows credentials only, or in combination with named SQL Server login IDs and passwords, which is known as mixed mode authentication. Once a user is created, the user can authenticate to the database and begin to operate within the bounds of his permissions and roles.

Windows mode authentication can allow for ease of use for the user because he has to remember only one password, but this can also create a potential vulnerability. If the user's Windows credentials are compromised and the database uses the Windows credentials for access to the database, an attacker has access to the database using the compromised account. Remember, all information that you discover from the network may be of use when assessing the database. This can also go the other way—any information you may gather from the database may be of use against the network.

Microsoft has simplified the administration of permissions by creating roles. SQL Server has several roles that are created at the time of installation. They are divided into two groups. Fixed server roles are those roles that have permissions associated with the server itself, and fixed database roles are those roles that are associated with permissions for the database. These roles are called fixed because they cannot be changed or removed. There are also user-defined roles that are exactly that—custom-defined roles created specifically for the database.

We will now re-examine the “sa” account. As we mentioned, the “sa” account is the DBO for all databases created on the server and is mapped to the system administrator account. Therefore, the “sa” user has administrative privileges over the database and host operating system. Any user created by the DBA and granted the DBO (db_owner) role would also have similar privileges.

When creating an SQL Server account, the only role that would be granted by default would be public. The public role comprises permissions that all users of the database are granted. The user is able to perform some basic activities within the database (limited to SELECT) and has limited execute permissions on stored procedures, which we will discuss in the following section.

One important difference between SQL Server and Oracle is the use of pre-coded stored procedures and extended stored procedures in SQL Server. Stored procedures are pieces of code written in Transact-SQL (T-SQL) that are compiled upon use. An example of a useful stored procedure is sp_addlogin, which is the stored procedure used to create a new user. Some others are listed in Table 5.2.

Extended stored procedures are similar to stored procedures except they contain dynamic link libraries (DLLs). Extended stored procedures run in the SQL Server process space and are meant to extend the functionality of the database to the server. One extended stored procedure useful to the penetration tester is xp_cmdshell, which allows the user to execute commands in a shell on the Windows operating system. As you can see, stored procedures in SQL Server can greatly improve database capabilities. However, they can also create significant vulnerabilities. We'll discuss exploitation of stored procedures in the Open source tools section for SQL Server later in this chapter.

As always, there are a number of open source tools which can help us in penetration testing MS SQL Server databases. Before examining those tools, let's go over some basic assumptions. Using the information from Chapter 2 and Chapter 3, you should already have pinpointed some potential targets for these tests. By utilizing the tools discussed in those chapters, you should have information regarding the IP of the target, which ports are open, and which versions of software are installed. This is the groundwork necessary before any penetration testing of the database itself can be performed.

Let's start with the Metasploit Framework again as it contains a number of tools which can help us in learning more and gaining access to a vulnerable SQL Server. The first step is to identify which tools are available within the framework. Open the Metasploit console with the command ./msfconsole and search for appropriate tools using the command search mssql. This should show you a result similar to Fig. 5.1.

Several default user accounts are created during Oracle database management system installation. At least 14 default users are created in version 10g, but that number can exceed 100 if you install an older version of Oracle. This is important for at least two reasons. First, these are well-known accounts with well-known passwords. Second, some of these accounts may not be DBA-equivalent, but they may have roles associated with them that may allow privilege escalation. Some of these accounts are associated with training, such as SCOTT, whereas others are associated with specific databases, such as SYS, SYSTEM, OUTLN, and DBSNMP. Since Oracle 9i, most of the default accounts are created as expired and locked accounts that require the DBA to enable them. However, the SYS and SYSTEM accounts are unlocked and are enabled by default. If the database is created using the Database Creation Wizard, the DBA is required to change the default password of SYS during installation.

Similar to the creation of a user in SQL Server, the new user in Oracle must be assigned roles. The default role assigned to every new user of a database instance is CONNECT, unless this is changed when the database instance is created. In most cases, the DBA will assign additional roles to an account after its creation to tailor the permissions available to the user.

Just like SQL Server, Oracle uses roles for ease of administration. Unlike SQL Server, the default roles in Oracle are more granular, allowing for a more secure implementation. The default roles of CONNECT and RESOURCE are examples of roles that administrators can misunderstand and that penetration testers can take advantage of.

The CONNECT role, which has an innocuous enough name, leads one to believe it is necessary for a user to connect to a database instance (in fact, the necessary role is CREATE SESSION). This role, which you can use when creating database objects, provides multiple privileges that normal users should not have. One example of this is the ability to invoke the CREATE DATABASE LINK statement. This statement will create a database link, which is a schema object in one database that enables you to access objects on another database, with the caveat that the other database needs not be an Oracle database system.

RESOURCE is a role that you also can use to create database objects, but it also has a hidden role that allows a user to have unlimited table space. This could allow the user to use all database resources and override any quotas that have been set.

The default role that gets everyone's attention is DBA. The account with the DBA role assigned to it has unlimited privileges to that database instance. If a default account, such as SYSTEM (default password manager), is left in the default configuration, a malicious attacker can connect to the database instance using this account and have complete DBA privileges over that instance. This brings back the importance of the standard configuration guide to address default users and default privileges. Changes to some default accounts such as CTXSYS, OUTLN, or MDSYS after a database is in production can impair database operations.

Stored procedures are handled differently in Oracle. Oracle stored procedures are written in PL/SQL, but they serve the same function as stored procedures in SQL Server. However, because Oracle can be installed on many different operating systems, you can modify the stored procedures to suit the host operating system if necessary. By default, Oracle stored procedures are executed with the privilege of the user who defined the procedure. In other words, if a standard user account created a stored procedure and he has the privileges defined in the DBA role, any user who executed that procedure would execute it with those rights, which may be more permissive than intended.

Plenty of open source tools exist to help us in penetration testing of Oracle databases as well. Again, it is assumed that the information from Chapter 2 and Chapter 3 has already been used to pinpoint some potential targets for these tests. By utilizing the tools discussed in those chapters, you should have information regarding the IP of the target, which ports are open, and which versions of software are installed. With this work already performed, we can move forward to penetration testing of the Oracle databases that we've discovered.

As mentioned previously in the Communications section, you need a few different pieces of information in order to successfully connect to an Oracle database:

Based on our scanning and enumeration, we should already have the first two elements but we still need to get the rest. In order for the username and password to work, we have to first have the SID, so we'll start with trying to get that information.