Bug Bounty: Tumblr reCAPTCHA vulnerability write up

On the 16th of June, HackerOne paid out over $80,000 in rewards during their first London meetup. Bug bounties are big business, and for good reason. Bug bounty programs incentivise security researchers to report security issues in an organised manner. Not only do they compensate researchers, they also drive up the quality of reporting so that an organisation has the full details required to quickly fix the issue that has been identified. Security is hard, and even big companies can make trivial mistakes. Bug bounty fills a gap between internal resources and external adversaries. It’s also impossible to internally recruit the quality and diversity of security testers that you can gain access to through external programs such as Bugcrowd and Hacker One, or consultancy services.

I’ve personally had experience of both good and bad handling of security issue reporting. Last year I reported an issue to Myspace, a critical vulnerability which allowed access to any user account. Yes, any user account. After many attempts to make contact with Myspace, I decided to publicly disclose this issue. Why did I choose to publicly disclose? This particular issue affected over 360 million user accounts. Times Warner, the owners of MySpace have a duty of care to protect user accounts on this website. You can read the original article here. Public pressure was sufficient for them to implement a solution to close the vulnerability. This is not a favourable course of action, but in some cases, the only option is to publicly disclose the security issue.

TUMBLR RECAPTCHA VULNERABILITY

In contrast, I had an excellent experience reporting a security issue to Tumblr this year. I contacted Tumblr in October last year, using their security and reports form. Unfortunately, my report was not received. In January I reached out to Tumblr on twitter. They were quick to respond to me through direct mail, and I was able to directly email my findings to one of their security engineers. Two days later, they confirmed that the vulnerability had been closed. The rest of this article covers the technical details of this vulnerability.
I identified a misconfiguration in the implementation of google reCAPTCHA during the account registration process on www.tumblr.com. The Google reCAPTCHA value sent by the client and the application allows for the paramenter ‘g-recaptcha-response’ to be empty. This vulnerability affects all new account creation and it doesn’t require any special tools to exploit. This can be done manually by the user by clicking the buttons in the application, or by intercepting the HTTP request in a tool such as burp.

IMPACT

Captcha if implemented properly is rate limiting, it should prevent spammers from creating fake social media accounts and reduce the volume of requests to a given application. This misconfiguration allowed for fake accounts can be created. It also had the potential for email and username enumeration; because the application prohibits more than one username being associated with one email during the account sign up process.

HOW IT WORKS

In order to understand how this works, lets take a look at the normal page flow for account creation on www.tumblr.com. The first page you are presented with is the login page. You can navigate to the signup page by clicking on ‘Sign up’.

This takes us to the first page in the account creation process, the ‘register’ page.

Click on ‘Get Started’ and you are presented with a number of fields to complete; username, password and email.

Once we have completed this initial information we are asked to agree to the sites terms and agreements.

Finally, we are asked to complete a reCAPTCHA form to confirm that we are human.

The web application itself isn’t checking that the user has completed a reCAPTCHA check. So instead of clicking on “I’m not a robot”. Instead I can click on “Almost Done!”

This will will take me to the dashboard of my newly created account, therefore bypassing the reCAPTCHA check entirely!

If that wasn’t clear, check out this video which demonstrates how this works

So what is actually going on here? Let’s take a closer look at the request and response for a user who has successfully completed the reCAPTCHA challenge.

If you look at the POST parameters for this request you can see that the captcha challenge has a value in the argument ‘g-recaptcha-response’. But when we choose not to complete the captcha challenge our request looks like this:

In this case the request does not contain a value for the parameter ‘g-recaptcha-response’. But both requests provide the same valid response from the server:

So what is actually going on here? The server isn’t checking for the parameter ‘g-recaptcha-response’ to have a value.

This is actually a more common issue than you might expect. Authentication vulnerabilities exist in many applications, even those that demand a high level of confidence from their user base. In May, Google had to fix a vulnerability that allowed for complete bypass of Google reCAPTCHA