From Cross-Subdomain Cookie Reuse to Becoming Super Admin: An Exploit Chain Walkthrough
Hey there! A few days ago, while performing a penetration test on one of our client’s applications, our team encountered a scenario that’s definitely worth sharing. It involved cross-subdomain cookie reuse, which, when combined with broken access control, allowed us to escalate privileges and become Super Admins in another organization’s dashboard. Curious to know how it all played out? Let’s dive into it.
Understanding the Application
First let’s understand the application. The application that we were testing provide a whole subdomain to each organization that is using their service. So let’s say we have an organization named cyberpro151, then they will provide me a whole subdomain i.e. cyberpro151.target.com such that in this subdomain, you can create new users, see customers, view orders and remove existing users also if you’re a super admin. The application had following roles: Super Admin, Admin, Lab Staff User and Customer Support. Note that Super Admin can make more super admins also in the organization. As it was a grey box pentest, that’s why we were given credentials of SuperAdmin for 2 different organizations. For this specific blog, we’ll consider one organization’s subdomain as attacker.target.com and the other one as victim.target.com. Let’s move to the actual walkthrough of attack now!
Cross-Subdomain Cookie Exploitation:
With an understanding of how the application works, let’s examine the Proof of Concept (PoC) demonstrating how we leveraged cross-subdomain cookie reuse and broken access control to escalate privileges and become a Super Admin.
Firstly, we visited the subdomain victim.target.com and it had a login page like following:
Here, we entered the credentials of super-admin of attacker.target.com and captured the request using BurpSuite and it was like following:
POST /auth/sign-in?tenantId=<ID of Organization> HTTP/2
Host: api.target.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Firefox/138.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://attacker.target.com
Content-Type: application/json
Content-Length: 58
Origin: https://attacker.target.com
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Priority: u=0
Te: trailers
{“email”:”attacker@gmail.com”,”password”:”AttackersPassword”}
In response to this request, we got a response like following:
Now upon seeing this response, we thought what would happen if I go to victim.target.com, enter wrong credentials in login page, capture the login request and replace the response with the response that I got after entering the correct login credentials in attacker.target.com. This is what we call cross-subdomain cookie reuse that we use cookies that we got from one subdomain on the other subdomain to check if they can work there.
Keeping this scenario in our mind, we copied the response which I displayed in the above screenshot and went to victim.target.com. Here, that login page displayed again which was shown to you previously. We simply entered wrong credentials and captured the request using BurpSuite. The request was like following
We right clicked on this request and clicked on “Do intercept -> Response to this request” as shown in screenshot below
The original response upon entering the wrong credentials was like following:
We replaced this response with the response that we got from the login request of attacker.target.com upon entering correct credentials and the final look of the request was like following:
We forwarded this request and Bingo! We were authenticated to the victim’s subdomain as shown below:
There was this one problem here, that although we were authenticated, We were unable to view the data of victim’s subdomain and at this point, we thought that this whole attack has no impact but we thought what if there is restriction on reading the data only but not on adding data. In order to test this out, we went https://victim.target.com/app/administrator and it displayed an interface like following:
Here, we clicked on “Add New Admin” button and displayed following interface:
We filled in all the fields such that I selected the role as Super-Admin as shown in screenshot below:
Finally, we clicked “Create Admin” button. Now if security would’ve been implemented, then we wouldn’t have been able to receive any email but guess what? we received a mail on my email like following:
we again visited https://victim.target.com and entered these credentials and bingo! we were logged in to the the victim’s subdomain but this time, we had access to read the data also as shown in screenshot below:
Conclusion:
In conclusion, this walkthrough of cross-subdomain cookie reuse combined with broken access control highlights the risks in multi-tenant applications, where any attacker with Super Admin rights in their own organization could escalate privileges in another just by knowing the subdomain. Special thanks to HackerX007 for sharing this technique in his BSides Ahmedabad talk, which you can watch here: https://youtu.be/lE9I92YKnV8?feature=shared. If you have any questions or want to connect, feel free to reach out on LinkedIn or X.