Re: Cross-Site Scripting vulnerabilities in Mozilla, Internet Explorer, Opera and Chrome
At first glance there it missed vbscript:? On Sat, Jul 4, 2009 at 1:07 AM, Michal Zalewskilcam...@coredump.cx wrote: refresh: 0; URL=javascript:alert(document.cookie) The code will work in context of this site. ...which happens to be covered here for half a year or so: http://code.google.com/p/browsersec/wiki/Part2#Redirection_restrictions I can't see how this could be a vulnerability per se, although changing the behavior offers an additional, if small, degree of protection in case of security lapses in web applications, so it's a reasonable improvement. Cheers, /mz
Google Chrome Break
Address spoofing. Already patched. It's in the news last month. Just a reminder, XCON'08 is coming in a week - check http://xcon.xfocus.org/ greetz to drewcopley, drorshalev, zwell, liuyuer, lqa21, and, of course [EMAIL PROTECTED] -- http://liudieyu.com/kissofthedragon.32168816196486005/ To be viewed with Google Chrome Last tested Wednesday, October 29, 2008 at 9:53:18 AM (time zone: UTC/GMT +8 hours) Up-to-date Google Chrome (version: 0.2.149.30) Contents Address spoofing. 1. Address is displayed bbb.org. 2. Contents are not from bbb.org(contents are manipulated). http://twitter.com/liudieyu Google Chrome is still virgin - Right now only had a bunch of D.o.S, and, a buffer overrun if user saves the attacker's webpage.
Firefox Privacy Broken If Used to Open Web Page File
Brief from my Twitter: The effect is exposing any location, incl your browsing history(about:cache etc) 04:54 AM October 05, 2008 from web Workaround: Do not use Firefox to open HTM/HTML - not from RAR package, not from remote Windows share folder, not from local, etc. 04:36 AM October 05, 2008 from web Some details from my blog: * Also works on Firefox 3.0.3 * Also works on Firefox 3.0.2 ... For Firefox, location is wrong when dot URL shortcut is launched by HTML elements. Slightly variant from CVE-2008-2810 which is about command line and only fixed in that perspective. ... __ Complete details and demo are available at http://liudieyu0.blog124.fc2.com/blog-entry-6.html
MSIE:patchedundisclosed XSS vuln
MSIE:patchedundisclosed XSS vuln (that's all is end of file if you are in a hurry) [tested] OS:Windows XP Professional Browser: MS Internet Explorer 6.0.2600..xpclient.01087-1148 (without any patch) (note: it doesn't work on the patched MSIE) [demo] at http://www.safecenter.net/liudieyu/AutoScanJPU/AutoScanJPU-MyPage.htm or http://umbrella.mx.tc == AutoScanJPU-MyPage section [exp] window.external.AutoScan method can navigate other windows to somewhere, and it doesn't filter Javascript-protocol url. that's all. [how] http://www.safecenter.net/CrossZone/ie/UJPU.HTM [gossiping] does anyone here know other vulnz patched silently? greetings to: the Pull, dror, guninski and Vadim Krochak - and gean! best wishes die make notes easily! - http://www.safecenter.net/liudieyu/domex - http://domex.int.tc --- all mentioned resources can be found at http://umbrella.mx.tc
(MSIE)A rather old trick for web server is now played on MSIE.
(MSIE)A rather old trick for web server is now played on MSIE.
(that's all is the end of file if you are in a hurry)
[tested]MSIEv6(CN version)
Patch: Q312461,Q328970(MS02-066)
{IEXPLORE.EXE file version: 6.0.2600.}
{MSHTML.DLL file version: 6.00.2600.}
[demo]
at
http://www16.brinkster.com/liudieyu/viaSWFurl/viaSWFurl-MyPage.htm
or
clik.to/liudieyu == viaSWFurl-MyPage section.
or
[code.url start]
http://www.macromedia.com//shockwave/download/triggerpages_mmcom/flash.swf?
lt;SCRIPTgt;alert(document.cookie)lt;/SCRIPTgt;
[code.url end]
[exp]
MSIE generates a page to load a multimedia file instead of loading it
directly.
the automatically generated page for loading an SWF(the extension of a
flash file) file contains URL of the SWF file -- without any encoding.
so the oldest XSS trick works on MSIE.
that's all.
[how]
(real show)
first, realize MS programmers are lazy(= too busy) and they prefer to
look wise, so you can doubt that they generate a page to load a multimedia
file.
then, check it: i played a small trick: typing
javascript:alert(document.body.innerHTML)
in the address field when the content of MSIE is a JPG file.
soon after confirmation, try the trick and you'll find it doesn't work on
a JPG file because the URL is encoded properly.(that programmer must have
been fired for his defence)
now you may lose self-confidence -- MS is not that foolish.
but thinking about document.open hole(not flaw) will encourage you.
(the essential point!)
then after several tries, you have this document.
(very few steps)
[more?]
this trick may work on other browsers, but i can't test it at present.
[BTW]
(0)merry Christmas!
(1)Greetings to the Pull
(2)there are many demoz at http://www.safecenter.net (thanx to Dror
Shalev for making them)
(3)i'm busy with exams, hope you can understand and forgive my delay (the
school is really crazy). i'll have a 30-day holiday. i think it's enough
to make a site showing tricks i know, why they work,how to exploit them,
and how people got the ideas. it's crosszone.org(not ready yet)
(4)LOTUS: i am slow.
[contact]
clik.to/liudieyu == How to contact Liu Die Yu section
(any postcard? :-) )
XSS flaw found at https://www.e-gold.com
i know bugtraq doesn't accept vulnerability on one site, but the following info is important; please suggest a forum for me to post. ===-- XSSatEGOLD-Content-Tech XSS flaw found at https://www.e-gold.com; technically, it's nothing new. XSS at E-gold is very dangerous. E-gold is one of the most popular way to do international business. and unlike credit card system, e-gold sent, it never comes back. there is no refund policy. so stealing passphrase means stealing real gold. it's important, so i take it seriously. [tested] browser:MSIEv6 time:2002/12/10 UTC+800 [demo] at http://www16.brinkster.com/liudieyu/XSSatEGOLD/XSSatEGOLD-MyPage.htm or http://clik.to/liudieyu ==XSSatEGOLD or [CODE.URL START] https://www.e-gold.com/acct/historycsv.asp? initial=1lt;SCRIPTgt;s=You_can_NOT_trust_this_page_if_you_got_if_from_a_ link.by_LiuDieYu_http://clik.to/liudieyu;w=window.open(https://www.e- gold.com/acct/login.html);setTimeout(w.document.write (s),150);lt;/SCRIPTgt;startmonth=12startday=4startyear=1996endmonth=12end day=4endyear=2003paymentsreceived=1oldsort=tstamppage=1 [CODE.URL END] [exp] technically, there is only one thing important for XSS attackers: some CGI can only be found when you are logged in, but they can be reached even if you are not logged in. of course, the module dealing with logged-in users is different from the one dealing with un-logged-in users. so, you have to test in both situations to ensure it's not XSS vulnerable. [contact] http://clik.to/liudieyu == how to contact liu die yu section [BTW] this flaw can be found easily with FASX at http://clik.to/fasx
Poisonous Style for Dialog window turns the zone off.
Poisonous Style for Dialog window turns the zone off.
(that's all is the end of file if you are in a hurry)
[tested]
MSIEv6(CN version)
Patch: Q312461,Q328790(MS02-066)
{IEXPLORE.EXE file version: 6.0.2600.}
{MSHTML.DLL file version: 6.00.2600.}
[demo]
at
http://www16.brinkster.com/liudieyu/PoisonousSTYLEforDialog/PoisonousSTYLEf
orDialog-MyPage.htm
or
clik.to/liudieyu == PoisonousSTYLEforDialog-MyPage section.
[exp]
you can appoint the style of text in window(a ModalDialog window) opened
by showModalDialog() regardless of zone difference.
the style can cause execution of script, one example:
IMG width=0 height=0 style=width: expression(alert());
so poisonous style can do XSS at client side.
that's all
[how]
i spent some time trying to bypass hotmail script filtering, so i read
something about it, including the above one from Guninski.
so, i got this one as soon as i read the description of showModalDialog
() at MSDN.
[BTW]
if you are interested in XSS at server side, don't miss a tool at
http://clik.to/fasx
(MSIE) when parent gives his son bad things ;) --dialogArguments again
IFRAME in a page opened by openModalDialog has dialogArguments of its
parent.
[tested]MSIEv6(CN version)
{IEXPLORE.EXE file version: 6.0.2600.}
{MSHTML.DLL file version: 6.00.2600.}
[demo]
at
http://www16.brinkster.com/liudieyu/BadParent/BadParent-MyPage.htm
or
clik.to/liudieyu == BadParent-MyPage section.
/*note: please tell me if MSIE SP1 allows an internet page contains an
iframe with local content*/
[exp]
IFRAME in a page opened by openModalDialog has dialogArguments of its
parent. so Attacker can open (via openModalDialog) his page which
contains an iframe whose content is in the victim zone and
uses dialogArguments directly without filtering.
in the demo:
(*)victim zone is localzone;
(*)the page from victim zone is res://shdoclc.dll/privacypolicy.dlg; it
uses cookieUrl without filtering.
[how]
realize that IFRAME has some properties the same as those of its parent.
but the parent can be bad.
(BTW, i used to hate that my parents give me many bad things, now i
realize it's my job to resist bad things. ;) )
[contact]
clik.to/liudieyu == How to contact Liu Die Yu section
MSIE:SaveRef cracks (VictimWindow).document.write
[title]MSIE:SaveRef cracks (VictimWindow).document.write
[digest]
MSIE: you can always call (VictimWindow).document.write regardless its
zone if you have its reference.
(please read [more?] section; i think it's important.)
[tested]MSIEv6(CN version)
{IEXPLORE.EXE file version: 6.0.2600.}
{MSHTML.DLL file version: 6.00.2600.}
Win98
[demo]
at
http://www16.brinkster.com/liudieyu/SaveRef_DocumentWrite/SaveRef_DocumentW
rite-MyPage.htm
or
clik.to/liudieyu == SaveRef_DocumentWrite-MyPage section.
[exp]
save the reference of (NewWindow).document.write when the zone
of (NewWindow) is yours. then you can call it via reference even if its
zone is not yours.
simple, that's all.
[more?]
i've read some doc about COM(Component Object Modal) at MSDN.
MSDN says
The server is primarily responsible for securitythat is, for the most
part, the server determines whether it will provide a pointer to one of
its objects to a client
(at http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/com/comext_99df.asp)
this causes Georgi Guninski 's (victimWindow).document SaveRef flaw. i
guess the patch just plants a security checker in window.document .
but method-SaveRef is not that easy to patch since there are so many
methods in so many objects in so many APPLICATIONS(not only MSIE).
SaveRef may end up turning M$ off? ;)
i don't know. please tell me your opinion via email.
(my physical work is all over,so reply in 24 hours)
[contact]
[EMAIL PROTECTED]
or
clik.to/liudieyu === how to contact liu die yu section
MSIE:SaveRef turns Zone off
TITLEMSIE:SaveRef turns Zone off/TITLE
[digest]
MSIE: you can execute jscript in any zone by saving the reference
of (NewWindow).location.assign.
(content after the [exp] section is not directly related to the flaw, so
skip it if you are in a hurry;)
[tested]MSIEv6(CN version)
{IEXPLORE.EXE file version: 6.0.2600.}
{MSHTML.DLL file version: 6.00.2600.}
Win98
[demo]
at
http://www16.brinkster.com/liudieyu/SaveRef/SaveRef-MyPage.htm
or
clik.to/liudieyu == SaveRef-MyPage section.
[exp]
javascript-protocol URL can cause CSS at client side, so microsoft
blocked (NewWindow).location.assign method(there is no other explanation
at all). but we can save the reference(mostly the same as 'pointer' in C)
of (NewWindow).location.assign when we can access it, then we can access
it forever -- regardless of NewWindow's zone, which means we can execute
jscript in any zone.
simple, that's all.
[BTW]
thanx to :
0. all knowledge bases
1.dror shalev, without his Who Framed IE demo at
http://drorshalev.brinkster.net/dev/Search
and his words, i wouldn't have discovered this flaw.(both SaveRef Who
Framed IE hurt microsoft's heart -- OOP/COM/DCOM ;)
2.the Pull, his words at
http://home.austin.rr.com/wiredgoddess/thepull/UnorthodoxBugFinding.txt
are inspiringpractical.
[apology]
i am always late for online issues because of everything around me( one
example is my parents), but i've never been absent;)
[contact]
[EMAIL PROTECTED]
or
clik.to/liudieyu === how to contact liu die yu section
MSIEv6 % encoding causes a problem again
it's about cross-site scripting at MSIEv6 client side using % encoding,
but not the same as the one by PeaceFire.org which doesn't work on my PC.
[tested]MSIEv6(CN version)
{IEXPLORE.EXE file version: 6.0.2600.}
{MSHTML.DLL file version: 6.00.2600.}
[demo]
at
http://www16.brinkster.com/liudieyu/2FforMSIE/2FforMSIE-MyPage.htm
or
clik.to/liudieyu == 2FforMSIE-MyPage section.
[exp]
%?? in URL is decoded when IE caculates the domain, but not decoded while
downloading a page.
so
[CODE.URL]http:[EMAIL PROTECTED]/liudieyu
( 2F=hex$(asc('/')) )
leads to clik.to/liudieyu instead of www.yahoo.com, and the domain of it
www.yahoo.com for IE
Very simple, that's all.
[contact]
[EMAIL PROTECTED]
