Geocommons.com admin account hijack

Potato chips, post-it notes, LSD and Viagra - all these things were discovered by accident. As it seems, sometimes great discoveries come by a surprise. I've had my moment of surprise lately. It all started during my research on sites using Cross Origin Resource Sharing. You know me, I just have to check the real-world HTML5 implementations. So there I am, checking sites implementing CORS headers. Geocommons.com is one of them - and this is the story of how geocommons got really common.

GeoCommons is the public community of GeoIQ users who are building an open repository of data and maps for the world. The GeoIQ platform includes a large number of features that empower you to easily access, visualize and analyze your data.

There was a critical vulnerability in geocommons.com website allowing any user to change e-mail address of administrative user and hijack the admin account. According to vendor, vulnerability is now fixed.

The simple vuln

Every user of geocommons.com is allowed to manage his/hers account credentials. Among other features, he's allowed to change the e-mail address. These functions are accessible by sending POST requests to http://geocommons.com/users/[user-id] URL. Sample POST content changing e-mail address of an account looks like this:

_method=put&user%5Bemail%5D=email@example.com&commit=Save&user%5Bterms_of_use%5D=1

I quickly confirmed that the form is vulnerable to CSRF. CSRF allows for form submission on behalf of any user logged in to geocommons.com. Knowing user ID (it needs to be in URL) attacker can convince user to visit a page sending POST request changing user's e-mail address.

Close, but no cigar. Sure, attacker can send thousands of requests and one of them would finally succeed (once he reaches the correct user id).

Moment of surprise

Just to check, I started doing some PoC. I created a user (his ID was 35 thousands something), and made him visit the CSRF page:

 for (var i = 0; i < 50000; i++) {
        post = {
            '_method':'put',
            'user[email]': 'securityvictim+exploit' + i + '@gmail.com',
            'commit' : 'Save',
            'user[terms_of_use]':'1',
        };
        
        $.ajax({
            url: 'http://geocommons.com/users/' + i,
            data: post,
            type: 'POST',
            complete: function() {console.log(user)}
        });

The code tried to replace user email with my securityvictim@gmail.com email (with +tag). Well, it was slow as hell. So I stopped. Just to check if anything succeeded, I browsed the geocommons.com site and searched for users with that email.

WTF????

I replaced admin account e-mail!

As it turned out, there is also a critical vulnerability, allowing ANY user to change admin account e-mail address. One only needs to submit the form to http://geocommons.com/users/1 (1 is user id of admin). Bitter CSRF just got a lot sweeter :)

Combining these two vulnerabilities, it is possible for an attacker to submit a form changing admin e-mail, while leaving all the traces to victim who was CSRFed. After changing the e-mail address to one under his control, attacker can simply use forget password feature of the site to get the new temporary password and effectively hijack the admin account of geocommons.coms

See for yourselves

Form submission

with new email

And a password reset

... sent conveniently to attacker's account

And all the admin goodies...

What's interesting, it's only admin (id=1) account that is so special, I cannot change the email of any other user (apart from myself). It might have something to do with the fact that admin can change properties of any other user, but who knows...

Timeline:
6.10.2011 - vulnerability discovered, PoC made
7.10.2011 - vendor notified & replied
11.10.2011 - vendor comment: issue fixed in codebase, we will be deploying soon
25.10.2011 - vendor comment: we are deploying today
22.11.2011 - public disclosure

Notes for developers

• Protect against CSRF by using unique nonces. CSRF is serious!
• If you're trying to protect only some of the forms (e.g. login form, password change form), always remember that e-mail address change form (or. e.g. security question change) form is equally important! With CSRF flaw there, attacker does not need to know the password, he can switch the e-mails and use the forget password feature to regenerate one.