Securebits Blog

Security is not about 100% protection, but rather about continuously “raising the bar” to make the attacks more difficult and less feasible. However, as defensive techniques evolve, offensive techniques also evolve. The opposite is also true: as offensive methods improve, defensive methods also improve. This circle whose two poles are offensive and defensive techniques is always running where every pole is pushing the other to a better state.

SQL Injection attack is an example of this; it was as simple as entering [; or 1=1--] to test for the availability of SQL injection vulnerability. Recently, a method called “time-based blind SQL injection using heavy queries” has been populated. This method was introduced at Defcon 16 (2008). The aim of this method is both discovering the SQL injection vulnerability as well as extracting data from SQL tables.

SQL injection attack refers to inserting a valid SQL statement (or partial statement) that is passed unmodified to the application that executes this statement on a SQL Database server. The way the attacker would know whether the vulnerability exists or not is by seeing the page returned. Once an attacker inserts an input that breaks the SQL statement, the server returns an error, which is then displayed back to the attacker. Not only that, the server can also dump any execution results which makes the attack even easier; the attacker can SELECT whatever data from the database, and it will be displayed back to him/her.

However, what if the server does not show any error message or does not return any data at all except the allowed web page? This is done by many developers and system administrators as a defense method against SQL injection attack. In this case, an attacker cannot know directly if the vulnerability exists and cannot get the results back if the vulnerability indeed exists. The method to circumvent this is called “Blind SQL Injection” and the central theme of this attack is to identify a Boolean behavior. For example, if the SQL statement is executed with a ‘true’ condition, the server displays the home page whereas if the SQL statement results into a ‘false’ condition, the server displays a “wrong password” message. An example of blind SQL injection is the following two statements:

  SELECT user FROM Users WHERE uname = ‘t’ and 1=1

  SELECT user FROM Users WHERE uname = ‘t’ and 1=2

After this identification, the attacker can extract data by continuously sending ‘yes’/’no’ statements. The following example, taken from SQL Injection Cheat Sheet, tries to check the first character of the first table name, and by repeating this statement to check other characters, the attacker can extract valuable data:

  SELECT ID, Username, Email FROM [User]WHERE ID = 1 
  AND ISNULL (ASCII(SUBSTRING((SELECT TOP 1 name 
  FROM sysObjects WHERE xtYpe=0x55 AND name NOT IN
  (SELECT TOP 0 name FROM sysObjects WHERE xtYpe=0x55)),
  1,1)),0)>78--

Now, what if there is no Boolean behavior? What if the server returns the same page (or error message) all the time and the attacker cannot see any difference between different injected inputs? Blind SQL injection evolved to “Time-based Blind SQL Injection.” Instead of identifying a binary behavior, the attacker injects SQL statements with “wait” commands, the syntax of which is dependent on the SQL Database version. This command will instruct the SQL server to wait (i.e. sleep) for a period of time (e.g. 10 seconds). If, after injecting the SQL statements, the response is delayed for that period of time, the injected statement has executed successfully. Next, such behavior would be used to extract data. The attacker inserts a “wait” command within a condition, if the condition is true, the response is delayed for a period of time; and when the response is false, the response is returned immediately. The following statement checks the first bit of the first byte of the current database; if it is 1, the condition is ‘true’ and the server will pause for five seconds:

  declare @s varchar(8000) select @s = db_name() 
  if (ascii(substring(@s, 1, 1)) & ( power(2, 
  0))) > 0 waitfor delay '0:0:5'

As a security measure, some administrators disable the ‘wait’ commands; and in this case, the time-based blind SQL injection attack won’t work. The latest trend in SQL injection is “Time-Based Blind SQL Injection using Heavy Queries.” The idea here is to use heavy queries that take significant time to execute as a substitute of the ‘wait’ commands. As with time-based attack using ‘wait’ commands, the time-based attack using ‘heavy queries’ is used to identify a binary behavior: if the response from the server takes significant time (e.g. 10 seconds), the condition is ‘true’ whereas if the response is returned immediately, the condition is ‘false’. The following statement is an example, provided by ‘Chema Alonso’, of Blind SQL injection using heavy queries:

  http:/ /www.informatica64.com/blind2/pista.aspx?
  id_pista=1 and (SELECT count(*) FROM sysusers AS 
  sys1, sysusers as sys2, sysusers as sys3, sysusers 
  AS sys4, sysusers AS sys5, sysusers AS sys6, 
  sysusers AS sys7, sysusers AS sys8)>1 and 300 >
  (select top 1 ascii(substring(name,1,1)) from 
  sysusers)

So, the evolution of SQL injection attacks can be summarized in the following stages:
A. Simple SQL Injection Attack
B. Blind SQL Injection Attack
C. Time-Based Blind SQL Injection Attack
D. Time-Based Blind SQL Injection using Heavy Queries Attack