Recon

While browsing Starbucks Singapore, I noticed a page loaded with content from a 3rd party site. Let’s call this site example.com in order not to disclose it. When I did some research on this site, I saw the same login page on card.starbucks.com.sg in the directory example.com/starbucks, and at this point I had two possibilities.

1. This application can be an environment where current developments of card.starbucks.com.sg are made and tested.
2. Or it may have been used as an old test environment and is in an idle state.

Both possibilities increased the probability of a bug here, but the main problem is that I did not know whether a bug I will find here would affect the production environment. To understand this, I created a user account at card.starbucks.com.sg and tried to log into example.com/starbucks with this account. BINGO! I was able to successfully login with the account I just created. Both applications seemed to be using the same authentication mechanism.

Exploitation

From this point I browsed example.com/starbucks and discovered an endpoint which does not exist in the production app. The POST data this endpoint received was as follows.

email=hacker@hacker.com

When I write the email address of the account I want to takeover in the email parameter here and send a request, I saw the partial information of the account belonging to that email address on my profile page. I could not fully takeover the account yet, and my password change request was not successful due to the invalid CSRF token generated in this application.

To get around this, I copied the PHPSESSID cookie value from example.com/starbucks to card.starbucks.com.sg and BOOM! I was able to see all the information belongs to victim in the production environment, the valid CSRF tokens generated here allowed me to change the password and I was able to completely takeover an account whose e-mail address I know.

Impact

Except for seeing all personal information belonging to users and completely taking over the accounts, if there is a loaded credit in the user account, these credits can be spent in Starbucks stores via the mobile application.

Multiplying the Reward

I came across two other test environments on example.com. Let’s call them example.com/starbucks2 and example.com/starbucks3. With my account at card.starbucks.com.sg, I was not able to login to either test environment. example.com/starbucks2 did not allow me to create a new account, so I tried my luck at example.com/starbucks3 and successfully created a new account. Things get a little complicated here, I will try to explain it as simply as possible.

I think the applications example.com/starbucks2 and example.com/starbucks3 were using test tables, so users in production could not login in these applications.

With the account I created at example.com/starbucks3, I was able to log in to example.com/starbucks2, but not card.starbucks.com.sg. However, the PHPSESSID I copied from example.com/starbucks2 was valid on card.starbucks.com.sg and I could use that account. Considering all the scenarios, I created a chain here as follows:

1. Create a dummy account with the victim’s email address at example.com/starbucks3. (Add to testusers table.)
2. At example.com/starbucks2, associate the account for that email with your own account via the same endpoint. (Associate the PHPSESSID with the email in the testusers table.)
3. Copy the PHPSESSID to card.starbucks.com.sg and takeover. (Takeover the real account of the same email address in the production users table.)

May 17th - Report Submitted
May 18th - Triaged
May 20th - Rewarded $4000 bounty
Jun 17th - Rewarded $2000 bounty as 1.5x multiplier

You can find Hackerone report here.
If you liked this article you can follow me on Twitter.