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]
Message-ID: <Pine.LNX.4.64.0701080835450.27722@fingers.shocking.com>
Date: Mon, 8 Jan 2007 08:35:52 -0800 (PST)
From: RSnake <rsnake@...cking.com>
To: Amit Klein <aksecurity@...il.com>
Cc: bugtraq@...urityfocus.com,
	Web Security <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

> The point is - someone with shared IP is vulnerable ONLY to an attacker with 
> the same IP. Which makes attacks much less generic and much more painful. 
> Rock solid it ain't, but I think it's a pretty good band-aid until all 
> (hmmm...) clients upgrade to Acrobat Reader 8.0.
>
> -Amit

Sorry for responding late, I've been doing some consulting work.

After talking with some people on my blog I don't believe that is the
case (at least not in theory).  Let's say Alice has an account with
Bob's website.  Cathy is an attacker who owns a website that uses
anti-DNS pinning.  Cathy wants Alice's credentials from Bob's website.

1) Alice visit's Cathy's malicious website www.whatever.com that points
to 123.123.123.123 (Cathy's IP).
2) Cathy uses an XMLHTTPRequest to tell Alice's browser to visit
www.whatever.com in a few seconds and times out the DNS entry immediatly.
3) Alice's browser connects to www.malicious.com but Cathy has shut down
the port.  The browser DNS pinning no longer points to 123.123.123.123
and instead it asks Cathy's bind server where the new IP of
www.whatever.com is.
4) Cathy's bind server now points to 222.222.222.222 (Bob's server).
5) Alice's browser now connects to 222.222.222.222 and reads the token
from that page (cookie, redirect, or whatever) via XMLHTTPRequest and
forwards that information to Cathy's other website www2.malicious.com.
6) Cathy reads Alice's token and then forwards Alice's browser to Bob's
server (not the IP, but the actual address) with Alice's token (if the
token is a cookie we can use the Flash header forging trick).  Alice's
cookie is not yet compromised because she is looking at a different
website, and her browser does not send the cookie, yet.
7) Alice's connects to Bob's server with the PDF anchor tag and the
correct token to view the PDF.  Since the token is bound by IP the token
works.
8) Alice executes Cathy's malicious JavaScript malware in the context of
Bob's web server.

It's ugly, but it should work, in theory.  Clear as mud?

-RSnake
http://ha.ckers.org
http://sla.ckers.org/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ