Universal PDF XSS After Party
For those who has slept over the last two days, here is a short introduction of what this talk is going to be about:
The Universal PDF XSS issue was discovered by Stefano Di Paola and Giorgio Fedon and it was presented on 23C3 security conference. This vulnerability obviously affects the Adobe Acrobat Reader which is a widely used software among business, non-business organizations and individuals. By abusing Acrobat’s open parameter features well protected sites become vulnerable to Cross-site scripting attacks if they host PDF documents. This is pretty bad and unless you update your reader or change the way your browser handles PDF documents, you may get hacked quite badly. This issue is very serious.
Now we know what we are going to talk about, lets have a look on how attackers can use this vulnerability to abuse your WEB presence.
First of all it will be good to mention that PDF is widely used document format. In fact, every major site (I don’t want to say every site, although I wont be far from the truth) hosts at least one PDF document. This makes the situation a lot worse because If you happen to be on a malicious site or you click a malicious link, attackers can simultaneously compromise several of your WEB accounts that are currently open/authenticated.
I mentioned that either you have to click on a link or visit a page in order to get the exploit working. In general you need some type of user interaction. First of all, clicking on a link could be a bit suspicious if you think about it. Unless you really want to open a PDF document, there is no need for doing so. However attackers can make use of sneak techniques to force you somehow, by changing the file extension of the PDF document to .mp3 or .mov or even .html. It looks less suspicious, but still when pulled from the server the content will be served as application/pdf:
#.htaccess RewriteEngine On RewriteRule *\.(jpg|png|css|mp3|mov|avi)$ http://www.google.com/librariancenter/downloads/Tips_Tricks_85x11.pdf
If the user clicks on something like the following URL:
the code will be executed on Google not on currentdomain. The user has fallen into the trap. You can see that you should not trust links and your browser status bar because they could say something that is not really the truth.
It is also worth mentioning that there are many variations of this attack vector. In fact, there are so many variations that its not worth discussing all of them. However, here is another interesting one. I presume you are already familiar with TinyURL. In simple words, attackers can store an entire XSS vector for a specific site and recall it anytime they need it by using the TinyURL service. I shrunk the following URL which contains harmless XSS exploit for Google:
TinyURL generated the following shortened URL:
If you paste the above URL into your browser address bar you should get an alert message saying XSS. The ability for shrinking and obfuscating URLs with TinyURL and other technologies makes the Universal PDF XSS a pure evil. URLs are easily exchangeable via simple text messages, emails and IM chat sessions. The impact is huge.
The second way for getting the exploit working is by automatically opening it without user interaction, although the user needs to attend a malicious resource first. In order to make the vector working the attacker sets a hidden iframe that contains the malicious URL. Upon visit, the exploit executes.
I mentioned that TinyURL can contain the entire XSS attack vector. Then you can easily execute it like this:
<iframe src="http://tinyurl.com/t8h4q" style="width:0;height:0;border:0"></iframe>
This is very bad because attackers can have multiple iframes in a single page that upon visit will exploit whatever WEB accounts you currently have open. It is totally stealth and extremely malicious.
Probably you are thinking that this can be used quite successfully to create a WEB worm infection. It is true! Obviously it is possible. A WEB worm of such a degree will be the first one that spreads on the top of the WEB without the restrictions introduced by the same origin security policy. The infection process can be very simple if you think about it. First of all the worm needs to have some kind of mechanism for discovering potential target. Google proves to be quite helpful with that. In this case either Google AJAX Search API (restricted) will be used or a hosted PDF document to do real Google searches on the main WEB Search interface (unrestricted). Once the worm finds a target, the infection algorithm is launched. Upon visit of a infected resource propagation process restarts.
The Universal PDF XSS is probably one of the worst things that has happened to the web. This vulnerability affects almost every website. Here is another news for you: your local file system is subjected to external attacks as well.
You can see that the above URL is accessed with the file protocol. This means that we have access to other resources served by the same protocol. For more information how to access the file system, read the current user history file, dump the registry, download the SAM file or access other sensitive information read here and here.
This is why the situation is very bad not only for Adobe but also for the users and the security community. I did investigation to see what is the situation with most Social Networks that I know about. Almost all of them have PDF files. I wonder what will be next.