Maddin, Montag, 19. Februar 2007, 12:28 LocalRodeo - Client-side protection against JavaScript Malware After contributing to show how to breakthings, 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)
Maddin, Sonntag, 4. Februar 2007, 21:38 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 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.
Maddin, Freitag, 12. Januar 2007, 15:24 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.
Maddin, Donnerstag, 4. Januar 2007, 11:19 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:
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.
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.
Maddin, Dienstag, 2. Januar 2007, 16:34 Outdated advisory: Code injection via CSRF in Wordpress < 2.03 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 recenttalks, 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.
Maddin, Dienstag, 26. Dezember 2006, 15:07 Using eval() in Greasemonkey scripts considered harmful 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:
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.
Maddin, Montag, 11. Dezember 2006, 11:15 The grand Hillbilly Bank Robbery 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.
Maddin, Freitag, 8. Dezember 2006, 09:58 Request Rodeo released 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.
Maddin, Mittwoch, 6. Dezember 2006, 16:35 Back form PacSec 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.
Maddin, Donnerstag, 23. November 2006, 12:16 Going to PacSec 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.
