Structured Query Language Injection (SQLi), Part 2: Particulars of the attack.

As noted in part 1, hackers extend the already structured SQL statement by injecting more legal syntax into the user input field of the interface. The simple example demonstrated the concept of SQLi but did little more than prove that the chosen interface was subject to exploitation. Also, we did not specifically uncover what the table and field names were, we just know that they existed and we could reach them. Now, using the same example, we take a closer look to see what more we can discover about the exposed application.

Most attackers are after something specific or they're just hunting for anything of value. Sometimes this means firing in the dark to see if they can hit anything. Part 1 was the shot in the dark with a hit, now we explore the target further by enhancing the complexity of our injections. Consider the following:

x' AND date_of_birth IS NULL;--

We use 'x' as a filler for data within the field, simply because at this point we're not too interested in trying to get a legitimate value or values in return, we're just trying to map the database. This is also why why we suggest a NULL value for 'date_of_birth', it doesn't really matter. The double hyphens at the end are syntax for SQL comments, this is sometimes added to eliminate effort in matching quotesat the end since they become commented out. This would make the full executed statement something like this:

SELECT unknown FROM unknown WHERE unknown = 'x' AND date_of_birth IS NULL;--';

First, it's important to note that we are arbitrarily targeting a column called 'date_of_birth'. We have no idea if there is a column called 'date_of_birth', but due to the form indicating that a last name is required we do know that there is a column with a person's last name. We can conjecture that the database may have other information about users, so at this point we make some guesses as to what they might be called. In this example we chose 'date_of_birth'. If there is a column titled 'date_of_birth' the database will respond with a 'no data found', 'date_of_birth not found for user', or similar error. Any other type of error would probably indicate that our SQL syntax was malformed, which could be due to the usage of a column that does not exists in the database.

If we were to inject a few statements in the this manner, changing 'date_of_birth' with whatever other column names we'd like to try (probably starting with more common columns like email, password, userid, name, etc.), and if we watch our return messages carefully we may end up capturing one or more legitimate column names within the database being attacked. With this information we begin to form the database schema, or the names of the database and subsequent columns or fields, which will serve as a road-map for attack using further and more intense injections.

Resources:
http://blog.imperva.com/2011/09/sql-injection-by-the-numbers.html

http://www.unixwiz.net/techtips/sql-injection.html

http://en.wikipedia.org/wiki/SQL_injection