Agreed, nice find. Here are some perl scripts to do the transcoding (I called it asciilate.pl):
#!/usr/bin/perl -n
#enable 8th bit on ascii characters sent to stdin, output to stdout
foreach $c (split//,$_) {print chr(ord($c)+128)}
#!/usr/bin/perl
#as above, add content-type header to make it work in IE at the start of the output
print '<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">';
while (<>) {foreach $c (split//,$_) {print chr(ord($c)+128)}}
#!/usr/bin/perl
#as previous, but only convert some of the input characters, making it look even
#more obfuscated than complete conversion.
print '<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">';
while (<>) {foreach $c (split//,$_) {print chr(ord($c)+128*int(rand(1)+.5))} }
--
Hubert Seiwert
Internet Security Specialist, Westpoint Ltd
Albion Wharf, 19 Albion Street, Manchester M1 5LN, United Kingdom
Web: www.westpoint.ltd.uk
Tel: +44-161-2371028
k.huwig@xxxxxxxxx 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
>
>
