Intrepidus Group
Insight

Owning Rails 2.0 Cookies at OWASP: Part II

Posted: November 19, 2007 – 2:05 pm | Author: | Filed under: Conferences, Web Apps

The OWASP conference proved to be a great ground to bring up this topic of the proposed Rails 2.0 cookie storage structure. I’ve had quite a few conversations with ASP.Net guys since this post comparing the Rails 2.0 Cookie storage verses Microsoft’s ViewState. While I agree there are quite a few similarities, I think there are still a few issues that make this Rails technology choice flawed.

Consider basically any web application for which there is unique data for particular users (like just about any app that requires a login). When the user logs in, the first thing your application typically does is look up the user in the database and stores their unique userID in a session object (if they pass authentication). Your app now should use that session value for each additional database query to only pull up your unique data. There are no additional checks since there should be no way the user can change this ID value… as long as you never send it to the client (I’m talking to you Mr. “Hidden” form tag). The amount of damage you can do by manipulating a value like that, which I believe is very common for any application, is considerably more sever than any attack against ViewState (given any logical implementation of either technology).

Another item that makes the Rails approach flawed is how the password is chosen for the SHA1 hash. It’s great that Rails will not allow a blank “secret” to be used, but this is the only complexity check. My feeling is that the machineKey approach used with ViewState hashing and encryption will yield a much more complex password than what you will find most developers choosing on their own. To prove that point, try out the BustRailsCookie.rb code. You’ll need Ruby installed and either a few trusty wordlists or John the Ripper. After that, just pass in a rails 2.0 cookie with both the encoded value and the hash. The script will first show you the unmarshalled session object, then start the cracking for the server side secret password.

I still think Rails is pretty sweet. Just make sure to update one line in your environmental files if you’re using 2.0. For those of you looking for more info on how Rails stacks up against the OWASP top ten, Heiko Webers has created a fairly in depth and up-to-date guide on the OWASP site. I recommend checking it out.

~b3nn

Ruby Script: BustRailsCookie.rb
Windows Compiled: BustRailsCookie1.1.0.zip
(Note: little problem with the compiled version and pipes. I recommend using the ruby script if you have ruby and rails installed.)

Update: Heiko has also added a post about this issue on his RORSecurity.info site.

Update (11/25/2007): Well glad this made it to the eyes of DHH on the core mailing list. I guess the “is_admin” flag is a bad choice for an example in Rails. I was hoping it would make things more clear, but my view is even putting the “user_id” in the cookie store session becomes dangerous if someone chooses a weak secret password (and my experience with that is… people choose weak passwords). If it’s something from a dictionary, or easy to brute force, it then allows anyone who cracks it to become any other user in the application. Even with encryption or a strong password, storing the session in a cookie opens up the possibility for an attack against it which is not present in the other session store options. As Heiko pointed out, he’s already found some code with fairly weak secrets set. I guess we’ll see how this plays out in the real world.

Both comments and trackbacks are currently closed.

3 Comments

  1. Posted November 20, 2007 at 5:50 pm | Permalink

    I’m sorry to report that you spread FUD at the OWASP conference.

    Remove the rev query parameter from the link to the cookie store source, or simply checkout Rails trunk anytime since March 3 2007, and reconsider your claim.

    I find this lack of diligence inexcusable when it’s the basis for a talk at a security conference. Please consider correcting this and your earlier post.

    There are legitimate concerns with the cookie store, but brute force attacks are not one of them.

  2. Posted November 20, 2007 at 7:17 pm | Permalink

    Correction: the cracker itself does use the HMAC. All the other links are wrong. The concern regarding session secret strength is totally valid. See the discussion on the rails-core mailing list for more.

  3. Posted November 21, 2007 at 8:56 am | Permalink

    Here’s a link to the rails-core mailing list where this topic is continued.

    http://groups.google.com/group/rubyonrails-core/browse_thread/thread/769f64d0f4ad59af

    To wrap up where things currently stand: Yes, the brute forcing of the cookie store hash is possible like this script demonstrates (so choose a strong password everyone!) And session replay is also possible (but there’s probably ways to fix that.) We seem to be in disagreement that this should be the default session store choice.

One Trackback

  1. By PhishMe » Owning Rails 2.0 Cookies at OWASP on November 19, 2007 at 2:16 pm

    [...] See the “Part II” post for the BustRailsCookie script. Digg [...]

image

This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24707 items have been purified.