Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security FullDisclosure
[Top] [All Lists]

[Full-disclosure] noise about full-width encoding bypass?

Subject: [Full-disclosure] noise about full-width encoding bypass?
Date: Mon, 21 May 2007 10:22:21 -0400
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/

<Prev in Thread] Current Thread [Next in Thread>