$200 Business Logic Blunder In Sole Source Project

1 month ago 18
BOOK THIS SPACE FOR AD
ARTICLE AD

Jatin_Chudasama

Hey, dear bug hunters & researchers, welcome once again. In this writeup, we will discuss one of my findings I found few days ago. So without taking much time, straighten up your backs, roll up your eyes on the screen, and let’s get started. If you find any errors/mistakes, apologies :).

I was invited to a private program in January 2024. The program has a single application as the in-scope target for researchers to hunt on. However, the application involves a vast area to explore, with almost 10 different roles provided for testing. As I mainly focus on finding flaws related to access control and business logic, I found the target to be pretty competent according to my skills and knowledge for testing and hunting.

I don’t want to get too excited and hurry up to dive into finding bugs directly, as I have made this mistake many times before and ended up finding nothing. So this time, I decided to alter my approach a little bit, taking time to explore each functionality and action residing in the application, while making proper notes of them and running burpsuite in the background. I started in mid-January, and for the next few days, I just analyzed the application’s workflow and prepared notes.

Target Application Overview

I’ve already gave an overview about the target application in my last writeup, if you haven’t read that do checkout from here: https://medium.com/p/c8a94feb7cf3. Here’s a target overview snippet from that writeup.

Target Overview
Target’s overview

Vulnerability Description

The flaw was identified in the application’s sole-source procurement flow. Sole-source projects refer to projects where the owner selects a single supplier to provide goods or services without considering competitive bids from other vendors. This means that the owner chooses to work exclusively with one particular provider due to their uniqueness and special expertise.

While completing project details in the application, it prompts the user to select a sourcing type for the project, which includes multiple types such as RFP (Request For Proposals), RFI (Request For Information), Sole Source, and more. Upon selecting Sole Source, typically involves awarding a contract to a single provider without any competition.

Once the project details are completed, we cannot edit the sourcing type again. However, later I observed that we can still edit the matched supplier by removing them and reselecting another one even after completing the details. Here’s where the application poses a flaw. I identified that the GraphQL operation “createFact” was used to update suppliers, and we can add multiple suppliers in a JSON array in the POST body request. Once multiple suppliers are matched, it is possible to send invites, approve their proposals, and award them, which violates the entire approach of considering sole-source procurement.

Steps of Finding

1. The attacker user, with the project owner role, creates a project and, while completing details, selects “Sole Source” when prompted to select the sourcing type.

2. After completing the details, they navigate to the Project Detail tab to edit the matched supplier. They remove the matched supplier, then select another one and captures the HTTP POST request with the GraphQL operation “createFacts” in BurpSuite.

3. From the POST request body, attacker add multiple suppliers in a JSON array and sends the request, resulting in a successful 200 OK response.

4. Now, from the Suppliers tab, they send project invitations to them one by one. (Since it’s a sole project, the application does not allow sending invitations to all suppliers at once.) The suppliers accept the project invites and send proposals for the project.

5. Attacker owner receives the proposals and are able to approve and award all of them.

Timeline

01 Mar 2024: Reported
08 Mar 2024: Got First Response
11 Mar 2024: Triaged as Low & Rewarded $200

Since the project owner role holds the utmost authority within the application’s project role category and only attackers with the owner role can perform this attack. None of the other roles, such as editor, viewer-collaborator, or evaluator, possess this capability, resulting in a downgrade of the severity of the issue by the team.

Thank you for reading. Stay safe & secure. Happy Hunting. See you soon.

See-ya
Read Entire Article