It's a shampoo world anyway

The grand Hillbilly Bank Robbery

Maddin — Mon, 11 Dec 2006 10:15:55 GMT

Last Friday a team from our research group (“the CInsects”) participated at the annual iCTF, a Capture the Flag contest held UCSB. As always it was a blast.

The contest itself was somewhat different than the Ctfs we played before. It was a “capture the flag” without any flags. Instead every team had to run and secure a very, very buggy online bank. The goal was to keep as much of your own money as possible and to increase that amount by hacking the other banks to transfer their funds to your account.

We finished the game on a solid 6th position (out of 25). I was no big help to my team though, as I had to watch my son most of the night and could therefore only temporary help robbing the other banks. At least I solved on of the side quests, that were posted during the game to win some bonus money. My biggest regret is that I was not there, when they shot the video.

NoScript now includes LocalRodeo-like functionality

Maddin — Tue, 30 Jun 2009 09:45:30 GMT

Giorgio Maone just announced that NoScript now includes ABE (a framework for CSRF protection) by default. Among others, ABE contains rules which enforce LocalRodeo's intranet protection functionality. Also, Mozilla has apparently finally fixed Firefox's DNS rebinding issues with the release of 3.5 (at least Kanatoko's testcase fails now). Hence, if you are already a NoScript user, there should currently be no need for additionally installing LocalRodeo.

OWASP Germany Conference

Maddin — Tue, 21 Oct 2008 15:41:46 GMT

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.

LocalRodeo (beta) for Firefox 3

Maddin — Wed, 10 Sep 2008 11:56:17 GMT

People that follow me on Twitter probably already noticed: I have started to work on LocalRodeo again. The old version of the extension broke on Firefox 3 and fixing took longer then expected. However, better late then never, finally a FF3 compatible version is available.

I will not use the legacy extension's auto-update functionality until I am positive that the recent changes won't affect people still using Firefox 2. Therefore, please refer to this page to get a current version for Firefox 3 (and send us feedback).

Travel ahead

Maddin — Mon, 19 May 2008 14:35:26 GMT

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.

DeepSec 2007 Roundup

Maddin — Thu, 29 Nov 2007 16:05:13 GMT

Last friday I had the honour of giving a talk at DeepSec2007 in Vienna. Due to other obligations I unfortunately could only attend the final day of the conference.

The day started with a keynote presentation by Jeff Moss, the founder of BlackHat. He gave a really entertaining talk on responsible disclosure using the Mike Lynn/ISS/CISCO-debacle of 2005 as an example. Jeff was followed by Halvar Flake who talked about (semi-)automatic malware classification using his tool BinDiff. BinDiff looks fantastic. I am always intrigued by tools that combine clever algorithms with a good looking and usable GUI. While I don't necessary completely agree with Halvar's assessment why his technique is significantly better than the competing approaches, I learned a lot from his presentation. Then I had to to some last minute refinements on my slides and meet some people, therefore I skipped most of the trailing presentations.

The next talk I attended was my own, which went fine. Once again (a probably for the last time) I presented on CSRF. This time I skipped most parts concerning our protection mechanisms and concentrated more on the various exploiting aspects using real life examples and demoing Justus's CSRF-exploit-o-mat, which allows the automatic creation of a working exploit in less the 5 seconds. I got some good questions and had a couple of nice conversations in the hallway.

The conference ended for me with Melanie Rieback's presentation on RFIDGuardian. The RFIDGuardian is a small wearable appliance which is able to intercept, alter, or block communication between RFID-readers and RFID-tags (e.g., your passport, tags in your clothing, or tags you didn't even know you had). The appropriate action which the guardian should execute can be selected on a per tag basis, thus allowing a rather fine-grained control. The feature I liked the most is, that the tool provides auditing/logging capabilities which enable the user to exactly establish when and where somebody tried to access RFID-tags during the day. Right now, only prototypes exist but Melanie's research group is trying to get some funding for mass production, which would result in a possible end-consumer price around 200 €. As all the basic information (software, hardware design) is open and free (GPL, CC) it is also possible to build your own device at home, provided you have a soldering iron and know what you are doing ( a note to my stundents: If anybody wants to do this as a part of his master's thesis, drop me a line).

In the evening fukami, Stefan Esser, and I attended Monochrome's fantastically entertaining Taugshow. The show's talk-guests on stage were (among others) Cory Doctorow, Tim Pritlove and Jeff Moss. The secret highlight of the show was a friendly american who almost chocked when he was trying to eat a dollar-bill (which he did to support the US economy).

In summary, DeepSec was a very pleasant and inspiring experience. My only regret is that my time was to limited so that I missed the first day and neither had the time to check out the Meta-Lab nor visit the Roböexotica-event.

Why I do not like taint tracking

Maddin — Wed, 19 Sep 2007 13:31:06 GMT

While I was giving a talk yesterday on our dynamic and language based approaches concerning the avoidance of code injection vulnerabilities at Laboratory for Dependable Distributed System at the University of Mannheim, I came up with a nice description, why I dislike dynamic taint tracking:

Preventing code injection exploits using dynamic taint tracking is like letting a thief in your house and checking his bag for stolen goods at the very moment he tries to leave. It might work, but only if you never lose track of the gangster and if you really know your house. However, I would prefer a solution that does not let thieves in my house in the first place.

(Nonetheless, I think taint tracking obviously has a valid place in the defender's arsenal)

DNS rebinding at CCS'07

Maddin — Thu, 09 Aug 2007 10:47:14 GMT

This year's ACM conference on Computer and Communication Security (CCS) features two excellent papers on DNS Rebinding (the attack formerly known as "anti-DNS-pinning").

Besides discussing DNS rebinding for firewall circumvention, Protecting Browsers from DNS Rebinding Attacks by Jackson et al. also covers DNS-rebinding-based IP-hijacking, which can be used to commit click-fraud (an malicious application of the attack I have not thought of before). Furthermore, the authors propose a couple of defensive strategies, of which two have especially caught my attention:

To protect a given intranet, they propose a firewall solution. This special firewall specifically filters DNS traffic and denies DNS resolution of external hostnames to internal IP addresses. A nice idea that is easy to deploy within a company network.
Furthermore, they suggest to alter the web browser's pinning strategy from strict IP-pinning to class C-pinning. This means DNS rebinding within the same /24 range is permitted. Such a policy would allow using DNS-Rebinding for load-balancing and failure recovery while preventing the discussed attacks. This is a better policy as we enforce in LocalRodeo - it prevents the intranet-targeted attacks as well as we do but also counters IP-hijacking. For allowing dynamic-DNS restricting the IP changes to class C is probably to strict though.

Dynamic Pharming Attacks and the Locked Same-Origin Policies for Web Browser by Karlof et al. shows how pharming attacks can employ DNS-rebinding to subvert strong authentication mechanisms like client-side SSL (another malicious application I had not thought of before). To counter this threat the propose a "locked same-origin policy" that does not only take domain, port, and protocol into consideration but also requires that the private keys of the web page's respective SSL-certs match (an approach that obviously only works for web pages served via https).

I think this solution is a pointer in the right direction. Making the security properties of a web application depended on something that is not directly controlled by the application itself (DNS) was a bad idea in the first place. In the future we should work replacing this policy by something more appropriate and fine-grained.

Update: Giorgio Maone announced that the next major version of NoScript will include the stanford paper's "same subnet" anti-rebinding policy (both in IPV4 and IPV6).

CfP: NordSec 2007 - The 12th Nordic Workshop on Secure IT Systems

Maddin — Fri, 15 Jun 2007 19:36:42 GMT

The 2nd Call for Paper for the 12th Nordic Workshop on Secure IT Systems (NordSec 2007) has been published a while ago. I am very proud to be one of the members of the program committee and would love to see many submissions to the workshop.

Important dates:

Paper submissions due: 23 July
Notification to authors: 10 September
Final papers due: 24 September

The workshop will be held from October 11 - 12 2007 in Reykjavik, Iceland

About NordSec

NordSec 2007 is organized by Reykjavik University, in Iceland, with a specialfocus on Language-based Techniques in Security. Since 1996, the NordSecworkshops have brought together computer security researchers andpractitioners from the Nordic countries, Northern Europe, and elsewhere. Theworkshop has an emphasis on applied computer security and is intended toencourage interaction between academic and industrial research.

Confirmed invited speakers are:

Cedric Fournet, Microsoft Research, Cambridge, UK
Greg Morrisett, Harvard University, Cambridge, USA

The workshop is linked to a special issue of the Journal of Logic andAlgebraic Programming. Authors of selected technical papers may be invitedto submit revised versions for consideration in this special issue.

For a list of applicable topics please refer to the CfP webpage.

A special focus of the 2007 NordSec workshop are Language-based Techniquesin computer security and their applications; papers and extended abstractson this topic are especially welcome. Students, researchers, and industryprofessionals working in this area are encouraged to submit to the workshop.

2nd Rule: You do blog about Bar Camp

Maddin — Tue, 12 Jun 2007 08:25:53 GMT

I attended the first BarCamp in Hamburg which took place last weekend. The lack of technical content was somewhat disappointing to me. However, the content of a BarCamp is a reflection of the interests of the attendee so I am not complaining. The Hamburg crowd seems to be hungry for business, as most sessions revolved around starting companies, getting users or making money.

I gave a short session on web security with a focus on issues that may arise due to the specific characteristics of the web2.0. While I had comparatively few participants we still had a nice and rewarding discussion.

New LocalRodeo Version

Maddin — Wed, 18 Apr 2007 15:21:20 GMT

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.

The state of hacking SessionSafe

Maddin — Thu, 05 Apr 2007 15:04:13 GMT

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.

Heading towards ACM SAC'07

Maddin — Thu, 08 Mar 2007 12:59:14 GMT

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.

Paper: SessionSafe - Implementing XSS Immune Session Handling

Maddin — Mon, 05 Mar 2007 15:46:28 GMT

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.

LocalRodeo - Client-side protection against JavaScript Malware

Maddin — Mon, 19 Feb 2007 11:28:01 GMT

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)

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

Maddin — Sun, 04 Feb 2007 20:38:54 GMT

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.

Anti DNS-pinning revisited

Maddin — Fri, 12 Jan 2007 14:24:47 GMT

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.

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

Maddin — Thu, 04 Jan 2007 10:19:23 GMT

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.

Outdated advisory: Code injection via CSRF in Wordpress < 2.03

Maddin — Tue, 02 Jan 2007 15:34:02 GMT

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.

(somewhat) breaking the same-origin policy by undermining dns-pinning

Maddin — Mon, 14 Aug 2006 15:42:44 GMT

A small contribution to the current “hacking the intranet with JavaScript” meme:

Introduction

J. Grossman, RSnake, SPI Dynamics, pdp and others have demonstrated lately that it is possible for a malicious JavaScripta) to obtain the (internal) IP address of the hosting web browser,b) to portscan the lan to locate intranet http servers,c) to fingerprint these http servers using well known URLsd) and (sometimes) to exploiting them via CSRF.

During my research on that topic I discovered, that with some tweaking, it is also possible for the script to obtain read access, allowing the leakage of internal information and more precise fingerprinting.

Technical background

The basis of the attack is rather old. It was described by the Princeton University in 1996 [1] and was recently brought to my attention by Amit Klein [3]. For the attack to succeed the attacker needs to control the DNS entry for his web server (www.attacker.org in the following example).

Attacking an intranet host located at 10.10.10.10 would roughly work like this:

The victim downloads a malicious script from www.attacker.org
After the script has been downloaded, the attacker modifies the DNS answer for www.attacker.org to 10.10.10.10
The malicious script requests a web page from www.attacker.org (e.g via loading it into an iframe)
The web browser again does a DNS lookup request for www.attacker.org, now resolving to the intranet host at 10.10.10.10
The web browser assumes that the domain values of the malicious script and the intranet server match, at therefore grants the script unlimited access to the intranet server.

To prevent this type of attack, modern web browsers implement “DNS Pinning” - DNS lookup results are kept unchanged for the entire browser session, even though the DNS entry’s lifetime may be shorter. Mohammad A. Haque describes in [2] how the attack method still can work, providing that the malicious script survives in the browser cache. The described scenario requires the victim to quit his web browser and to access the malicious script a second time, which renders the attack to be somewhat unlikely.

The refined attack: Undermining DNS pinning by rejecting connections

As it turns out, it is also possible to force the browser to renew the DNS entry for a given domain “on the fly”. The following sequence of events worked for me (tested on IE6 xpsp2 and Firefox 1.5.0.6):

The victim loads the script from www.attacker.org.
The attacker changes the DNS entry of www.attacker.org to 10.10.10.10
Further more the attacker quits the web server that was running on www.attacker.org’s original IP
The script uses a timed event (setIntervall or setTimeout) to load a web page from www.attacker.org
The web browser tries to connect to the IP which is bound to www.attacker.org from the previous request. As the web server there is shut down now, this connection attempt is rejected.
Because of this (and probably because of the DNS entry’s short lifetime), the browser drops the DNS pinning and does a new DNS lookup request, resulting in 10.10.10.10 (sometimes it takes more than one loading attempt to trigger the lookup request).
The script is now able to access the intranet server’s content and to leak it to the outside.

Some (crude) PoC code is available at polyboy.net

I successfully tested the described approach on two different computers in two different networks. Still the result is purely experimental. As I have not read the web browser’s source code, I can only guess why the attack works. For this reason it may be possible, that the attack fails on different setups.

Outlook

This technique obviously can be automated. Instead of quitting the web server on attacker.org completely, dynamic firewall rules could be used to reject further connections from the victim’s IP after the initial script was delivered.

The attack only woks, if the attacked server does not check the http host property, as this property would still be “www.attacker.org”. For the same reasons all virtual hosts are out of the attacker’s reach.

Update (12/2006): Kanatoko Anvil from jumperz.net found out that it is not necessary to shut down the web server. It is sufficient for the malicious script to access a closed port on the intranet server (e.g. attacker.org:81) to cause the web browser to initiate a new DNS query. See here for a demo. Wow.

References

[1] DNS Attack Scenario, www.cs.princeton.edu[2] Josh Soref: DNS: Spoofing and Pinning, viper.haque.net[3] Amit Klein: Re: Detecting, Analyzing, and Exploiting Intranet Applications using JavaScript (Posting to the WebAppSec-Mailinglist), www.webappsec.org

Using eval() in Greasemonkey scripts considered harmful

Maddin — Tue, 26 Dec 2006 14:07:51 GMT

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];

These values are used in an eval() to create a new global variable:

eval("var " + emailUrlVarName + " = 'https://mail.google.com/mail?view=cm&tf=0" + (emailTo ... );

As there is no intermediate filtering step, injecting code into this eval is rather simple:

<a mailto="me@th)';your_js_code_here;//>name</a>

If a Firefox with the according userscript installed displays a webpage that contains such a mailto-link, the browser executes the injected JavaScript in the domain of the displayed webpage. Therefore the Greasemonkey-script creates a XSS-problem in all web applications that allow users to create arbitrary mailto-links (as e.g. the default installation of Wordpress does). Go here for a demo. Furthermore, these scripts are executed in the Greasemonkey domain, thus are allowed additional privileges like cross-domain XMLHttpRequests.

I don't consider this issue to be grave or critical. I don't expect the install-base of this particular userscript to be big enough to actually cause any exploitation. Nonetheless I think it is a good example how browser add-ons can create XSS-problems in web apps that are secure themselves.

Request Rodeo released Maddin — Fri, 08 Dec 2006 08:58:57 GMT Justus and I finally found the time and patience to decide on a hosting option for our client-side anti-CSRF proxy. From now on, we will maintain RequestRodeo on nongnu.org. There are still open issues to implement and rough edges to smooth (cough HTML parser cough). So if you care about CSRF and/or are a Python enthusiast – hop on board. It is called open source for a reason. Back form PacSec Maddin — Wed, 06 Dec 2006 15:35:20 GMT Well, I am back in Hamburg again. The days in Tokyo were a blast. The city is as overwhelming as I imagined it to be. PacSec itself was great as well. I saw many intriguing talks and met tons of cool people. There was not much content that directly related to my area of research (mine was the only websec talk and, with the exception of Ben Chelf’s presentation of Coverity’s technology, software security was not too dominant as well). Not that this matters as the good thing about going to conferences is that one gets exposed to topics that are not necessarily right up one’s alley. With three talks on the subject, there was quite a focus on IPv6. I especially liked Yuji Ukai presentation on scanning IPv6 networks and fingerprinting v6 network stacks. Arnaud Ebalard and Guillaume Valadon talk on mobile IP was also very cool, but I only did understand about one third of what they were explaining. So many abbreviations, so little time. Fortunately their live demo of a mobile IPSec tunnel helped to get the big picture.Another focus was on Microsoft and Microsoft related technologies. All Microsoft guys were experienced and professional speakers that managed to avoid the obvious traps of vendor talks. Furthermore, Philippe Lagadec taught us about the pitfalls in the new office XML formats and Marc Schoenefeld gave a first introduction on possible future issues with Mircosoft WCF.As usual, the lightning-talks were my favourite part of the event. Fast, chaotic, entertaining. I wish the time would have allowed a few more (the interpreters had to leave punctual). In one of the breaks, I got the chance to talk to Window Snyder (Mozilla Corp.'s Chief Security Foo). I tried to convince her that the topics I am working on (JS malware, CSRF, XSS exploitation, etc.) are the most pressing issues right now and that the http/browser paradigm needs a thorough overhaul urgently. However I got the subtle impression that she did not quite agree. Too bad. If you are interested to get a visual impression, visit the flickr account of Ryo, the conference’s official photographer. I also made a couple of pictures but they are mostly boring tourist shots of Tokyo. Going to PacSec Maddin — Thu, 23 Nov 2006 11:16:51 GMT Wow, tomorrow I will head off to Tokio to talk at PacSec. I have to remember to send the inventors of http a "thank you"-postcard. If they wouldn't have made http stateless, nobody would pay me a flight to Japan. Entering Bliki Maddin — Fri, 19 May 2006 14:55:48 GMT Igor just finished revamping our NerdAlert webpage - nerdalert.de is know proudly run using a Bliki, a Frankenstein’s monster between a blog and a Wiki. I was sceptical at first because I could not see the advantages over the regular wiki we have used before. Man, was I wrong. I sold now. The Wikipedia as usual has the best explanation: The main advantage of combining the two concepts, however, is in leveraging the utility of wikis at making connections between ideas; this effectively turns blog posts into proper wiki articles, but maintains the former's immediate nature. Thus, a bliki can evolve as a whole over time, and past information is not merely jettisoned into the aether and lost in the shuffle. I think it is a perfect fit for our needs (documenting a monthly radio show and some additional activities). And the webpage looks sooooooo gorgeous now.