Hello guys! My name is Tuhin Bose (@tuhin1729). I am currently working as a Chief Information Security Officer and Infosec trainer at DSPH. In this write-up, I am going to share one of my interesting findings. So without wasting time, let’s start:
Basically the target was a marketing automation website where you can automate your marketing stuffs efficiently. Let's call it target.com. I have already found more than 10 bugs on the target and earned $$$$ from there.
Now while testing the profile update feature, I came across with this interesting request:
PUT /api/account/general-info/ HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
They are using accessToken header for changing the profile details (For other authenticated actions, there is no such header). I quickly changed the value of accessToken header with my 2nd account and my 2nd account’s details were changed. I tried to add the accessToken header in other authenticated requests and it got successful and 2nd account’s details were changed. While doing more research on this, I have discovered that the value of accessToken is static i.e. accessToken is same even after logout. That means, if somehow I can get the accessToken of victim, I would be able to takeover his complete account. But the value of accessToken header is non-guessable so I thought to find a way to get victim’s accessToken. But at that time, I was unable to do so. After 3 – 4 days of hunting, I forgot about that and started hunting on other functionalities.
Getting Victim’s accessToken
In the website, under email marketing, there is a section where we can make our own email templates. While testing that feature, I tried to upload an image file in the email. There are 2 ways to do so either from my device or via an image url. I tried some DoS, SSRF, XSS and file upload tricks. But it seems that they have a strong file type validation. Also they are fetching the image from client side so SSRF is not possible. Now when I tried to use my burp collaborator’s link to see the request, I noticed an interesting thing:
Then accessToken is getting leaked in the Referrer header via the token parameter.
So what would be the attacking scenario?
- Victim is creating a manual template.
- Victim adds an image to his template from 3rd party website.
- The 3rd party website owner (or employees) gets victim’s access token (from their logs) and can able to takeover their complete account.
I quickly made a POC and send it to them. After one week, they replied me:
06/05/21 — Reported Vulnerability
14/05/21 — Replied with the bounty email
If you want to learn Bug Bounty Hunting, you can enroll in our course from here.
Follow me on Instagram: @tuhin1729
Thanks for reading. I hope you enjoyed this blog.