Phishing is now recognized as a 2007 SANS Top 20 risk, and rightly so. What I was even more excited to see is SANS calling out the countermeasure correctly. They didn’t recommend deploying millions of dollars worth of technology to “catch” phishing attacks, but said “user awareness is a key defense. The most promising method of stopping spear phishing is continuous periodic awareness training for all users; this may even involve mock phishing attempts to test awareness”.  As I said in a previous blog post , we are in total agreement with SANS on the efficacy of this countermeasure. In fact we are so in agreement that we have developed a solution (www.phishme.com) to do exactly that – run mock phishing attacks to test and measure employee awareness.

Now for the gimmicksmen. Qualys just made an interesting announcement – “Free security scan available for the new SANS Top 20“. I wonder how they are going to scan for phishing vulnerabilities.

 - Rohyt

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.

If you’re out at the OWASP AppSec conference in San Jose this week, we invite you to come hear a presentation about Ruby on Rails security. We’ll mostly be covering how Rails holds up to standard web attacks (SQL Injection, Session Riding, XSS, and on down the list), but also adding in a little deeper dive into the default Rails 2.0 session storage.

The Rails framework is definitely doing some security features very well, but when the final 2.0 version comes out later this year, session storage is not going to be one of them. The new default Rails configuration will actually be storing server side session information in client side cookies. (You read that correctly….) The server side session information is going to be pushed down and stored on the client side web browser’s cookie cache. This new rails session cookie value will consist of two items. The first being a dump of the session object that has been Base64 encoded and then URL encoded. Notice the word encoded not encrypted.

You will be able decode and view all the data in your session object as quickly as you can copy and paste and click. The only thing preventing you from changing that data and resubmitting your “is_admin=true” session hack will be the second part of the cookie value. This will be a hash of the original session value along with the secret server side password (the default hashing algorithm will be SHA1). Do you see where this is going? You will be able to locally brute force the hash to uncover the secret, then put anything you want into your server side session object.

I’ll be posting some code later this week to demonstrate, but everything you need is already in the “cookie_store.rb” file if you’ve downloaded the Rails 2.0 Release Candidate. If you’re using edge rails or building a rails 2.0 application, I would strongly recommend using one of the other session storage choices.

~b3nn

Update: See the “Part II” post for the BustRailsCookie script.

The development of our phishing attack emulation service, to be hosted at www.phishme.com, is on target for a February 2008 release. We are in the midst of alpha testing at this time and hope to be ready for beta in January 2008. At that time, we will be opening up the service for free evaluation. If you are interested in being notified (via email) when the evaluation accounts become available please sign up at http://phishme.com/signup.php (we will not phish you ).

- The Phisherman

We might finally have some decent mobile viruses to worry about.

Why is it that McAfee’s VirusScan Mobile is only Windows Mobile 5 and 6? Simply put, it’s because that platform gives the end-user enough rope to hang themselves. Users can grab a .CAB file of the brick breaker game from only god knows where and install it themselves through Activesync.

Surely tech-savy users don’t just install any hackware from untrusted sources right? If you believe that then you haven’t spent much time on http://www.howardforums.com/ or http://www.mobile-files.com/forum/ where every day, technophiles repackage and swap DLLs and other tasty bits from one carrier’s phone to another. Users don’t care about running untrusted code. To them, it’s just an annoying split second while they click away the nag window so they can dive into Justin Timberlake-screensaver-ring-tone wallpaper bliss.

It goes beyond running untrusted code from untrusted sources. Users will replace entire operating systems through unofficial channels:
Windows Mobile 6 for the XV6700: www.downloadsquad.com

If you step outside of your tech circle for a moment you’ll notice that most of your friends and family (you know, the people that will be watching football over Thanksgiving while you’re fixing their computers) don’t have windows mobile, RIM, or palm phones. If they have a typical Verizon phone then they follow a path like this to get applications:
Developers create and sign BREW code, that code is then tested and certified via Qualcomm’s NSTL site: https://www.nstl.com/brew/ . Ultimately the wireless carrier decides on what application they put in their catalog. (Usually after they test it themselves.)

Some see this path as a way to lock the user into the carrier’s applications. Another way to look at is the carrier is certifying that code for your phone. Given that the wrong code can put your handset into a chronic state of reboot permanently ruining the device I can see why carriers like to keep tabs on what users load on the phone.

The masses are crying about an open iPhone API. I’m sure they’ll get the open API, along with everything else that comes with it.
If you look at any of the press surrounding Android, the mantra is clearly openness and convenience. Openness and convenience; security’s best friend? <borat> NOT! </borat>

-higB