It has been a month or so since I wrote about SessionSafe. To my delight a couple of people have taken an interest in the matter. Here is a short summary of the various discussions:

Deferred Loading

There was not a lot of controversy about this topic. Only Wladimir Palant made some suggestions how to streamline the implementation. Anyway, as Firefox is about to implement http-only cookies the need for Deferred Loading slowly vanishes (with Deferred Loading mainly being a http-only implementation for browsers that does not support it natively).

Subdomain Switching

In the original blog entry and in the ph-neutral presentation I hinted that I considered the combination of Deferred Loading and Subdomain Switching to be sufficiently secure. Kuzza55 brought to my attention that by using anti-dns-pinning and subsequently spoofing the host header with either XHR or the low level socket functions some of the protection provided by Subdomain Switching can be bypassed (as the authentication cookie for secure.domain.tld can be sent by the attacker). Therefore, as long not all browsers support http-only cookies and anti-pinning is still an option, we need one-time URLs.

Besides this, I still consider Subdomain Switching a powerful tool to mitigate the effects of malicious XSS.

One-Time URLs

As I expected, most feedback revolved around the JavaScript trickery that is necessary to hide the random nonces from malicious XSS. At some point during the discussion I posted my old PoC which spurred even more hacking attempts. It started out with a watch/unwatch--problem that Kuzza55 found, closely followed by possible caching issues. Then Kishor found a silly coding mistake of mine in the PoC. This was succeeded by a IE and Opera specific technique that required to overwrite the document-object found by kazuho, who also found two additional problems.

Fortunately all of these issues are avoidable and resolved in the PoC. As long as references to all vital resources are kept by the Randomizer in a tamper proof local copy and all values passed to the go()-function are examined carefully, the one-time-URL concept itself is still feasible. However due to the highly dynamic nature of JavaScript, nobody can foresee wether there are more sneaky ways to trick the Randomizer. I think kazuho summed it up the best:

Although I agree that it might theoretically be possible to hide a link from XSS, I wonder if its practically possible.

Various bits

During the ongoing work of fixing the PoC, I learned some new aspects of JavaScript:

• Right now, all browser's JS implementations are single threaded. This means a running JS is never interrupted by second script (e.g., because of the triggering of an event). This comes in handy, as race condition based issues are not possible. This also explains the glaring absence of locks/semaphores and related language tools in JS. I do not know if this standardized or if the JS-interpreters behave that way just because the browser's developers could not be bothered to write threading coder. If anyone knows something more precise I would like to learn about it.
• Internet Explorer acts strangely when it comes to redefining certain global objects. If in a single <script>-block the document-element is overwritten it is set to "undefined" even before the redefining instruction is executed. Try this in IE:

  alert(document); var document = "foo bar"; alert(document);

  Usually alert(document); results in "[object]" but in this case the first alert results in "undefined". This leaves my kind of puzzled.

Tomorrow I'll leave Germany to attend the ACM SAC 2007 conference which takes place in Seoul/Korea this year. I will present our work on transparently countering code injection attacks via approximating data/code separation in String values.

In the unlikely event that one of the readers of this blog happens to be in Seoul next week or even at the conference - drop me a line and I will buy you a beer.

My SessionSafe-paper is online for quite a while now, but I never found the time to write about it. The paper describes three methods that, if used in combination, allow to protect web applications against session hijacking even in situations when a XSS attack already successfully injected malicious JavaScript code into the application.

           

XSS problems are not always caused by flaws in the web application itself. Instead they may arise due to external factors, like the expect header problem, vulnerable browser extensions (e.g., the Adobe PDF UXSS), or unwise usage of eval() in Greasemonkey-scripts. For this reason such a second line of defence is useful even if an web application is well audited and believed to be secure. The paper was presented at ESORICS 2006 and published in the conference's proceedings.

Abstract (fat free version):

[...] In this paper we classify currently known attack methods to enable the development of countermeasures against [session hijacking]. By close examination of the resulting attack classes, we identify the web application’s characteristics which are responsible for enabling the single attack methods: The availability of session tokens via JavaScript, the pre-knowledge of the application’s URLs and the implicit trust relationship between webpages of same origin. Building on this work we introduce three novel server side techniques to prevent session hijacking attacks. Each proposed countermeasure removes one of the identified prerequisites of the attack classes. SessionSafe, a combination of the proposed methods, protects the web application by removing the fundamental requirements of session hijacking attacks, thus disabling the attacks reliably.

In hindsight I tend to consider the JavaScript based Randomizer object to be the weakest part of the paper as I am not fully convinced that some JavaScript implementation might not provide a non-standard mechanism to either obtain the encapsulated list of nonces or hijack the document.location property. E.g., one of the paper's reviewers warned about an attacker that tries to overwrite the setter-function of the document.location property. While Kuzza55 showed how to counter such an attempt, the whole business still leaves an uneasy feeling. However even the combination of Deferred Loading and Subdomain Switching still provides decent enough protection, as I have discussed in my ph-neutral 0x7d6 presentation. Also implementing the Randomizer object either in Flash or as a Java applet should get rid of my JavaScript worries.

Misc. remarks and updates:

• I have to thank Andre Luerssen. Without him I would not have considered the background-XSS-propagation attack vector.
• Christian Weitendorf implemented the paper's techniques for J2EE as part of his Master's thesis. The thesis is still in review. We are thinking about releasing the code afterwards. Stay tuned.
• Furthermore, after reading the paper, Collin Jackson pointed me to a small but significant error in the paper's example code: Instead of

  nonce = validNonces[path];

  in Listing 1.1 it should better be

  var nonce = validNonces[path];.

  Otherwise the nonce would be stored as a property of the global window object.

A closing remark: The research that did lead to this paper was probably the most fun I yet had in academia.

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.

This issue is rather old, fixed and superseded by more serious code injection problems in Wordpress. But as I never got around to write an advisory and as I did use this vulnerability as an example of a severe CSRF-exploit in my recent talks, I decided to do a short write-up in order to document the issue properly.

Introduction:

The look and feel of a Wordpress weblog is determined by the "theme" of the blog. Such a theme itself consists of a couple of template files. These templates can either be HTML- or PHP-files. To edit these templates Wordpress provides an web interface.

The preparation:

This template editor was not protected against CSRF in Wordpress versions < 2.03. While a couple of functions in the Wordpress admin interface required strict referrer-checking, for some reasons the scripts of the template editor were accessible without providing a valid referrer.

To launch a CSRF exploit the attacker had to know the name of the template file he wants to change and the name of the used theme. Both these informations are in the most cases public, as the majority of Wordpress weblogs use themes that are derived from standard themes that are available to the pubic. Furthermore, if the web server is configured to allow directory listenings, the attacker can get these information by simply accessing the blog's wp-content/themes directory.

With this knowledge the attacker could create a malicious webpage that contains a HTML form with the action POST and the target http://baseurl_of_the_attacked_blog/wp-admin/theme-editor.php and four hidden fields:

• A field called "action" with the value "update",
• a field called "file" with the name of the template file as value,
• a field called "theme" with the name of the theme as value,
• and a field called "newcontent" that contains as value the new HTML/JavaScript/PHP code that the attacker wants to inject into the application.

This form can be contained in e.g. a hidden iFrame and will be submitted via JavaScript whenever anybody accesses the malicious web page.

The attack:

If the attacker succeeds to lure the blog's admin/owner to access the malicious page while being authenticated with the blog, the hidden request that is created by the web page is send within this authentication context admin and is therefore accepted and executed by the blog.

Many CSRF attacks are hard to exploit as the attacked victim has to be logged in the attacked application at the same time the attack is launched. In the case of Wordpress it is rather simple for the attacker to ensure this condition: Many blogs employ comment moderation. Every comment that is submitted to the blog has to be manually approved by the blog's admin before it can appear. Therefore, all the attacker has to do, is to include the link to the malicious page into a comment to one of the blog's articles. To moderate the comment, the blog's admin has to be logged into the admin-interface and to judge if the comment in ok, he should follow all provided links. Peng.

Closing remarks:

As I already wrote in the beginning, the issue is fixed since WP 2.03.

I found this vulnerability in late March 2006 and reported it to the security people at Wordpress immediately. As I became a father a couple of days later, I temporary lost interest in web security. Before I got around to write an advisory and post it to the appropriate places, other people found a more serious code injection issue in WP and publicized it. After this it felt kind of pointless to write the advisory. Nonetheless I considers this issue to be a very good example for the potential damage a CSRF-attack can do - in this case PHP code injection. As CSRF is still frequently underestimated, such an example is useful for raising awareness.

By the way, it took Wordpress quite a long time to fix the issue. One of the reasons for this is, that they decided to drop referrer checks and introduce form-nonces (the right thing to do (tm)). Check out this mailing-list threat to get an impression how clueless many web app developers are when it comes to CSRF.

For some time now, there is a vague assumption in the web-security community that browser add-ons like e.g. Firefox extensions can cause security problems. On my flight back from PacSec, I decided to have a closer look on Greasemonkey scripts. I had already downloaded all available Greasemonkey-scripts from userscripts.org a while ago, but never got around to do anything with them. When I was skimming through the files, I noticed that eval() is used quite frequently. It didn't take long to find a userscript that passes non-sanitized user-provided data to a eval()-statement: Mailto Compose In GMail (with choice).

The userscript parses mailto hyperlinks and creates according compose-links to gmail.com. The parsing is done by a simple regexp:

nameValue = param.match(/([^=]+)=(.*)/);
...
emailTo = emailTo + "%2C%20" + nameValue[2];