Bugtraq: Re: Bypassing of web filters by using ASCII

["Amit Klein (AKsecurity)" <aksecurity () hotpop com>]

On 21 Jun 2006 at 18:24, Paul wrote:

> Very interesting, indeed. Does this work with functional characters
> such as html brackets? What about html tag obfuscation (bypassing
> script filters such as those in place at hotmail)?
Notice that in order for this trick to work, the charset should be explicitly set to "US-
ASCII". The default charset for HTTP text/html messages is ISO-8859-1 (From RFC 2616,
section 3.7.1: 'When no explicit charset parameter is provided by the sender, media
subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1"
when received via HTTP'), which does define the high-bit values in octets. In other words,
in order to successfully exploit this, the attacker needs to control the page/message
charset. This can be done through the Content-Type header (as demonstrated in the original
post's demo URL - notice that it sends the following response header: "Content-Type:
text/html;charset=US-ASCII") or (I believe) via the META tag (using the HTTP-EQUIV
attribute).
So in order to exploit this in HTML over HTTP, the attacker needs to either add/modify the
Content-Type response header, or to add/modify the META tag in the HTML page.

-Amit


> Nice find.
>
> Paul
>
> On 6/21/06, Fixer <fixer () gci net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > This also affects IE 7 Beta 2.
> >
> > Did you shoot this over to Microsoft?
> >
> > k.huwig () iku-ag de 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
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.3 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iQEVAwUBRJmo5wt0Y4479LtgAQJ6/gf9HiQlg8HcteEKECisR3x0sWH0hptcr9De
> > aaaQMJkTvnlwtTKTnrIe7TdZaeAKPNnsh6VMyS5zaOPqnwFfjKjmRK21Ml6m0wLB
> > fKR8XQM+xO9hdNSO7wvjFJC8/NuDhts3M6hKiUHcOqOEEmWH+jll1OchiDTG3AB3
> > 9vAIH1WuYH101gOwt9RSYD3kjujQjro+RQWj5eez42MZEn7k/Fl69XtaVbjMb16M
> > Ud99mpk45JKUWUOuSXXT5VEQJI95M+9Oe7IZmchI89hCDtD6Q38tBGo8nrBweld8
> > /WFdI5v1YStONnJS1mB1zeGmn1nyXiRRN+2KDaNYc0rld6v1He6SpA==
> > =fAiX
> > -----END PGP SIGNATURE-----