Bugs In Things – My First Bug Bounty – RedBubble.com

This post is about some vulnerabilities I discovered and reported in the e-commerce website Redbubble. They are a marketplace for independent artists, and I would like to say up front, not only how nice and professional they were in their response, but how nice it was of them to reward me with something for doing something that I love.

Also they have kick-ass art there.

I have talked before about information security, hacking etc. There are a couple of websites that provide access to something called “Bug bounty programs”. These are essentially what they sound like. People pay bounties for bugs you find.

That may sound like a win-win, but software vendors have traditionally been pretty sluggish about responding to vulnerabilities discovered in their products (no-one likes being told their baby is ugly). In fact there are multiple (maybe dozens) of instances where it has become public knowledge that a vendor has threatened a security researcher with a lawsuit if they go public with their bugs.

It’s 2016 though, and companies are gradually becoming more and more amenable to working with researchers instead of suing them. Responsible disclosure is where all stakeholders agree upon a timeline to disclose information about the bug, giving companies time to fix their products, and an assurance to researchers that it will indeed get fixed.

Full disclosure is where the researchers feel that the issue is so important that it should be immediately disclosed publicly to draw a lot of attention to the issue, so that vendors will fix their products as soon as possible, and people will patch their environments as soon as possible.

These websites are called Hackerone and Bugcrowd. They both offer companies the chance to engage large quantities of security researchers (who have signed up) to go hunting for bugs in their products. The researchers find bugs, and submit them to the sites using their inbuilt bug-reporting tools. The bugs are then reviewed buy the company, and if appropriate, a fix created and finally a bounty rewarded to the researcher.

This is for, some people, fantastic. You are legally allowed to try and hack stuff that five years ago in the USA would leave you with a Felony charge and perhaps 30 years of jail time. Progress! Many companies have their own official bug bounty programs that don’t use Hackerone or Bugcrowd, like Google, Facebook and just a couple of days ago, the Pentagon actually announced just such a program.

Companies find and fix security problems for a pretty cheap price. Researchers get to practice their craft on real live applications. If you are a researcher in a less developed nation, it is entirely possible to make a very decent living from bug bounties. Let’s not beat around the bush here,  bug bounty programs are a good thing.

Having gotten that out of the way, let’s get on to what I found at Redbubble.

I would also like to reiterate that the team that I dealt with at Redbubble were really excellent about responding to me in good time after I contacted them, and responsive about fixing the issues.

They didn’t have to do that at all, in fact they didn’t even have to reply to my initial email to their customer support team, they could have just silently fixed the issue and not responded, but the fact that they not only replied, but fixed the issues and then rewarded me too made me feel like they really care about the security of their users.

The reason this all came about was that I saw a post on a social media site from someone I used to work with. This person is an incredibly talented artist, and was just posting something that they had been working on recently. When I saw it, something just clicked in my brain and I felt my stomach drop inside me. It was a picture of an astronaut floating beyond an asteroid. You can see it on his page here.

For whatever reason, it just spoke to me, heavily, so I asked him if there was some way I could get a copy of it. He pointed me in the direction of his Redbubble page, I signed up, bought a print, sat back and eagerly awaited for delivery.

It arrived, but a week later, I received a “You may also be interested in…” type of email from Redbubble. Evidently there was a box in the signup process that I forgot to un-check. Down at the bottom of the link, there was an Unsubscribe button, as there usually is, so I clicked it, but just as I was doing so, I opened the chrome developer tools to see what was happening over the network. This was reflex based on my previous experience with unsubscribing from email lists which I wrote about here.

Nothing seemed out of the ordinary, but I thought for whatever reason that I would take a deeper look. I signed up for a test account, despite already having one assigned to my primary email address. During the signup process, you are asked for the usual stuff, username, password, email address etc.

I was entering a username, and got distracted by something else on the page, and shifted the focus of my mouse, and after a second the username field went red to tell me that the username was taken.

Looking in the console, I could see the sign-up page was making a GET request to “https://www.redbubble.com/signup/username_check?username=XXX” where XXX was the username to check. I made the above a link to demonstrate this. If you click it, you will get exactly what I saw being returned, a simple dictionary revealing if the username was taken or not.

username check

This started ringing some alarm bells for me, as that meant that username enumeration was completely trivial. All you would have to do is make a GET request to a specific url and check the response for the word “available”. In fact in a couple of minutes I had a python script up and running to do exactly that through a test set of usernames ranging from a-z, single characters only. Most of them were taken. I have included an excerpt below.

The only change you would have to make from the above is a “for name in list_of_usernames: do …” and you would be able to enumerate through all usernames, depending on how long you have.

Next I thought I would see what happened in the Chrome developer tools (F12)  when I signed up, rather than what was happening as I was trying to. I forgot to enter a password, so to see what kind of error was thrown, I just entered a single character. It went through fine.

Password length of 1 character (!).

Obviously you could have longer ones, but that really shocked me. I added it to my notes, and carried on digging. There is not really a whole lot you can do with an e-commerce site that is legal from a testing perspective, as modifying user data or attempting to complete fraudulent transactions are completely off-limits. I was essentially penned in to only things that I could do against myself on my computer.

I enumerated through various different vulnerabilities like reflected XSS attacks, stored XSS. The usual stuff. At some point I realised that I had not attempted any kind of session  handling or fixation testing.

Session testing is basically where the Redbubble server knows who I am, and continues to serve me pages that should only be visible to me. HTTP is a stateless protocol, so there has to me some way to identify each user to the server, so that I don’t see someone else’s account page or vice versa. This is usually done with cookies.

In fact it is usually done with cookies on the client side, and some kind of program on the server keeping track of which session belongs to which user. I will get assigned a cookie that makes no sense when a human reads it, like “BAhJIhkkMmEkMTAkellra0pENrdWIxcgY6BkVU” but somewhere on the server is a record telling the server “Every time you get a request with this cookie, that means it’s Hugo, so only show Hugo’s stuff to that request”.

The server has access to all the users account pages, but will only show a user theirs if the cookie they supply matches one it has itself assigned. That is the other key to this relationship; only the server can assign these cookies to people. There should be no way that an attacker can find out the cookies of other people, because if they could, they could then impersonate that user.

I have a plugin for Chrome called “Edit this cookie”, which does almost exactly what you would expect from the name. In fact I highly recommend it. It allows you a very simple interface to edit cookies for whichever site you are on, export or import, or set new cookies. A really great, and occasionally terrifying, exercise is to randomly set a new cookie for websites you go to as “admin=true”.

Also around Christmas time the cookie icon wears a little red bobble hat like VLC player.

I was exporting some cookies and importing others to see what would happen, when I accidentally missed the plugin button and just closed the browser. I reopened it, and after re-entering the url, I was directed straight to my account page. Now HTTP doesn’t know when I close or create a browser window, but this made me try to copy my cookies, logout from Redbubble and then go to my users public profile page. At this point I copied my cookies back into the browsers memory and reloaded the page.

I was logged in.

That meant that whenever a user logs out from the service, they are only logged out on the client side. The session still exists on the server side. In fact if anyone had my cookie, they could impersonate me. That was bad.

At this point I thought it might be cache or that Chrome stores the cookies in memory even if you are using Incognito mode. I retried the copying cookies and pasted them into a text document. I rebooted the computer to make sure there was no RAM artifacts, and tried pasting in the cookies again. I was logged in again.

So as far as I could see there were 3 vulnerabilities I had discovered in a relatively short amount of time. In fact, it was not at all a short amount of time. I had been so absorbed in this bug treasure hunt that I had in fact burned 5 hours in what seemed like the blink of an eye. This makes me think that I might really like this kind of thing. Or that I might be on some kind of spectrum. Or both.

I contacted Redbubble through their customer service email, and they responded the next day asking for clarification on the issues I had discovered. Things went relatively quickly from that point forwards, with Redbubble being very responsive and communicative. For the years I have been following security researchers disclosure efforts (at least those that became public) they have been filled with unresponsive or lawyer-happy vendors. This was luckily not the case for me.

The timeline for this occurred as follows:

  1. 2015-09-08 – Initial discovery of vulnerabilities and reporting.
  2. 2015-09-09 – Redbubble customer service responds asking for more information.
  3. 2015-09-10 – Information forwarded to customer service agent to send to engineering team.
  4. 2015-09-25 – Confirmation of issues and expected timeline of fixes.
  5. 2015-11-26 – Engineering team replied with fix for one issue, timeline for another issue and reasoning behind the last issue. Also included $50 voucher for use on Redbubble.
  6. 2015-11-29 – Communication with Redbubble regarding intent to publish blog about findings within 90 days.
  7. 2015-12-06 – Redbubble respond saying 3 months would be great.
  8. 2016-03-16 – This blog post is published.

This is the first time that I ever received a bug bounty, but I think it is absolutely something that should be considered by all companies that have a presence or business model that depends on the Internet. If you are considering a bug bounty, I would highly encourage you to move forward with one.

A word of warning though, make sure you have well laid plans in place for what to do with the Head of IT Operations at my job calls the “Avalanche of value” that you can receive through the process. Having a program in place is no use if you have no resources set aside to triage and remediate issues and bugs, develop fixes and roll them out to production.

I mentioned above in the timeline that Redbubble explained the reasoning behind one of the issues, which was the enumeration of usernames. To paraphrase their engineering team “We are a marketplace, so this is intended behaviour that users can be discovered, similar to Esty/Ebay etc”.

They are the people that make their product, so I am not going to tell them that they are wrong, and although I disagree to an extent (the more data an attacker has, the easier it is to enumerate or guess logins), I can see how it is completely reasonable to have the application behave in this way.

One thing that I learned through this process is always, always check for improper session termination whenever you are investigating a web application. Also that Redbubble have some ascii art hidden in responses every so often.


Also that sometimes, when you are essentially sending something to the server that may or may not be expected, to not take every single error message literally.

500 server room on fire

I fully intend to take part in Bugcrowd and Hackerone programs, at least in the very near future, and would encourage you to do so too if you like this kind of thing.

I hope you have a really great week.

Leave a Reply

Your email address will not be published. Required fields are marked *