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.

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.

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.

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 JavaScript a) 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 URLs d) 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):

1. The victim loads the script from www.attacker.org.
2. The attacker changes the DNS entry of www.attacker.org to 10.10.10.10
3. Further more the attacker quits the web server that was running on www.attacker.org’s original IP
4. The script uses a timed event (setIntervall or setTimeout) to load a web page from www.attacker.org
5. 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.
6. 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).
7. 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

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.

At the end of May I have the honour to present some of my research work. First I will attend PH-Neutral in Berlin and talk a little bit about my results in developing transparent websecurity techniques. Later the same week, I will present our anti CSRF proxy at the OWASP AppSec06 conference in Leuven. Dear reader, if you are attending one these events please let me know, so that we can share experiences and beer at the fireplace.

What a fun night. I met nice people, listened to some enlightening talks, had geeky conversations and drank cold beer. Hamburg’s first Web Montag was quite nice.

Lately, I did some research on “Session Riding” (aka CSRF). As Session Riding is a vulnerability class that is rather unknown, I used the opportunity of this event to raise some attention. I gave a short talk on the subject and showed an unfixed CSRF exploit. Hopefully I didn’t bore my audience to death. Check out my slides here.

See you next (Web) Monday.

There was more than one moment in the last month, in which I wondered about the reasons behind the same-origin restriction on the XMLHttpRequest JavaScript object’s destination URL. This restriction effectively prevents JavaScript initiated cross domain http requests. None of the other network aware elements of HTML/JavaScript are subject to such a policy (e.g. images, iframes or scripts).

Finally somebody convinced me: Lucas Carlson describes in a recent Blog entry how cross domain XMLHttpRequests could be employed to subvert firewall protection. A malicious JavaScript executed by a web browser behind a firewall would be able to communicate the content of any http intranet server, which would otherwise be protected by the firewall, to any host on the internet. Such a script is furthermore able to do a complete port scan on the intranet, thus discovering services and further attack targets.

What a pity, cross domain Ajax would be so much fun otherwise.

...and it is not even a Web 2.0 one.

The Google Duel is a nice web application that takes two terms and uses Google to find out, which one can be found more often in the almighty internet. Whenever I am unsure about some construct of the English language or the spelling of some name, I use the Google Duel for a quick and dirty first impression what might be right (hmmm, is this guy spelled ‘Kwitschko' or 'Klitschko'?). The outcome is by no means authorative but sometimes a majority vote like this is enough.

I wanted to use the duel from the search field of my Firefox, therefore I wrote a little connector and a search plug-in (click to install). The two duelling terms have to be separated by a semicolon (;).