In the past couple of days I’ve been working heavily on the XSS book which is coming out very soon. I’ve been also involved with several projects which were released in the GNUCITIZEN Projects area.
First of all, let’s see what is happening on the client-side web hacking front-line. It is possible to steal the browser history by using an approach quite different from what Jeremiah Grossman came up with last year. I am making use of script tags together with about:cache protocol leeks. This works on Firefox 2.0.0.2 which means that if this is what you are using right now, you are most definitely vulnerable.
I couple of days latter, RSnake published his own History scanning technique which does not use JavaScript at all. Neat! This technique makes use of Jeremiah Grossman’s methodology plus a conditional CSS trick to reveal links that has been visited. Although, Firefox users who have the SafeHistory extension installed are secured against this type of attack, RSnake’s implementation is the lightest approach I have seen so far. I decide to improve upon his POC and construct a generic NoScript History Scanner which you can read about it here.
Meanwhile, PDF files have suddenly become bad again. It seams that attackers can use PDF to launch file: URLs from the local context.
Depending on the situation this issue could be outlined as critical or less critical (medium or even low risk). It is critical in situations where organizations are attacked with a series of emails with PDF attachments sent to key individuals. It is easy to fake an email and it is even easier to make someone read a PDF document. PDF documents are considered quite secure mechanism for exchanging business information as you already know. As soon as the victim clicks on the PDF attachment, the email application will store it inside a temporary folder on the local disk and execute it from there. Because locally accessed PDF documents can open file: protocol URLs, they can call themselves but this time supplying parameters to the URL to cause an exploitable XSS condition as it was found with Adobe Reader versions prior 7.9. Universal XSS in PDF on a file: locations grants permission to malicious JavaScript objects to access the file system and as such steal confidential information. This is quite bad. Of course, the same situation applies to PDF documents downloaded from the WEB.
It is also possible to steal the current user name, which is not that big of a deal. However, if attackers are interested to penetrate a VPN solution for example, knowing about the first part of the required credentials is a big step forward. From a personal experience, I can tell you that many VPN solutions can be penetrated with a few password/username guesses.
Last but not least, opening file: URLs is not a good idea in general. Anything opened from the local file system has higher privileges. In several steps, attackers can plant key objects on the file system by using various caching mechanisms and launch an attack whit a single PDF document. This is quite hard to achieve but it is not impossible. It is definitely a challenge for inexperienced attackers, but do not underestimate the actual potentials when this issues is used as part of the corporate espionage practices in the wild.
I would recommend that Adobe patches these issues although it is required to close particular PDF functionalities which may come quite handy in many situations. There is a high chance to see PDF viral epidemic developing across the Internet. I am almost certain that this wont happen in the next three months so there is still time to tackle the problem.
Let’s have a talk now.
