Exploiting Starbucks: How I Hacked My Way to Free Coffee

Exploiting Starbucks: How I Hacked My Way to Free Coffee

I think a lot of hackers share the same sentiment; I couldn’t do this without coffee. I bizarrely find myself most productive and doing my best bug bounty work at 3am. I don’t know what it is; whether it’s because that’s the only hour of quiet I get living under train tracks, or that’s how all hackers are portrayed in media and I’m just a walking stereotype. Whatever it is, it makes waking up in the morning difficult. Caffeine is my lifeline, I would have an IV of caffeine pumped directly into my blood on waking up in the morning if drinking it wasn’t such a pleasure.

There’s a Starbucks on the way to my local tube station, I think I must be in their top 10 customers. Because of this I ashamedly have a ‘Starbucks Rewards Gold Membership’ which entitles me to me amazing perks like; a discounted extra shot of espresso, a free pump of syrup, and a free drink on my birthday (It also means I’ve spent well over £250 there this past year).

What if it was possible to live the wish I made when blowing out the candle on my 5th birthday? For everyday to be my Birthday. Who needs candles and birthday magic, when I have Burpsuite.


Recon

When creating a Starbucks account we are sending a POST request consisting of a specific format of JSON data to the API endpoint: /api/v2/account/. A sample account creation request would look something like this:

Once we have an account created and authenticated our session is identified by a JWT.

If we attempt to attach a bogus partner card to our account, we generate a PATCH request using a similar formatted JSON data

/

Here we can see that if the API sees "**fakeId**" in the "id" it will default to using the TAsessionID JWT for authentication in the API. As we can also see, it takes an attributes field exactly like we use for signing up. So what if we send a PATCH request to /api/v2/account/ to try and change our "firstName".

name_field

Great, they’ve left the other fields in the account details unprotected.

Exploitation

With prior knowledge of Starbucks’ excellent birthday rewards policy, I changed my Birthday on my aforementioned gold account to 2 days in the future (an extra day just to be safe) and SUCCESS!

I was sent an email with a discount QR code for a Free coffee or Pastry. Time to cash in my reward and grab a free latte!

Potential Damages

Whilst it might not seem like such an impactful bug and on the surface only relate to Improper Authentication. Should hundreds of Starbucks gold members replicate the bug, it could potentially lead to thousands of pounds of losses for Starbucks.

Mitigation

  1. Implement server side validation on PATCH requests like there are on POST and PUT requests.
  2. Implement server side validation on certain protected fields (I.e "firstName")

Conclusion

Hopefully if you take one thing away from this writeup its this: always check the weird HTTP Requests. The POST and PUT methods were protected when updating any account details but the PATCH request had just been glossed over.

I only got one coffee before reporting this, as I didn’t want to take the piss at my local Starbucks and accidentally get someone fired. Now if you’ll excuse me I have a Latte to enjoy.


Update

Timeline:
  • Jan 28: Bug Submitted to Starbucks UK
  • Jan 31: Bug Acknowledged by Starbucks UK
  • Feb 11: Bug Fixed via a total block to PATCH requests to the /api/v2/account/ endpoint.
  • Feb 23: Medium Bounty Awarded for Improper Authentication

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

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