How a little modification of a request parameter led to Unauthorized Access to Private Workspaces
This blog was originally published here by Mohamed Ali
Hi, glad you are here 👋,
In today’s write-up, I will talk about a vulnerability I discovered in a PBB in Bugcrowd, where a malicious admin could be able to access a private workspace only accessible by the owner.
First of all, the target was one of these targets that used to manage all of your social media accounts ex: (pinterest, instagram, twitter, etc..) and you can establish several workspaces for different usages, for example one workspace to manage your brand, your work on the social media account, another different workspace to manage your personal/private social media account etc.. each workspace has it’s own unique UUID & id And for sure, each brand is separated, users/admins in brand_1 can’t access anything in brand_2, only the owner of the two workspaces/brands can.
Starting the discovery
After spending 15 days with this target, I came to an endpoint that takes the UUID of a brand and retrieve all general info about this brand, looks good, what will happen if the admin of brand_1 tried this endpoint with the brand_2 UUID ?, and it did work!
lso, after some checking, I discovered that if some additional parameters were added, the admin in brand_1 can edit some info of brand_2, like its name, timezone, etc. At this point, there are two problems
- This request depends on a workspace UUID not a normal, easy guessable ID
- still the info retrieved is not so critical, and the actions could be done — changing the name and so on, is not a big deal to report it
Solving problem 1 - ( access the private workspace easily )
If you take a deep look at the response retrieved, you will notice that the first two parameters are ID and UUID Take a closer look, you will see the UUID is the same UUID In the request Body, so now did you get what the next step we are going to check?
You got it right, what will happen if we change the request parameter from uuid to id and give it the id value instead of the uuid value?
AND yes, alhamdulillah id did work with the same response!
So, now the attacker would only fuzz an easily guessable ID with this new request formula, if private workspace exists with the associated id it’s info will retrieved, it not -> 404 not found (Problem 1 solved).
Instead of reporting this little issue immediately — which would get p4 at best, I digged deeper into the requests and the functionalities of the web app, to take an advantage of this simple idor.
Solving problem 2 - ( increase the small impact )
After trying to investigate all the functionalities and their requests structure (I hope I didn’t miss anything), with the help of the private workspace uuid Retrieved from the previous step, I was able to :
- Access the info of the social media accounts associated with this private workspace
- Create a permanent, unremovable link to access the workspace and see all the media published or even the ones that haven’t been published yet and are still saved as drafts
Note that this one is so critical, as these workspaces maybe used to publish personal images/reels on the social media, so to be able to fully access them is for sure not desired.
Note that this one is not only giving the attacker the ability to see private/personal media released/saved on the private workspace, but also it opens the door for the attacker for two more additional attack vectors, which are:
- Prevent the owner from using the Image editor feature on all of their media types using
/api/<path_1>/<path_2>/generate-<endpoint>endpoint, That’s happening because the new edited image stored in the default upcoming empty s3 bucket, so the attacker could store this place by adding another random data (image, reel or video) in it, and when the owner try to edit any of their images, reels or videos, the GUI will freeze, and under the hood that’s what happen :
- steal all their media content using in this workspace using
/api/<path_1>/<path_2>/<container_id>
• • •
Reported At - 02 Apr 2025
Triaged As P2 At - 17 Apr 2025
Alhamdulilla at 28 Apr 2025 → severity Changed from P2 to P3 by customer and get rewarded
To add your blog, send an email to hello@bugbountydirectory.com
