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.
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.
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.
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.
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.
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:
May 17th - Report Submitted
May 18th - Triaged
May 20th - Rewarded $4000 bounty
Jun 17th - Rewarded $2000 bounty as 1.5x multiplier