LaMeH@CkeR

Introduction

Not a few articles have been written about the subject I am going to write the article about. And what I am going to comment on, as you already guessed is US ASCII encoding used to by pass the web filters. Now when initially I found this vulnerability, actually I did not find it someone else did I just think it is interesting, I thought the this is going to have a mass impact all web sites!! but unfortunately or fortunately it does not. Anyway, the issues is that 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.

The Security problem

Of the tested browsers Firefox 1.5 and above, Opera 8.5 and above and Internet Explorer 6 and 7, only the Internet Explorer versions 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 behavior of the Internet Explorer is the correct one, this creates a security risk: the author of a web page can set the bit on arbitrary 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. [1]

What do we mean by saying US-ASCII

There are several national variants of ASCII. In such variants, some special characters have been replaced by national letters (and other symbols). There is great variation here, and even within one country and for one language there might be different variants. The original ASCII is therefore often referred to as US-ASCII; the formal standard (by ANSI) is ANSI X3.4-1986.[5]

The name ASCII, originally an abbreviation for “American Standard Code for Information Interchange”, denotes an old character repertoire, code, and encoding.

Most character codes currently in use contain ASCII as their subset in some sense. ASCII is the safest character repertoire to be used in data transfer. However, not even all ASCII characters are “safe”!

ASCII has been used and is used so widely that often the word ASCII refers to “text” or “plain text” in general, even if the character code is something else! The words “ASCII file” quite often mean any text file as opposite to a binary file.

The phrase “original ASCII” is perhaps not quite adequate, since the creation of ASCII started in late 1950s, and several additions and modifications were made in the 1960s. The 1963 version had several unassigned code positions. The ANSI standard, where those positions were assigned, mainly to accommodate lower case letters, was approved in 1967/1968, later modified slightly. For the early history, including pre-ASCII character codes, see Steven J. Searle’s A Brief History of Character Codes in North America, Europe, and East Asia and Tom Jennings’ ASCII: American Standard Code for Information Infiltration. See also Jim Price’s ASCII Chart, Mary Brandel’s 1963: ASCII Debuts, and the computer history documents, including the background and creation of ASCII, written by Bob Bemer, “father of ASCII”.[5]

The explanation

Lets say for example that we want to see if a website is encoding or filtering the < character, what someone would do is to inject < and see what the web application would return.

Now if the web app returns something like < or < then the web application is probably not vulnerable to XSS, now if the web app is using the US-ASCII then things change for IE6/7. IE is going to process all US-ASCII encoding with the most significant bit set .To process for example the < character with IE first we have to convert < to hex meaning in 3c and add hex 80, meaning 3c+80 = bc and then we do a url encoding, then the < is equivalent to %bc for IE6/7 this is a valid encoding.

This offers spammers and virus writers the possibility to bypass installed spam and virus filters. We checked several filter products and all of these failed to detect the manipulated web pages. But it should be quite easy to close this hole by clearing the most significant bit on ASCII encoded web pages before analyzing them.

The JavaScript code:

<script>alert(”This is some obfuscated script!”);</script>

Here is some C# code that removes the most significant bit from the javascript:

int char1;
Char c1;
FileStream fs = new FileStream([file path], FileMode.Open);
BinaryReader r = new BinaryReader(fs);

r.BaseStream.Seek(0, SeekOrigin.Begin);

while (r.BaseStream.Position < r.BaseStream.Length)
{
char1 = r.ReadByte();
char1 = char1 – 0×80;
c1 = (Char)char1;
Console.Write(c1);
}

Code example 1:Removing most significant bit [2].

NOTE1: there has been significant discussion about this issue, and as of 20060625, it is not clear where the responsibility for this issue lies, although it might be due to vagueness within the associated standards.[3]

NOTE2: this might only be exploitable with certain encodings.[3]

CVSS Severity (version 2.0 upgrade from v1.0):
CVSS v2 Base score: 2.6 (Low) (AV:N/AC:H/Au:N/C:N/I:P/A:N) (legend)
Impact Subscore: 2.9
Exploitability Subscore: 4.9 [3]

Access Vector: Network exploitable , Victim must voluntarily interact with attack mechanism
Access Complexity: High
Authentication: Not required to exploit
Impact Type: Allows unauthorized modification [3]

Current situation

I?€™m happy to report that IE8 is delivering additional XSS-Focused Attack Surface Reduction goodness. For Beta 1 you will notice a small but notable step forward ?€“ the US-ASCII XSS attack vector has now been closed.

External Source: XF (disclaimer) Name: ie-ascii-encoded-web-filter-bypass(27288)

Hyperlink: http://xforce.iss.net/xforce/xfdb/27288

External Source: BUGTRAQ (disclaimer) Name: 20060623 Re: Bypassing of web filters by using ASCII

Hyperlink: http://www.securityfocus.com/archive/1/archive/1/438163/100/0/threaded

External Source: BUGTRAQ (disclaimer) Name: 20060623 RE: Bypassing of web filters by using ASCII

Hyperlink: http://www.securityfocus.com/archive/1/archive/1/438154/100/0/threaded

External Source: BUGTRAQ (disclaimer) Name: 20060622 Re: Bypassing of web filters by using ASCII

Hyperlink: http://www.securityfocus.com/archive/1/archive/1/438066/100/0/threaded

External Source: BUGTRAQ (disclaimer) Name: 20060621 Re: Bypassing of web filters by using ASCII

Hyperlink: http://www.securityfocus.com/archive/1/archive/1/438049/100/0/threaded

External Source: BUGTRAQ (disclaimer) Name: 20060621 Bypassing of web filters by using ASCII

Hyperlink: http://www.securityfocus.com/archive/1/archive/1/437948/100/0/threaded

External Source: BUGTRAQ (disclaimer) Name: 20060621 Re: Bypassing of web filters by using ASCII

Hyperlink: http://www.securityfocus.com/archive/1/438051/100/0/threaded

External Source: (disclaimer)

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

External Source: BUGTRAQ (disclaimer) Name: 20060626 RE: Bypassing of web filters by using ASCII

Hyperlink: http://www.securityfocus.com/archive/1/archive/1/438359/100/0/threaded

External Source: BUGTRAQ (disclaimer) Name: 20060626 Re: Bypassing of web filters by using ASCII

Hyperlink: http://www.securityfocus.com/archive/1/archive/1/438358/100/0/threaded

External Source: OSVDB (disclaimer) Name: 28376

Hyperlink: http://www.osvdb.org/28376

External Source: (disclaimer)

Hyperlink: http://ha.ckers.org/blog/20060621/malformed-ascii-bypasses-filters/

Vulnerable software and versions

Configuration 1
??’	Microsoft, Internet Explorer, 6.0.2900

Reference[1]:http://www.iku-ag.de/sicherheit/ascii-eng.jsp

Reference[2]:http://blogs.msdn.com/dross/archive/2006/10/01/780339.aspx

Reference[3]:http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-3227

Reference[4]:http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx

Reference[5]:http://www.cs.tut.fi/~jkorpela/chars.html#examples