bugtraq - Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

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>] [day] [month] [year] [list]

Message-ID: <6905b1570701031318h78815383q4e7f42a8d05e7773@mail.gmail.com>
Date: Wed, 3 Jan 2007 21:18:48 +0000
From: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
To: "James Landis" <jcl24@...nell.edu>
Cc: "Amit Klein" <aksecurity@...il.com>, bugtraq@...urityfocus.com,
	"Web Security" <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

The impact of this issue is huge.

Web worms can use Jeremiah's css history dump and login detection
hacks together with the Google AJAX Search API hack in order to create
a massive WEB infection. In fact, such type of malicious code can be
trivially composed in half an hour. This is a vary scary thought.

REFS:
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html
http://jeremiahgrossman.blogspot.com/2006/12/i-know-if-youre-logged-in-anywhere.html
http://www.gnucitizen.org/blog/google-search-api-worms
http://www.gnucitizen.org/projects/attackapi

On 1/3/07, James Landis <jcl24@...nell.edu> wrote:
> Why bother with the token handling? If the request URI is a PDF and it is a
> POST or contains URL parameters, just 30x to the naked PDF. Otherwise it's
> safe to serve.
>
> -j
>
>
> On 1/3/07, Amit Klein <aksecurity@...il.com> wrote:
> > Amit Klein wrote:
> > > pdp (architect) wrote:
> > >> I will be very quick and just point to links where you can read about
> > >> this issue.
> > >>
> > >> It seams that PDF documents can execute JavaScript code for no
> > >> apparent reason by using the following template:
> > >>
> > >>
> > >>
> http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here
> > >>
> > >>
> > >> You must understand that the attacker doesn't need to have write
> > >> access to the specified PDF document. In order to get an XSS vector
> > >> working you need to have a PDF file hosted on the target and that's
> > >> all about it. The rest is just a matter of your abilities and desires.
> > >>
> > > Amazing, and kudos to Sven Vetsch who found this.
> > >
> > Oops, seems that the credit went to the wrong guy. Actual credit go to
> > Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS
> > Analysis) and Elia Florio (Poc and Code Execution analysis).
> >
> > BTW, one way to mitigate this is for the server, upon receiving a
> > request to file.pdf (without a valid query+cookie pair, see below), to
> > redirect it to file.pdf?token_query=X (where X is an unpredictable, high
> > entropy string) accompanied with a Set-Cookie header for a cookie named
> > say "token_cookie" with value X and short expiration period ( e.g. 10
> > seconds). The browser will then respond with a request to
> > file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the
> > server receives token_query==token_cookie, the server knows this is a
> > legit request (i.e. without fragment), and it can safely serve the PDF
> > resource.
> >
> > I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI
> > filters.
> >
> > -Amit
> >
> >
> ----------------------------------------------------------------------------
> > The Web Security Mailing List:
> > http://www.webappsec.org/lists/websecurity/
> >
> > The Web Security Mailing List Archives:
> > http://www.webappsec.org/lists/websecurity/archive/
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> >
>
>


-- 
pdp (architect) | petko d. petkov
http://www.gnucitizen.org