Re: noise about full-width encoding bypass?

["Amichai Shulman" <shulman () imperva com>]

We have tested this technique for both XSS and SQL Injection with IIS
(and any backend database) and it works nicely.

The issue is that the web server translates the graphical equivalent
character to the actual character (so %uFF07 is actually translated by
the web server to an ASCII quote character). 


Amichai Shulman
CTO



Imperva, Inc.
125 Menachem Begin St.
Tel Aviv 67010
Israel

(972) 3-6840103 Office
(972) 54-5885083 Mobile
(972) 3-6840200 Fax
shulman () imperva com

 ................................        

SecureSphere
Named 
Editor's Choice for
Web Application Firewall
http://imperva.com/go/nc/

 

-----Original Message-----
From: full-disclosure-bounces () lists grok org uk
[mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of Brian
Eaton
Sent: Monday, May 21, 2007 5:22 PM
To: Web Security; Full-Disclosure
Subject: [Full-disclosure] noise about full-width encoding bypass?

Has anyone had a look at the full-width unicode encoding trick discussed
here?

http://www.kb.cert.org/vuls/id/739224

AFAICT, this technique could be useful for a homograph attack.  I don't
think it's useful for much else.  However, a few vendors have reacted
already, so I may be missing something important.

Here's why I think the attack is mostly harmless:

Let's say an attacker wants to use this technique to hide a SQL
injection attack.  They decide to use a full-width encoding for single
quote, 0xff 0x07.  They successfully bypass the IDS, because the IDS is
only scanning for normal single quotes.  (You can see the encodings and
their graphical representation here:
http://www.unicode.org/charts/PDF/UFF00.pdf)

If the SQL engine is processing queries in Unicode, then 0xff 0x07 will
be treated as a normal unicode character, not a single quote.
The sequence 0xff 0x07 is not equivalent to 0x27, the real single quote
value.  No SQL injection occurs.

If the SQL engine is processing queries in UTF-8, then 0xff 0x07 will be
converted from Unicode to UTF-8: 0xef 0xbc 0x87.  Again, the engine does
not recognize 0xef 0xbc 0x87 as equivalent to 0x27.

If the SQL engine is processing queries in ASCII or ISO-8859-1, the
conversion from unicode to the code page used by the engine will fail.
 Either the engine will give up on the query, or it might substitute a
question mark (?) for the unconvertible character.

To summarize: I think half-width and full-width unicode characters are
characters that happen to have the same graphical representation as
other characters, but don't carry any special significance outside of
that graphical representation.  The graphical representation can be
important in homograph attacks, but otherwise I don't see this technique
as particularly useful to an attacker.

Any comments on what I may have missed?

Regards,
Brian

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/