I recently encountered an interesting collection of attempted SQL injections. The following SQL code strings were recovered from server logs:
' Declare @q Varchar(8000) Select @q = 0x57414954464F522044454C4159202730303A30303A313527 Exec(@q) --
1 Declare @q Varchar(8000) Select @q = 0x57414954464F522044454C4159202730303A30303A313527 Exec(@q) --
1) Declare @q Varchar(8000) Select @q = 0x57414954464F522044454C4159202730303A30303A313527 Exec(@q) --
') Declare @q Varchar(8000) Select @q = 0x57414954464F522044454C4159202730303A30303A313527 Exec(@q) --
These four lines of SQL are a clever SQL-injection test used to determine whether or not a server is vulnerable to any type of SQL injection. Unlike your standard garden-variety SQL injection attempt like “‘ OR 1=1–”, this code can also be used to detect servers vilnerable to blind sql injection while leaving no trace on the database itself.
If you saw this or a similar type attack in your server logs, it means that your application has been probed by a hacker checking for SQL injection vulnerabilities. If you take care to sanitize your data and notice no other SQL injection attempts after the probes, chances are the hacker found your server was not vulnerable and moved on. But if these are only the first in a long string of injections against your site, you have cause to worry. A lot.
First, let’s analyze the attack code. The probe is broken down into five parts – the trigger, the variable declaration, the encoded payload, the payload execution, and the ending comment. Here’s how it works:
1) The trigger – this breaks the SQL query and allows injection of commands (if the application is vulnerable)
2) The variable declaration – create a variable, q, to hold an arbitrary string
Declare @q Varchar(8000)
3) The encoded payload – a hex-encoded SQL command, which is SELECTED into the variable q. The hex encoding obfusticates the payload and (somewhat) helps avoid detection
Select @q = 0x57414954464F522044454C4159202730303A30303A313527
4) The decoded SQL statement now contained in q is executed by the exec() command
5) The ending comment – standard SQL injection, comments out the rest of the native command
The hex-encoded string in this attack, 0x57414954464F522044454C4159202730303A30303A313527, can be decoded easily with any hex tool. The plaintext is the following SQL code:
WAITFOR DELAY '00:00:15'
The WAITFOR DELAY command simply causes the SQL server to sleep for 15 seconds before concluding the query and returning. This will effectively slow the page load time by 15 seconds if successful.
So, all together, if this payload is successfully executed against a web application it will cause the page to load fifteen seconds slower then normal while leaving no traceable effects on the target database. This means that even if you’ve been careful to avoid outputting SQL errors, a server vulnerable to SQL injection can still be detected using this attack by measuring and comparing load times with and without the payload.
The four iterations of this code each change the trigger, attempting to find a combination that results in a successful SQL injection.
If a positive result is gained through this test,. an attacker can begin a blind SQL injection attack against your server. A successful attack could result in data loss or even complete server compromise if features like XP_CMDSHELL() are available on your server’s SQL installation.
This exact probe is quite commonly used across a variety of automated SQL-injection penetration testing frameworks frequented by script kiddies and hackers alike. Protect yourself by religiously cleaning all of your inputs with mysql_real_escape_string() and regular expressions, protect input forms with CAPTCHAS, and keep good logs so you can quickly discover and respond to attacks. If your code was written correctly, your sanitization should effectively escape and render these probes useless:
\\\' Declare @q Varchar(8000) Select @q = 0x57414954464F522044454C4159202730303A30303A313527 Exec(@q) --