All Your Google Docs are Belong To US...

It's been a rough week for Google Security...  It seems like everyone had some Google vulnerability they wanted to disclose this week.  You can see some of the various vulns here, here, and here.

   

Well... the week isn't over YET!  I'm actually disclosing this vulnerability because Google has already fixed it.  Although I don't use Google Docs (because I'm a paranoid guy), I know a lot of people who do and I didn't want to put their docs at risk.  Without  further delay, the details...
 
This vulnerability allowed any Google Docs user to STEAL ARBITRARY DOCUMENTS from the Google Docs Server.  The basis of the vulnerability stems from a simple Session Management issue.  Once a user has logged into Google Docs and has created a document, they are presented with several options.  Under the "Share" tab, the user has an option to "Email Collaborators"

     



   

Once the user clicks the "Email Collaborators" link, the following HTTP GET request is made to docs.google.com:

   

GET /Dialogs/EmailDocument?DocID=<ANY DOC ID HERE> HTTP/1.1
<appropriate HTTP headers here>

    

If you changed the DocID value to another DocID, Google Docs WOULD NOT VALIDATE whether you should have access to that DocID.  The title of the stolen document you requested will be shown (as a javascript variable) in the HTTP 200 OK response that is returned.  Once this step is completed, you can make a POST request to a Google Docs Server Side Script named MiscCommands.  The POST request looks something like this:

   

POST /MiscCommands HTTP/1.1
<appropriate HTTP headers here>
 
command=validate_address&docid=<ANY DOCID HERE>&addr=gmail%40gmail.com&finis=true&POST_TOKEN=POSTTOKENVALUE
    

If you changed the DocID in the POST request, the entire contents of that document would be emailed to the addresses specified in the "addr" parameter!  I tested this against several friends Google Docs and it worked EVERYTIME! 

   

This issue does stem on being able to predict the DocID for the document that you want to steal.  At first glance, the DocID seems to be a fairly stout "random string", but a little bit of analysis shows some interesting characteristics.  It seems that the DocID is delimited by an “_” character.  The characters preceding the underscore represent the Google Docs UserID.  Each document uploaded to Google Docs by a particular user will have the same characters up to the underscore.  Now... what about the characters after the underscore?  Well... take a look at what happens when I generate 10 different DocIDs in rapid succession:

    

mydocsid_14ggbd48
mydocsid_15gt54pt
mydocsid_16c44jws
mydocsid_17cnnfw8
mydocsid_18ggzpm7
mydocsid_19dczf6g
mydocsid_20c8h7nx
mydocsid_21czqc3h
mydocsid_22d48w8j
mydocsid_23f4hk9b
mydocsid_24gdwfzk

   

Maybe the last set of characters isn’t as “random” as we thought……  Throw in some DocID enumeration (which exists) and we may be on to something here…       I’ve seen Session Management issues like this in MANY of the web applications I’ve assessed.  If your hired gun (webapp pentester) looks at you funny when you ask if they are testing for Session Management issues, FIND A NEW ONE!  There isn’t a web app vulnerability scanner on the market that can detect this and Web App firewalls will not prevent this either!  It takes an actual brain and some experience to find these types of issues!                 
       
In closing, I would like to give a shout to the Google Security Team.  If you’ve ever dealt with the Google Security Team, you know that they take security seriously and they move fast…. VERY FAST.  After giving them the details for a couple of Google vulnerabilities, it took Google ONE DAY to fix the issues and to deploy the fixes worldwide… Kudos to Chris and the GST.

Google Docs puts Google Users at Risk

The whole concept of "Taking Ownership" of someone else's content can be VERY dangerous.  The reason taking ownership of content is so scary is because the ENTIRE trust model for the World Wide Web is basically built on ONE thing... the DOMAIN NAME.

   

This is why issues like XSS on sites like google.com are such a big deal... XSS basically allows an attacker to execute client side code in the context of the vulnerable domain.  Malicious client side script is one thing... but malicious client side script executed in the context of a trusted domain is something entirely different... but I digress...

   

Google Documents basically allows you to upload your documents (aka content) to a Google server.  Once you've uploaded the document, Google has essentially "taken ownership" of the document (content).  There are ways to minimize the risks associated with taking ownership of content and it seems that Google has taken some measures to sanitize for XSS... but it seems that their focus on XSS may have caused them to miss a different type of cross domain exposure.

   

Flash Players (>7.0.19.0) support a new method for making cross domain requests.  This method allows a user (or attacker) to specify where a crossdomain.xml file is located on a particular server.  Essentially, if the flash player finds this crossdomain file (and the file is properly formatted) the flash player will allow cross domain requests to the domain that "owns" the crossdomain policy file, in this case... Google.com.   We talked about issues like this at our DEFCON talk.... but I guess Google missed out.

   

So, the Proof of Concept works like this:

1. NO XSS IS REQUIRED!


2. Create a Google Docs Account and upload a properly formatted Crossdomain.xml file


3. Once the file is uploaded, you publish the file, exposing the file to every authenticated Google.com user.


4. Create a flash object on a malicious server, pointing the System.security.loadPolicyFile() to the document that you uploaded to Google Docs.


5. Once the Flash object has read the contents of the crossdomain file from the Google server, it assumes that Google has allowed cross domain requests (I mean… who in their right mind would allow random people to upload random files to thier server and serve that content under the context of their trusted domain name?).


6. Now, the flash object has full access to the google.com domain and can steal all your Google information.

   

Proof of Concept can be found here.  The PoC just displays your contact list, but I have full access to the Google.com domain, so the sky is the limit (aka I can read all your email too)... I left out one key step needed to pull this off and the source for the Flash applet will not be published at this time in order to slow the kiddies. 

     

If anyone from Google Security comes across this page, send me an email and we can go over the missing step as well as the Flash Source... I'd also like to talk to you about another hole in Google Docs that allows me to ACCESS ANY ARBITRARY USERS DOCUMENTS.

Stealing Pictures with Picasa

In celebration of our acceptance to Black Hat Japan, we've decided to post the details on our Picasa exploit which allows an attacker to steal images from victims.  Perhaps this should be the month of Google flaws considering our posts in this previous week and some of the posts that are on their way in the next week or two.

   

If you've read our previous post Say Cheese! then you know that Google's Picasa registers the picasa:// URI in the Windows registry and it is possible to abuse this registered URI through a Cross-Site Scripting exposure to steal a victim's images.  My personal feeling on this issue is that it represents a HUGE privacy breach for users of Picasa. Ok, so without further dramatic build-up, you can find the gory details here and you can find the source code we use for the exploit here.

BK for Mayor of Oak Tree View

I’m excited about Google Docs.... although there is NO WAY you could convince me to upload my sensitive documents to a Google Server, I’m still very interested in seeing how Google’s Engineers tackle the security issues with online document sharing.  Security for online collaboration tools is TOUGH, every online collaboration tool I’ve ever assessed has had major issues. 

    
So I made my way to docs.google.com to see what the hype is all about.  I found the link for “Watch a Video” on the login page.  I like Google’s videos and this one did not disappoint.  About half way through the video (1:60), I saw something that made me put my beer down… a link to a Google Document.

   



   

Being the curious sort, I entered the link into my browser address bar.  I was surprised to see the following document:

   



    

Now, being able to view someone else’s document is pretty bad… but this is a demo… maybe they WANT everyone to see this document… that’s understandable.  So what happened next REALLY surprised me…  I clicked on the “Edit this page” link, entered my creds… and lo and behold…  I had full rights to edit/modify the Oak Tree View newsletter! 

   



      

I was planning on using the Oak Tree View newsletter to launch my campaign for Mayor of Oak Tree View, but I decided against modifying the page, as I’m not interested in pwning Sam’s pretty little newsletter.  I’m sure she’s not interested in what I have to say about Oak Tree View….

 

The Old Dog and his Old Tricks (Part I)

Lets say I found a CSRF that allows me to hijack your Gmail account to send an email from you to another Gmail user... would you consider it a risk?  Well, the good news is I don't have a CSRF to send out email from your Gmail account, but the bad news is I don't need CSRF (or any other exploit) to send an email from your Gmail account.

    
Using Google's SMTP servers, I can send an email from any Gmail (or @google.com) account to any other Gmail email address.  The process is simple... and is shown in the images below (addresses masked to slow the kiddies).



   

This is NOT a vulnerability in Google's infrastructure... it's merely how SMTP was DESIGNED to work.  This same procedure works on other SMTP servers as well.  Many of the old protocols (like SMTP) that we continue to use everyday are inherently insecure.  My favorites are DNS, SMTP, and ARP.  Many of the exploits based on these protocols aren't really even exploits... they are simply an abuse of functionality intentionally built into the protocol!

    

How could we let things get so bad?  Why should I be ALLOWED to send an email on your behalf, sending colorful messages to other Gmail users?  Honestly....  I don't know... what I do know... is instead of fixing the underlying protocol (which is painful, costly, and resource intensive) we've "bolted on" temporary fixes like spam filters to help us "fix" the issues with the underlying protocol.  After a while... we get used to having these "bolt on" and the temporary fixes become permanent fixes and the underlying protocol remains vulnerable to simple attacks like this one.

    

I know what you're saying.... "SMTP was created in the wild wild west... times have changed... that will NEVER happen again!"  The sad thing is... we're starting to see the same things happening to HTTP.  Just as SMTP Admins have turned to Spam filters and other appliances to make up for the shortcomings of SMTP, we are now seeing that many are turning to Application Firewalls to make up for the shortcomings of HTTP and poor coding practices.  There are some that claim that application firewalls are a great "temporary fix", and they probably they are!  Just as Spam filters were a temporary fix for SMTP abuses!

      

HITB 2007!

I'm back from HITB in Malaysia!  HITB was held in Kuala Lumpur, Malaysia from September 3rd - 6th.  The conference was AWESOME.  Dhillon really out did himself this year.  The talks were awesome and the company was second to none.  You can find the slides for all the talks (including our slides on DNS rebinding with Java Applets) here.  Dhillon will be posting links to the VIDEOS in December!

   

It was a truly amazing experience to sit down and have a beer (or two) with the likes of Phiber Optik, Emmanuel Goldstein, Window Snyder, Andrew Cushman, Mikko, Lance Spitzner, fx and many many others.   

   
All the talks I attended were great, but I particularly enjoyed:

• Rise and Fall of Info Sec in the Western World - Phiber Optik - Listening to Phiber Optik talk about pwning a major corporation live for the audience during conference he was speaking at was sweet. 

• The Evolution of Hacking - Emmanuel Goldstein - Listening to some old skool hacks is always fun and brings back memories of 300 baud modems and wildcat bbses...

• SCADA (in)Security - Raoul and Alessio - I'm EXTEMELY interested in SCADA systems and the security surrounding them.  There are basically a handful of SCADA security experts around the world and Raoul and Alessio are two of the best.

• Exploiting the Intranet with a Webpage - Martin Johns - It was nice to hear about DNS rebinding from the guy who basically brought DNS rebinding back from dead!

• Locks, Lies, and Liability - Mark Tobias and the TOOOL USA - Watching these guys pick apart "high security" locks was pretty scary... especially when I saw a few locks we used in the Marine Corps in the speaker slides!

• Online Crime and Crime online - Mikko Hypponen - It seems that Mikko is VERY well connected to the underground.  Not only did he describe (in crystal clear detail) how the general Internet population is getting pwnd, he showed exactly where all the action is taking place!

During our talk, we mentioned that we would post the details of a recent Picasa URI vulnerability (which will be patched in next version of Picasa).  We'll have the details, screenshots, and a dedicated POST up in a few days.

  

In closing, I would like to thank Dhillon for inviting me out to HITB 2007 and the wonderful country of Malaysia.  It was an amazing experience and everyone (including the street vendors in China Town) were such gracious hosts!

Firefox File Handling Woes

It seems recent URI remote command execution bugs in Firefox have long been forgotten.  Mozilla put out a patch in a lighting fast manner, probably spurring on bravado like the “10 Fucking Days!” claim overheard at Black hat USA.  Let’s take a closer look at the vulnerability, starting with an interesting piece of the description provided in MFSA2007-27: 

   

“…Further investigation by Secunia showed that a % not followed by a valid two-digit hexadecimal number also triggered the problem for the affected protocols. The Firefox and Thunderbird 2.0.0.6 releases contain fixes that prevent the original demonstrations of this variant, but it is still possible to launch a file type handler based on extension rather than the registered protocol handler. A way to exploit a common handler with a single unexpected URI as an argument may yet be found. Since this handling is a property of the Windows Shell API this variant appears to affect other internet-enabled applications that pass these URIs to the Windows Shell.”

   
   Well, to make a long story short, Nate and I have discovered a way to “…exploit a common handler with a single unexpected URI…”  Once again, these URI payloads can be passed by the mailto, nntp, news, and snews URIs, allowing us to pass the payload without any user interaction.  So, it seems that although the conditions which allowed for remote command execution in Firefox 2.0.0.5 have been addressed with a security patch, the underlying file type handling issues which are truly the heart of the issue have NOT been addressed.    

    

    We contacted Mozilla a while ago about the issue and they are working on it.  We’re going to refrain from giving out the exact details of how this particular issue is executed (based mainly on the efforts and conversations we’ve had with Jesse Ruderman), but we’ll include a screenshot of a payload in action.  In the screenshot below, we use the mailto URI, which passes the URI to the Windows File Handler, which calls the appropriate program (in this case Windows Scripting Host), which in turn calls our attacker controlled file.  We’ve purposely pointed the Windows Scripting Host to a file that doesn’t exist as the error message allows the user to see that WSH is using the URI passed from Firefox.