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
| ||
|
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