Just in case you haven't noticed yet: On November the 25th the first OWASP Germany Conference will take place in Frankfurt. It will be a one-day (mostly) two-track event organized by the German chapter. The program looks pretty great. I am especially curious to see fukami's new talk. Furthermore, [shameless plug] Jeremias and I will give a presentation on our XSS detection work (featuring noXSS and XSSDS). So if you are free on that day, come and join the fun.

I am traveling this week. First I will attend the OWASP Europe conference in Ghent to give a talk with Moritz on our static-analysis-evaluation-project. Then on Friday I will fly from Bruessels to Berlin for ph-neutral. If one of the three readers of this blog is at one of these events, let me know so that we can hang out and talk web sec.

We just released a new version of LocalRodeo, our little anti-JavaScript-malware Firefox extension.

Release notes:

• Fixes for some issues found by Stefan Esser and RSnake (thank you).
• Better UI to (de)activate the extension.
• Notifications through the JavaScript console.
• Debug-mode. If the debug checkbox is activated, Firefox will print verbose debug messages to the commandline-console that was used to start the browser.

So, if you are interested please take LocalRodeo for a testdrive and let us know if anything breaks.

After contributing to show how to break things, it is about time to start fixing things: Justus Winter and I are happy to present the first (beta) version of LocalRodeo, a Firefox extension that aims to protect against attacks which lately have been summarized under the term JavaScript Malware.

LocalRodeo specifically counters two attack vectors:

• Intranet Exploration (i.e. JavaScript portscanning and fingerprinting): The extension classifies all network locations to be either local or external, with local locations being part of the intranet. All http requests that have an external origin (i.e. were generated within the execution context of an external webpage) and a local target (i.e. an intranet resource) are canceled by LocalRodeo.
• Anti DNS-Pinning: LocalRodeo detects this attack method by monitoring DNS answers. The switch of a given domain from external to local (or vice versa) is a clear indication of an anti-pinning attack. If such a switch is detected, all further requests from or to the malicious domain are prohibbited.

If you feel like it, please take the extension for a testdrive and let us know if anything went wrong. Enjoy.

Due to problems at my provider, the LocalRodeo webpage can't be reached temporarily. I hope that problem will we solved in the next hours. Here is an replacement site. (problem solved)

As the JavaVM employs its own DNS-pinning, Java applets are in general unaffected by anti DNS-pinning attacks. However, Kanatoko and I recently came up with a method that enables the usage Java code in anti DNS-pinning attacks anyway (at least in Firefox and Opera).

The JavaScript-engines of the Firefox and Opera browsers offer a nice interface to Java classes: The LiveConnect feature of JavaScript 1.5, which allows to instantiate and access objects from the JDK. For example a Java socket can be opened this way:

var Socket = new java.net.Socket(host,port);

It turns out that if such a JavaScript-to-Java call is executed after the DNS-pinning has been broken, the JVM uses the newly assigned DNS entry (now pointing to an intranet host). While it is probably not as powerful as using arbitrary Java applets, this method still expands the means of an anti-pinning attack significantly (especially if the attacked browser does not allow Flash). Check out Kanatoko's demo that uses the Java socket class to do a low level portscan.

It is about time for the browser vendors to start getting active in respect to anti-pinning issues.

After discovering that accessing a closed port is sufficient to cause most web browsers to drop their DNS-pinning, Kanatoko Anvil worked further to refine my anti DNS-pinning technique: If a browser drops the pinned DNS mapping for a certain domain, it does not only affect JavaScript but also Flash objects. This way same-origin restriction for the low level socket functions of Action Script 3.0 can be circumvented, effectively allowing binary network connections with arbitrary hosts. Check out his demo. Now it seems only a matter of time until somebody ports Nmap to run in a Flash applet. Quite scary.

Update: Flash does not even pin DNS (!). All it takes is a short-lived DNS entry. It is still 1996 for Adobe.

At the 23C3 Stefano Di Paola and Giorgio Fedon from OWASP Italy gave a talk on various methods to undermine the security of AJAX applications. Part of their presentation was the disclosure of an universal XSS (UXSS) problem with Adobe Acrobat reader in connection with Firefox: Acrobat reader supports "open parameter", a method to pass additional display information to a pdf that is served from a web server (e.g. to autofill some forms). Some of these parameters accept general URLs as input. In such a case the reader plug-in request the given URL and uses the received data to determine how the pdf should be displayed:

http://site.com/info.pdf#XML=http://othersite.com/formfill

But if a javascript:-URL is used as part of the pdf's URL, Firefox executes this javascript in the context of the domain the pdf was received from:

http://site.com/info.pdf#XML=javascript:alert("document.cookie");

This results in creating a XSS problem in every single web application that host at least one pdf-file and that is accessed by a Firefox/Acrobat Reader combination (so approx. 10% of all browsers). Autsch.

Here ar some links for further information:

• The original advisory.
• The issue is also explained in Stefano's and Giorgio's 23C3 paper.
• Sven Vetsch and pdp have some PoC code.
• Adobe's open parameter documentation.

Adobe patched the problem with Acrobat Reader version 8.0.

Lessons learned:

This issue is an excellent example how third party add-ons can undermine the security of otherwise well audited web applications (like my finding on Greasemonkey scripts with the difference that the install-base of Acrobat Reader is a lot (!) bigger that the number of people using Greasemonkey).

Therefore, one advice to all developer and owner of web applications: All content that you serve from your application that is interpreted by a third party browser add-on may be subject to client-side XSS problems. As the cause for these problems lies within the browser add-on, there is few that can be done on the server side. For this reason all static non-html content (like pdfs, swfs, ...) should be served from a separate subdomain (e.g. pdf.site.com). If a client-side UXSS exists, only this subdomain is affected and the main application (hosted on www.site.com) is still safe.

An interesting side note: When i talked to Stefano and Giorgio at the 23C3 congress, it seemed as if they were under the impression that this was only a minor discovery compared to the memory corruption vulnerability they found in Acrobat reader. While this is somewhat true, their other discovery could lead to complete owning of the victim's computer, a UXSS in that magnitude simply was not discovered in the wild before. Cudos guys.

Update: It turned out that by accessing a pdf file from the local harddisc via the file:// protocol specifier, the attacker can also execute JavaScript inn the security context of the local computer, thus allowing the JavaScript access to private resources like e.g., local files.