It's a shampoo world anyway

OWASP Germany Conference

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.

... Link

Travel ahead

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.

... Link

New LocalRodeo Version

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.

... Link

LocalRodeo - Client-side protection against JavaScript Malware

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)

... Link

Using Java in anti DNS-pinning attacks (Firefox and Opera)

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,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.

... Link

Anti DNS-pinning revisited

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.

... Link

Browser add-on security (Part II): XSSed by Acrobat Reader

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:

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:");

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:

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. If a client-side UXSS exists, only this subdomain is affected and the main application (hosted on 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.

... Link

online for 6728 Days
last updated: 09.04.14 16:14
Youre not logged in ... Login
... home
... topics

... antville home

April 2020
the shampoo world is
the personal weblog of Martin Johns.

xml version of this page

Made with Antville
powered by
Helma Object Publisher

...welcome to the long tail...