Saturday, June 14th, 2008

3rd Annual Symposium on Information Assurance

I was recently given the honor of delivering a keynote talk for the 3rd Annual Symposium on Information Assurance, which was held in conjunction with 11th Annual New York State Cyber Security Conference.  It was a great conference and I want to thank Sanjay Goel for inviting me!

 

The conference was VERY academic… which I love.  Academics present with an eye to the future so I listened as PHD candidates talked about securing nano networks, sensor based wifi networks and a slew of other topics… Academics also seem to have an boldness and fearless approach to the topics they present, which I admire…

 

While I enjoyed most of the talks I attended, there was one that perked the ears of the blackhat in me.  John Crain of ICANN gave a talk on “Securing the Internet Infrastructure: Myths and Truths”.  If you don’t know, ICANN basically owns the root DNS servers that the world relies on everyday.  He gave a great explanation of how ICANN goes about creating a heterogeneous ecosystem of DNS servers.  These DNS servers use multiple versions and types of DNS software, multiple versions and types of operating systems, and  even go so far as to use various pieces of hardware and processors.  The reasoning behind this logic is… if a vulnerability is discovered in a particular piece of software (or hardware) is discovered, it would only affect a small part of the entire root DNS ecosystem, whose load could be transferred to another.  It’s an interesting approach indeed.  After the talk, someone asked me why enterprises/corporations don’t adopt a similar strategy.  I thought about it some and I don’t think this approach could enterprise environment… here’s why (other than the obvious costs and ungodly administration requirements):

 

ICANNs interest is primarily based on preventing hackers from modifying a 45k text file (yes the root for the Internet is a ~45k text file).  Now, if a hacker happens to break into a root DNS server and modifies the file, ICANN can disable the hacked system, restore the file and go about their business.  As long as ICANN has a “good” system up somewhere, they can push all their traffic to that system.  Businesses on the other hand, aren’t not primarily interested in preventing the modification of data (not yet at least), they are more interested in preventing the pilfering of data.  So if you own a network of a million different configurations, a vulnerability in any one of those configurations could allow an attacker to steal your data.  Once the hacker has stolen your data, what does it matter that the 999,999 other systems are unhacked?  

This brings up the heart of the argument, should we be worried about our systems being compromised or should we be worried about our data being stolen?  These are actually two different problems as I don’t necessarily have to compromise your system to steal your data…

Posted by xssniper | Filed in Uncategorized | 1 Comment »

Monday, April 21st, 2008

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

Posted by xssniper | Filed in Security, Web Application Security | 5 Comments »

Monday, April 21st, 2008

ToorCon ROCKED!

ToorCon this weekend totally ROCKED.  Any venue that has flaming tetherball, major websites getting pwnd, hawt hacker chics pwning backbone protocols, java 0-days, and free beer has to ROCK.  All the talks I caught were awesome and the con has inspired me to look into some new avenues of research (aka pwnage). 

      

Thanks to H1kari, tim, Geo, and Phil for having me out!

Posted by xssniper | Filed in Security | Comment now »