Monday, March 18, 2013

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.



Posted by at No comments:

Wednesday, March 13, 2013

Structured Query Language Injection (SQLi): A look at one of the oldest and most efficient attack vectors for hackers

Only the foolish believe that this form of attack is obsolete. The truth is that SQL Injection was rated as one of the top ten attack methods used on applications in 2007 and again as recent as 2010. Applications in production are subject to as many as 71 SQLi attacks per hour, with high value applications being attacked 800-1300 times per hour. So what's at risk? How does SQLi work? And how do I defend my application against SQLi? Let's find out.

Some of the most powerful applications use a database to store their data. On the back-end data is accessed via SQL statements that are either fixed or are customized based on user input. The goal of attackers is to make the application run an SQL query that was not intended by the application programmers, with the result being attackers gaining access to information they should not be authorized to have, or they can manipulate data or even control an entire database.

The user interface to input the data should be considered the gateway by which the injection occurs. SQL statements are often structured similar to this:

SELECT thiscolumn FROM thistable WHERE data = '$value';

If the database table we are accessing is called 'member_information', and the column in the table we are trying to capture data from is 'birth_date', and the column we are verifying user input against is 'last_name', then since the “$value” is the variable container representing input from the user if the user submits the value “Smith” into the user interface the application handler would execute the following SQL statement:

SELECT birth_date FROM member_information WHERE data = 'Smith';

Although simplified, this is a very common approach to verifying data in a database. This particular statement would probably return the targeted members recorded birth date. Unfortunately, this approach can be subject to manipulation by using SQLi to return other-than expected results to the application user. Continuing with our last example, what if the user input the following instead of “Smith”:

anything' OR 'x'='x

Note the placement of the apostrophes. Since $value parameter of the pre-defined SQL statement already includes apostrophes to enclose the variable, the intentional placement of further apostrophes gives opportunity to the SQL injector to extend the query to include more parameters – which is the core of SQLi. This extended statement now looks like this:

SELECT birth_date FROM member_information WHERE data = 'anything' OR 'x'='x';

This is a perfectly valid SQL statement, but instead of returning one value based on one record it would now return the birth_date from every instance where the targeted data was true (because x will always equal x). This means that the return would be the birth_date for every record in the table.

This is perhaps the most basic way to understand how SQL injection works. It's easy to see how this strategy can be easily harnessed and configured to extract sensitive information or even identify information regarding the schema of a particular database. On outset that may not look like too much of a reward for a successful cyber attack, but considering the data maintained by financial organizations and in military or government databases the gains could be far worth every bit of effort.

Is there a way to protect against SQLi? Yes there is, but that's an article for another day.



Posted by at 1 comment:
Subscribe to: Posts (Atom)