SQL Injection Attack, Listing the Database Contents on Oracle

Lab Description:

This lab contains a SQL injection vulnerability in the product category filter. The results from the query are returned in the application’s response so you can use a UNION attack to retrieve data from other tables.

The application has a login function, and the database contains a table that holds usernames and passwords. You need to determine the name of this table and the columns it contains, then retrieve the contents of the table to obtain the username and password of all users.

To solve the lab, log in as the administrator user.

This lab is very similar to the previous lab, “SQL Injection Attack, Listing the Database Contents on Non-Oracle Databases”. The only difference being is that we will be working with an Oracle database.

If you followed the previous lab walk-through, you may feel comfortable trying this one on your own using the provided cheat sheet.

If not, then follow along here!

First, let’s create a list of what we need to accomplish in order to solve this lab.

With Burp running, access the lab. The SQLi will be in the product category filter. Click on the filter of your choice.

You should then be able to find your filter in the Burp target site map. Right-click on your filter and select ‘Send to Repeater’.

Click on the ‘Repeater’ tab and you will see your request on the left. Clicking send, you can see the original request’s ‘200 OK’ response on the right.

#1 — Verify SQLi vulnerability injection point.

On the left, in your request, replace your filter with a single quote (‘) and click ‘Send’.

A ‘500 Internal Service Error’ response tells us this site may be susceptible to a SQLi attack!

#2 — Determine the exact number of columns AND data types.

In order to use a ‘UNION SELECT’ attack the number of columns AND the data types must match exactly.

One way to find out the number of columns is to use the ‘ORDER BY’ clause. Append ‘ORDER BY 1 — — ‘ to your request. This will tell the server to order the results by the first column. If the is one.

Using the cheat sheet, in the ‘Comments’ section, we can see using the double hyphen at the end will comment out the rest of the line.

Now that we have our ‘ORDER BY’ clause, replace the single quote in your request with the payload.

Before clicking send make sure to URL encode your payload. Burp makes it easy. Just highlight your payload and click ‘Ctrl+u’.

Click ‘Send’. You should see a ‘200 OK’ response. This lets us know that this database has at least one column.

Let’s check for two columns now. Change the ‘1’ to ‘2’ and click ‘Send’. You should get another ‘200 OK’ response letting us know that, yes, there are two columns.

We do indeed have two columns.

Let’s try to sort by three columns. Replace the ‘2’ in your payload with ‘3’ and click ‘Send’.

Getting the ‘500 Internal Server Error’ is telling us that there is NOT a third column to sort by.

We now know how many columns we have. What about the data types of the columns?

Looking at the website we can figure out that the two columns should be the product and the product’s description. Both will be text data types.

We can verify this by injecting text strings onto the page itself by using a ‘UNION SELECT’ statement.

First, recall what the ‘Hint’ portion of this lab tells us:

In their example they use the string ‘abc’. This will be fine if the table contained only one column, but we need to modify it for our use since we know we have two.

We will need to add another sting following a comma to get this payload to work.

Enter our URL encoded payload into your request and click ‘Send’.

#3 — Verify that the site is, in fact, using an Oracle database.

Technically, this step is not needed to solve this lab since we are already told what type of database we are dealing with. Also the use of ‘dual’ in the previous payload. However, it is good to know how it is done.

Refer back to the provided cheat sheet. Scroll down to find the section “Database version”. Here we can find the query we need to extract this information.

This query will have to be modified to fit our needs as well. Since we know we have two columns in the database we are trying to access, ‘banner’ is one column, we will have to add another column to our payload before sending the request.

Send your URL encoded payload request and you should receive a ‘200 OK’ response from the server.

#4 — Determine the relevant table name within that database.

Looking at our cheat sheet again, under the ‘Database contents’ section, they give us the syntax needed to find the available tables.

In Oracle, ALL_TABLES is a data dictionary view that provides information about all the tables that a user has access to in the database. Some of the key columns contained in ALL_TABLES include:

We are, of course, interested in TABLE_NAME. A complete list of all the columns contained in ALL_TABLES can be found here.

The cheat sheet tells us we can use ‘SELECT * FROM all_tables’. However, we can not use ‘*’ in our UNION SELECT. The ‘*’ indicates we want ALL the columns in the table, but we only have two columns to join in our UNION.

We will need to modify this query. Our two columns will be ‘table_name’ and ‘NULL’.

Send your URL encoded payload in Burp repeater and you should receive a list of all the tables in the database in the ‘200 OK’ response.

Use the search function in Burp to easily find the table starting with ‘users’.

Now we know the table name we were looking for. Next up, finding the relevant columns that contain the user name and password for the administrator.

#5 — Determine the relevant column names within the table.

Back to the cheat sheet. Oracle has another data dictionary view, like ALL_TABLES, called ALL_TAB_COLUMNS.

ALL_TAB_COLUMNS provides information about all columns in tables and views accessible to the current user.

Key columns included in ALL_TAB_COLUMNS are:

You can find the complete list here.

Like the last query, we need to modify the request to meet our needs.

Add your URL encoded payload to your request and click ‘Send’.

#6 — Find credentials for ‘administrator’.

Our final simple query will give us the usernames and passwords for all users. We are only interested in the administrator’s password to solve the lab.

Send your URL encoded payload in Burp repeater and your ‘200 OK’ response should reveal all the usernames and passwords. Find ‘administrator’ and it’s corresponding password and head back over to the lab site.

Click on the ‘My account’ link in the upper right hand corner and you will be brought to the login page.

#7 — Log in to the site as ‘administrator’.

Use the found credentials for the administrator to log into the site.

Once you have logged in, you have solve the lab!

Congratulations! You solved another one! Keep up the hard work!

See you next time!