Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:13288
HistoryJun 22, 2006 - 12:00 a.m.

Re: Bypassing of web filters by using ASCII

2006-06-2200:00:00
vulners.com
3
    Jeremiah Grossman and I were able to get a proof of concept

working based off of Kurt's work that actually runs a simple piece of
JavaScript in IE, without using open or close angle brackets. Here's
the link to the post:

http://ha.ckers.org/blog/20060621/us-ascii-xss-part-2/

    I concur that it would be very likely that this would pass

through almost all the content filters known to date, although the
liklihood of exploit is fairly low for any given websites, given the
encoding needed (US-ASCII). This is more relevant to perhaps injecting
JavaScript from remote locations by which you have control and bypassing
AV or content filtering products that otherwise would restrict malicious
JavaScript.

On Wed, 21 Jun 2006, [email protected] wrote:

> _______________________________________________________________________
>
> iKu Advisory
> _______________________________________________________________________
>
> Product : Microsoft InternetExplorer 6
> : various filter applications
> Date : June 20th 2006
> Affected versions : all
> Vulnerability Type : bypassing security filters
> Severity (1-10) : 10
> Remote : yes
> _______________________________________________________________________
>
> 0. contents
>
> 1. problem description
> 2. affected software
> 3. bug description/possible fix
> 4. sample code
> 5. workaround
>
>
> 1. problem description
>
> The character set ASCII encodes every character with 7 bits. Internet
> connections transmit octets with 8 bits. If the content of such a
> transmission is encoded in ASCII, the most significant bit must be ignored.
>
> Of the tested browsers Firefox 1.5, Opera 8.5 and InternetExplorer 6,
> only the InternetExplorer does this correctly, the others evaluate the
> bit and display the characters as if they were from the character set
> ISO-8859-1. Although the behaviour of the InternetExplorer is the
> correct one, this creates a security risk: the author of a web page can
> set the bit on arbitraty characters without changing the look of the
> page. But virus scanners and content filters see completely different
> characters, so that there programs cannot detect viruses or spam.
>
> This offers spammers and virus writers the possibility to bypass
> installed spam and virus filters.
>
>
> 2. affected software
>
> Only the InternetExplorer displays ASCII encoded web pages as 7 bit. We
> checked several hardware router and antivirus solutions, all of which
> failed to detect malicious JavaScript in manipulated web pages.
>
>
> 3. bug description/possible fix
>
> It should be quite easy to close this hole within filter/scan
> applications by clearing the most significant bit on ASCII encoded web
> pages before analysing them.
>
>
> 4. sample page
>
> At
>
> http://www.iku-ag.de/ASCII
>
> you can find a test page that displays a secret message. IE6 displays
> the text correctly, Firefox 1.5 and Opera 8.5 display glibberish text.
> This page only shows that IE6 displays ASCII-text correctly and does not
> contain any content that a filter should sort out.
>
> Updated information can be found at
>
> http://www.iku-ag.de/sicherheit/ascii-eng.jsp
>
>
> 5. workaround
>
> There is no workaround know to us.
> –
> Kurt Huwig iKu Systemhaus AG http://www.iku-ag.de/ Vorstand Am Rцmerkastell 4 Telefon 0681/96751-0
> 66121 Saarbrьcken Telefax 0681/96751-66 GnuPG 1024D/99DD9468 64B1 0C5B 82BC E16E 8940 EB6D 4C32 F908
> 99DD 9468
>

-RSnake
http://ha.ckers.org/
http://ha.ckers.org/blog/feed/