Before I go any further, I'd like to say that the Google Security Team (GST) is great to work with. Rios and I have had numerous vulnerabilities that we've reported to various companies and there simply is no one that handles things as quickly or communicates as well with the researchers. As Rios mentioned on his blog entry, this is a non-trivial exploit to fix, and they did it fast. Now, before someone accuses me of playing favorites or being biased, I'll answer that with a "Yep, I am biased in this case." I'll admit it. I'd rather work with someone who listens to what I say, responds professionally, and takes into consideration my own counter arguments. OK, that said, onto the details.
Really, I'm not sure we should call it taking ownership of content as much as we should call it taking "pwnership" of content, as this is a serious pinch point for applications. Rios gives the expert explanation of this issue, so I will paraphrase his blog entry for our discussion. Rios says:
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”.
Ok, so the key to this is that we aren't going to use Flash. As Rios states below, we're going to use Java so that we can get around of some of the limitations that Flash has for this type of attack:
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.
Awesome, this gives us exactly what we need then, and a very useful attack vector; however, there's some complications, as Rios mentions:
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.
Wow, pretty visual PoC, eh? I hate the idea of using my Google password!
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.
Like Rios mentions, you can buy all the tools and web application firewalls you'd like, it doesn't protect you from this issue, or from making your own mistake in creating this issue on your own web application. There's no substitute for design review and application security testing.
