Wednesday, 9 May 2012

CSRF - improving the basic attack

CSRF is a low risk vuln for script kiddies

I think Cross site request forgery (CSRF, which I've always been alone in calling see-surf) gets a pretty bad rap, not least because script kiddies are flooding exploitdb with boring CSRF attacks against CMSs that no-one uses. But let's not write off CSRF as a bland client-side attack just because people are using it poorly. CSRF actually has very viable and useful applications that takes a little longer to create, but the results are totally worth it.

It all revolves around how we are trusted when we log in. Normally this means C-surfers go looking for all the functions that doesn't require creds or authentication to complete. Most half decent apps will therefore check and protect against this. But quite often they make a mistake.

A better surf

Lets take an example:
 Joe's email web portal allows users to log in and then allows passwords to be changed. Fearful of CSRFing, they make the user include their old password in the request. Solved! But of course the user is who they say they are, so don't limit them on retries when they get the password wrong....

Yep. We can run dictionary attacks through CSRF.

So is this so great? It's a little slow (maybe a couple of minutes to run through a decent dictionary and ultimately still limited to having people visit your site that have to be logged in to the site you want to hit to be vulnerable. So yes it's still a limited client side attack, but it's one that works on some pretty popular apps.
Just load a dictionary into a JavaScript array and run it in a loop. JavaScript can handle GET and POST.

The only problem is that it's blind. We could change 50 people's passwords with this attack, but how do we know it's worked, and to whom?

Consequences....did it work?

Obviously this is easy if there's other attack vectors, like XSS but then if you've got cross site, then you hardly need CSRFing. The important point here is that other lower vulns can be used alongside this one to build a more valid attack vector.

Enumeration of usernames allows trying the altered password against the list. As you're only trying one password on each account, it shouldn't cause a lockout.

CSRFing multiple points can make the attack victims more visible. Changing a profile value may be pretty lame by itself, but if it is done along side the password change, it would become a flag to compromised accounts.

No comments: