Az elmúlt hónapban több levél is foglalkozott az US-ASCII web tartalom kezelésével. A gond az, hogy az eszközök egy része úgy értelmezi, hogy az US-ASCII 7 bites és egyszerűen levágja a legfelsőbb bitet. A másik részük azonban ISO8859-1 karakterkészletként értelmezi, azaz meghagyja a legfelsőbb bitet. Ez komoly problémákat okozhat a böngészőkben valamint a szűrőkben, hiszen pl. javascript kód is bejuttatható úgy, hogy a törlésre kerülő legfelsőbb bitet beállítjuk.
--- Begin Message ---_______________________________________________________________________ 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
--- End Message ---
--- Begin Message ---Paul schrieb: > 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)? This works for the whole set of ASCII characters. I was able to create a HTML page where the MSB was set on all bytes of the file, i.e. also all brackets, and it worked fine with IE. I did not check hotmail's script filters. > Nice find. Thanks. I happened to read Wikipedia's ASCII page on my lunch time and stumbled upon "the eighth bit was commonly used as a parity bit for error checking on communication lines or other device-specific functions. Machines which did not use parity typically set the eighth bit to zero, though some systems such as Prime machines running PRIMOS set the eighth bit of ASCII characters to one." Then I was curious what our browsers do with this. The hardest thing was to get the test page up; the PrintWriter used by JSP deletes the MSB, so I had to use a servlet. -- 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 9468Attachment: signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---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----- > >
--- End Message ---
--- Begin Message ---RSnake schrieb: > > 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. I was able to get your example working on a normal HTTP server by adding this to the <head>er: <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII" /> Demo page is here: http://www.iku-ag.de/ascii.cgi.htm -- 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 9468Attachment: signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---imipak schrieb: > Hmmm, I just noticed Firefox's Accept-Charset header doesn't include > ASCII. Does the HTTP spec say that ASCII is the default charset? No, it's ISO-8859-1. According to http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-035.pdf Page 27 (37): "11.2 Transformation from 7-bit to 8-bit codes Within a CC-data-element any 7-bit combination has an equivalent 8-bit form comprising b7 to b1 of the 7-bit form, together with a b8 of ZERO." the MSB must be set to 0. The folks at Mozilla say it is evangelism for some broken AOL pages, but then I ask why evangelism, when it does not work with IE? -- Mit freundlichen Grüßen 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 9468Attachment: signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---Hi, I've found that the two methods you described work, e.g. using HTML such as this: <html> <link rel="stylesheet" type="text/css" href="ascii.css"> <span>If this text is orange and an alert appears, the obfuscated JS in the CSS was evaluated</span> </html> and a CSS file like this: ---ascii.css--- @charset "US-ASCII"; óðáî û ãïìïòº ïòáîçå» âáãëçòïõîäº õò쨧êáöáóãòéðôºáìåòô¨¢èåìì»§© ý /* code above is span { color: orange; background: url('javascript:alert("hello");') } */ --------------- The color attribute and JS code get executed in IE. I could not get @charset to work as an inline style directive. Setting document.charset also works, although I have to reload the page in IE (this can probably be avoided with some further hacking): <html> <head> <script>document.charset = 'US-ASCII';</script> </head> <body>¼óãòéðô¾áìåòô¨§ôåóô§©¼¯óãòéðô¾</body> </html> So to change the charset, you need to be able to inject into the stylesheet, include a remote stylesheet, or inject script code to set document.charset. If any of those are possible, an attacker may as well inject malicious code directly, though being able to obfuscate the JS code in this way may help bypass client side filters. I don't currently see how this "ascii vulnerability" would make code injection possible on webservers where the Content-Type is not US-ASCII already, as the 3 methods mentioned to change the charset (http-equiv content-type header, CSS @charset, document.charset) depend on being able to inject things already. Regards, -- 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 James C. Slora Jr. wrote: > Amit Klein wrote Thursday, June 22, 2006 3:47 AM > >> 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. > > There are other ways that might carry a bigger injection threat: > > Style sheet: > http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/properties/charset_1.asp > > Object property: > http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/properties/charset.asp > > > By extension, it should also work for inline styles.
--- End Message ---