Account Takeover via Access Token Leakage

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:

tuhin1729

Introduction:

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
Host: services.target.com
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-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://bo.target.com/
Content-Type: application/json
accessToken: 795b74eXXXXXXXXXXcba9abd3beaa3ec40b5d3ed
Content-Length: 213
Origin: https://bo.target.com
DNT: 1
Connection: close
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
{"company":"DSPH","domain":"https://darksocietypenetration.com","cellphone":"+91-83xxxxxx36","companySize":"2","businessSector":20,"logo":{"height":0,"base64":"","square":true,"width":0}}

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.

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:

tuhin1729

Then accessToken is getting leaked in the Referrer header via the token parameter.

So what would be the attacking scenario?

  1. Victim is creating a manual template.
  2. Victim adds an image to his template from 3rd party website.
  3. 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:

tuhin1729

Timeline

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.

Bug Hunter❤ Cyber Security Researcher😎 Ethical Hacker 😍 Follow me on instagram for bug bounty tips: https://instagram.com/tuhin1729