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.htm
l
http://jeremiahgrossman.blogspot.com/2006/12/i-know-if-youre-logged-in-a
nywhere.html
http://www.gnucitizen.org/blog/google-search-api-worms
http://www.gnucitizen.org/projects/attackapi
On 1/3/07, James Landis <jcl24 (at) cornell (dot) edu [email concealed]> 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 (at) gmail (dot) com [email concealed]> 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
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.htm
l
http://jeremiahgrossman.blogspot.com/2006/12/i-know-if-youre-logged-in-a
nywhere.html
http://www.gnucitizen.org/blog/google-search-api-worms
http://www.gnucitizen.org/projects/attackapi
On 1/3/07, James Landis <jcl24 (at) cornell (dot) edu [email concealed]> 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 (at) gmail (dot) com [email concealed]> 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
[ reply ]