35 Classifying SQL Injections

There are a wide variety of SQL injection techniques. Sometimes several are used to mount a single attack. It’s useful to examine:

Route - where injection happens.
Motive - what it aims to achieve.
SQL code - the form of SQL injected.

Injection Routes

User inputs e.g., web forms via HTTP GET or POST.
Cookies used by web apps to build queries
Server variables logged by web apps (e.g., HTTP headers)
Second-order injections where the injection is separated from attack.

Primary and Auxiliary Motives

Primary motives may be:

Extracting data
Adding or modifying data
Mounting a denial-of-service attack
Bypassing authentication
Executing arbitrary commands

Auxiliary motives may be:

Finding injectable parameters
Database server fingerprinting
Finding database schema
Escalating privilege at the database level

Forms of SQL Code injected

Tautologies

Inject code into condition statements so they always evaluate to true.

SELECT accounts FROM users WHERE
login =’’ or 1=1 -- AND pin=

Blacklisting tautologies is difficult :

Many ways of writing them: 1>0, ’x’ LIKE ’x’, etc.
Quasi tautologies: very often true RAND()> 0.01.

Illegal/incorrect queries

Cause a run-time error, hoping to learn information from error responses.

SELECT accounts FROM users WHERE
login =’’ AND pin = convert (int ,( select top 1 name from
sysobjects where xtype =’u’))

Explanation :

Assumes MS SQL Server.
sysobjects is a server table of metadata.
Attempts to find first user table.
Converts name into an integer $\to$ Runtime error. Example Error Response :

Microsoft OLE DB Provider for SQL Server (Ox80040E07)
Error converting nvarchar value ’CreditCards’
to a column of data type int

Tells the attacker :

MS SQL Server is running.
The first user-defined table is called CreditCards.

Union query

Inject a second query using UNION :

SELECT accounts FROM users WHERE
login =’’ UNION SELECT cardNo from CreditCards where
acctNo =10032 -- AND pin =

Effect :

Suppose there are no tuples with login=’’.
May reveal cardNo for account 10032.

Piggy-backed queries

The Bobby Tables attack is an example of a piggy-backed query.

SELECT accounts FROM users WHERE
login =‘doe ‘; drop table users -- ‘ AND pin =

Explanation :

Database parses second command after ;.
Executes second query, deleting users table.
Some servers don’t require the ; character.

Inference pairs

Even if error responses are not visible to the client, information can still be extracted by observing subtle differences between outputs. Two common techniques :

Blind Injection – exploits visible differences in responses.
Timing Attack – exploits variations in response time based on boolean conditions (e.g., using WAITFOR).

Idea : Discover whether the login parameter is injectable. Step 1: Always true

login =’legalUser ’ and 1=1 -- ’

Response : INVALID PASSWORD The attacker thinks : Perhaps my invalid input was detected and rejected, or perhaps the username query was executed separately from the password check.

Step 2: Always false

login =’legalUser ’ and 1=0 -- ’

Response : INVALID USERNAME AND PASSWORD The attacker thinks : Aha! The response is different! Now I can infer that the login parameter is injectable.

Stored procedures and other DBMS features

Stored procedures are custom sub-routines that provide support for additional operations.

CREATE PROCEDURE DBO . isAuthenticated
@userName varchar2 , @pin int
AS
EXEC (" SELECT accounts FROM users
WHERE login =’" + @userName + "’ and pass =’" + @pin + "’ ");
GO

Risk: If improperly sanitized, can allow SQL injection inside the stored procedure !

A particularly dangerous stored procedure

Microsoft SQL Server provides xp_cmdshell, which allows executing OS commands!

EXEC master .. xp_cmdshell ‘format c:‘

Mitigation:

Since SQL Server 2005, this is disabled by default.
But DB administrators can re-enable it.
Worse, an attacker with SQLi access might be able to enable it! Lesson: Access control and passwords are critical inside the database !

📝 My Obisidan Notes

Explorer