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: Mon, 8 Jan 2007 08:35:52 -0800 (PST)
From: RSnake <>
To: Amit Klein <>
	Web Security <>
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 that points
to (Cathy's IP).
2) Cathy uses an XMLHTTPRequest to tell Alice's browser to visit in a few seconds and times out the DNS entry immediatly.
3) Alice's browser connects to but Cathy has shut down
the port.  The browser DNS pinning no longer points to
and instead it asks Cathy's bind server where the new IP of is.
4) Cathy's bind server now points to (Bob's server).
5) Alice's browser now connects to and reads the token
from that page (cookie, redirect, or whatever) via XMLHTTPRequest and
forwards that information to Cathy's other website
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
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?


Powered by blists - more mailing lists