CSRF - How much is enough?

One of the hot topics at AppSecDC this year seemed to be CSRF attacks and protecting against them. CSRF was brought up at least once in virtually every session that I attended at the conference (including several questions in my own ESAPI Presentation)

This spawned some great hallway conversations and got me really thinking about how we solve CSRF issues today. I kept coming back to an application I was working on recently that uses GWT and how I had to solve CSRF for that particular situation. See, normally the solution is to append a parameter on to the GET or POST request with a unique token that the server can verify against. Depending on who you talk to - sometimes this token has a lifespan of a session, and sometimes it is only a single request. Some would argue that for more sensitive applications you should use a per-request token and per-session tokens could be used in other places.

With that in mind, let's look at the GWT problem. You see in GWT, everything is handled by the Java -> Javascript compiler; which makes it very easy for Java Developers to create Rich UI Webapps. The flipside to this is that there is very little visibility (without a lot of research) into what is actually happening to your java code when you use GWT. Most developers just know that they put Java in and get a web app out.  This presents an interesting dillema for security in general, but specifically for things like CSRF and DOM Based XSS.

Google has posted an article all about securing GWT Applications - while I normally commend google on their suggestions as they pertain to security in software, I could not believe what they were suggesting as a solution to CSRF. The full article can be read here - but here is an excerpt outlining the proposed solution.

"A common countermeasure for XSRF attacks involves duplicating a session cookie.  Earlier, we discussed how the usual cookie-based session management model leaves your application open to XSRF attacks.  An easy way to prevent this is to use JavaScript to copy the cookie value and submit it as form data along with your XMLHTTPRequest call.  Since the browser's Same-Origin Policy will prevent a third-party site from accessing the cookies from your site, only your site can retrieve your cookie.  By submitting the value of the cookie along with the request, your server can compare the actual cookie value with the copy you included;  if they don't match, your server knows that the request is an XSRF attempt.  Simply put, this technique is a way of requiring the code that made the request to prove that it has access to the session cookie."

Wait... what?

First thought that popped into my mind when I read that (and maybe you had the same thought) was that the proposed solution of duplicating a session cookie doesn't solve the problem at all. I suppose this could be the case in a Framejacking CSRF Exploit, that this would solve that issue - but if I send a crafted link to a handful of users to their bank to transfer 1 million dollars to my account like:

"Dear Sir or Madam, I am writing you from EvilHacker Bank and Trust to let you know about a new policy regarding our interest rates - please click the evil link below to get pwned.

 http://evilbank.com/xfer?from=12345&to=12345&amt=1000000&forceApproval=1

Sincerely, 

Doctor Evil

EvilHacker Bank and Trust"

How does a cookie protect the user who is possibly already authenticated to the EvilHacker Bank application with a session cookie in their browser (and said duplicate session cookie). The browser is going to send both cookies because it does in fact, have access to them.

Well, that's completely unacceptable, I thought to myself. That doesn't protect the application or users of the application at all from CSRF. So I set out to come up with my own solution.

The answer, which turned out to be quite simple after a lot of research into how GWT builds in RemoteService interfaces and the javascript it uses to call services exposed to the client, was to make a slight modification to the ProxyGenerator (creates a Proxied implementation of the RemoteServiceAsync interface created by the developer). If you think of GWT Services in terms of RPC's this should make sense. I will likely post a follow-up detailing the solution and how to integrate it, but the meat of it is really this:

1. App Server needs a filter or some means to setup the session on the first request made to the application. This is standard CSRF protection behavior. 
1. Caveat with GWT - GWT generally uses static HTML files and the Javascript generally doesn't have any reference to any existing interpreted code (ie: JSP, PHP, etc.)  So the question became how do I tell the client application what the CSRF token should be. I chose to go with a cookie, but this could also be done as a separate RPC call to get the token (this presents it's own set of problems - they are not overcome-able) 
1. Created a filter (CSRFFilter) to generate a CSRF nonce when the session is created and set that as a cookie that gets sent back to the client. 
2. Client application reads the nonce from the cookie and alters the request to add a custom header containing the nonce. 
3. Server checks for either the presence of a request parameter or request header containing the CSRF nonce and verifies it against the value stored on the session (not in the cookie)
4. A new nonce is generated every time a new session is created.

So what does this really mean?

It means that since SOP rules won't allow a Java Applet (post 1.6 update 8) or Flash App (unless it is setup completely incorrectly) to make a cross-domain request - you are safe from the attack embedded in a flash or java applet, and since an e-mail client can neither predict the nonce, nor can it send request headers - you are safe from CSRF.

It also means that you cannot have entry-point actions in your application. So if your model is to allow people to accomplish some action by clicking a link from their e-mail - you will want to exclude that service from this solution (or just about any other CSRF protection - here you have are probably going to have to resort to a hash that can be calculated as your CSRF nonce, which still provides ample protection against most threat agents and situations, but is slightly less evil-hacker-proof then using something completely random)

Now on to the argument about sensitive data and the per-request token model. I think this is severely overcomplicating an otherwise simple and elegant solution. A distributed phishing style CSRF attack would have to not only count on a pre-authenticated session but would also have to predict the nonce (which is tied to the authenticated session) which while not completely impossible is so improbable that it equalizes the threat completely. In other words, with this solution - you may have a single successful attack inside millions of years (depending on the width and PRNG used to create the nonce)

The complexity introduced in managing a per-request model in an Ajax application becomes a nightmare full of bugs.

So, in summary - I contest that the per-request model of CSRF nonces is overcomplicated and a complete overkill in 99.9% of cases (there may be the small edge-case where this makes sense).

Remember, the more complicated a Security Control is - the more likely there is a bug in the control that can be exploited to circumvent it.

Cracking Passwords with Teh Google

Have you ever googled yourself? You may have to sift through several pages of results about people with the same name that aren't you, but you would be surprised how easy it is to find a wealth of information about yourself by combinging information retrieved by your social networking profiles being indexed.

Have you ever tried your hand at cracking a password? Chances are if you have, you have downloaded a word list and may have eventually cracked a password (unless you happen to have a cluster of PS3's laying around to do all the processing for you)

Password cracking is a lost art that often requires a lot of patience. There are two primary methods of cracking passwords: online and offline. When you attempt to crack a password online, it is often via a 'brute-force' style attack and has to be throttled carefully to avoid immediate detection (although, any competent system admin will be able to spot an online BF from a mile away after 10 shots of tequila) Offline, is often much more difficult to accomplish, simply because in order to crack a password offline, you either need to obtain a password list, or at bare minimum the hash of the password that you are trying to crack.

All that aside, one of the most difficult and time consuming parts of cracking passwords is starting with the right wordlist. There are tons of really horrible wordlists spread all across the internet, and even a handful of good ones. I am fairly partial to the Common Passwords Dictionary and the extremely large dic-0294 when I am flying blind.

However, with the wealth of knowledge available on the internet about everyone you know from sites like facebook, myspace, linkedin, hi5, twitter, and the list goes on and on, there really is no need to fly blind anymore when cracking passwords.

Now before I go much further, let me warn you that this is a tedious process right now as I am not aware of any tools in the tubes that do this for you (although, such a tool probably would not be to difficult to build) Also I would like to note that as a security professional, the information that I am providing is as much a warning to people about how easy it is to get their password, as it is a informative post about something that has been sorely neglected in security presentations (that I have been privy too).

To keep this relatively brief while still getting the point across, the example I am providing below is purely fictional, and any similarity to actual people is completely unintentional.

Step 1: Recon
If you personally know your target, this step is pretty much already done - however, if you don't know the target, the first step is to find out some very basic information about them. This is all public domain information that is easy to gain through the use of search or social engineering. For the purpose of this example we will say that I am trying to crack the password of a coworker named Don Johnson.

Now I know very little about Don other than the company he works for (obviously) and the department that he is in. We will say that he is the director of Human Resources. Our fictitious company name will be Acme Inc.

So seeing as how I know about him only in his job, LinkedIn seems the obvious starting point for me. Now, LinkedIn is one of those funny psychological experiments that proves that people really don't care about their privacy, no matter what they say. Their profile may say that they are only interested in reconnecting with previous coworkers, but if a recruiter requests to be in their network, they will almost always click - if nothing else, for curiosity sake.

Google Search #1: site:linkedin.com "Don Johnson" +Acme +Denver

9 times out of 10, the Don Johnson we were looking for will be in the top 5 results returned from google. Once I have found his profile, it is quick and easy to get a free gmail account, create a fake recruiter profile on linkedin, and start adding a bunch of people, with Don among those being added. The reason for adding several people is that Don may be a little paranoid and if a recruiter with no network requests to be in his network, he may think twice about allowing him - however, if Don sees that this recruiter is acting like most every other recruiter on linkedin, and obsessively adding 10-20 people a day, well he will probably think nothing of it and allow the request. Once he is in your network you can view his full profile which will often include such information as all of his prior employers, education, blogs, etc. Generally, I will take a scrape of the entire profile (a scrape can be as simple as using File -> Save Page As in your browser) and use the information and picture from that profile to identify him on other networks.

Let us say that in the recon of my target I discovered a linkedin, facebook, myspace, and pandora account all linked to Don. I have scrapes of his profile pages from each network, along with an archive of comments and wall postings on friends profiles from the last 60 days.

Step 2: Assimilation of Information

This is where things really start to get interesting. You have a wealth of information now about your target. You know who he is dating, the names of all his pets (real and virtual), a list of his favorite musicians, movies, and books (invaluable), a collection of nicknames, his birtday, and much much more.

I specifically call out the fact that music, movies, and books are invaluable information to know about a target. Often, people will use a term or character name from their favorite stories as all or part of their password. So that being said, you can take Don's favorite songs look up the lyrics and start your wordlist. Next, look up a character list from his favorite books and movies, then lookup memorable quotes from those characters (imdb.com) and (wikipedia) are your friends here. Keep doing this with all the information you have until you have a comprehensive word list built specifically around the social profile of your target.

This is it, this is all you need to do. I have a relatively high (60-70%) success rate when building a custom word list using this method and if I were to take the time to build some tool that used the full power of the internet to build related information, I could almost guarantee a 90%+ success rate at using this method.

So the next time you are updating your profile on myspace or facebook, think about the password that you are using to login to that site and see if you can connect the dots between your password and any of the information on your profile. I would say that for most people, they will be able to make the connection fairly quickly and most of the time.

I purposefully described this process in a fairly abstract manner, as it is a very effective means of social engineering without having any direct contact with the target, and really, there are enough bad guys in the world already.

We rely on technology to keep our personal information secure and safe, yet the true dangers still lie in the information that we publicly disclose without a second thought. This is no different from the days of dumpster diving, only google is a much cleaner and organized dumpster.

Eric Schmidt, Google, and Apple

It appears that my long lost relative, Eric Schmidt, has left the Apple BoD. What do I think about that, simply that I really need to get in touch with Eric and see if he wants to loan his long lost relative, me, a couple million. Other than that, I think this will probably resolve the whole Apple/Google thing for the most part, but I really don't think that Apple wants to get themselves into an Apple vs. Google scenario. We will see what happens, but I imagine this all going away and news shifting back into the Microsoft vs. the world scene shortly.