From No to Go — Uninvited Access To Invited Projects

Hey Folks..! Hope you all are good. Happy to be back again after a long time :) Today I’m going to share a bug I found a few days ago. So, without wasting much time, take a deep breath and stay tuned till the end. Kindly ignore any mistakes, let’zzzz Gooooooww.!!

Overview of the target

Let me first give a brief introduction about the target.
The target application is an autonomous sourcing platform that allows large businesses and organizations to use advanced technologies, particularly AI to automate and optimize the procurement process. Application has different account roles. However, for this finding, we have to understand 2 major roles — Project and Supplier Roles. No rocket science to understand what these roles are about. Simply, users with project roles can create, update, or view the projects & invite suppliers for their projects, and users with supplier roles can view the invited project details, accept or reject the project invitation sent by the project owners & send proposals for the projects.

How I Identified The Vulnerability

After a few days of hanging around the application interface, it was a decent finding for me to spot. I was testing the invitation process between project owners & suppliers and observed that once the supplier rejects the project invitation, they can not view any project details nor they can re-accept the invitation, and the project owner also can not send a re-invite to them. This means the supplier has only access to details till they decline the project invite.

Looks eye-catching at this point and the very next moment I realized - what if I can access project details now? Is it possible or not? The application is using graphQL and after reviewing the HTTP history I’ve found a graphql operation ‘briefView’ which uses variables — workspaceId and projectId to fetch project details. Later, I noticed when supplier opens the project in application the URL path contains the same UUIDs as mentioned in operation briefView variables. I declined the invitation and captured a request in burpsuite with operation briefView from another project details & changed both variables. Booom!!! I got HTTP status 200 OK with the response body disclosing project information.

Steps To Reproduce

Project owner creates a project, completes the details, and invites supplier to their project.Supplier receives invite & access to project details, then they note down the projectId and workspaceId from URL & declines the project invitation.From the Projects tab, supplier opens another project and intercepts the graphql request with operation name ‘briefView’ in burpsuite by clicking Details button and send it to the repeater tab.Changes the workspaceId and projectId to rejected project. Got access to all the project information. Even if project owners make any changes or updates later, supplier can access that.

Impact

The flaw arises due to inadequate authorization checks on graphQL operation ‘briefView’. It affects project confidentiality, allowing unauthorized access to sensitive information or updates in project details after declining an invitation.

Timeline

22 Jan 2024: Reported

25 Jan 2024: Got First Response — Requires Additional Info

26 Jan 2024: Provided Additional Info

26 Jan 2024: Triaged and Rewarded $$$💰

That’s it for today. Thank you for reading. Happy Hunting. Stay Safe-Stay Secure. Signing off till the next time!!! 🤝

Taaaddaaa :)