How a Unique Combination Opened the Door to an IDOR

Hello everyone! This write-up is part of my IDOR Diaries series, where I share insights on the various IDOR vulnerabilities I encounter during my vulnerability hunts.

Checkout my previous write-ups in this series

Lets dig in !!

As usual, I was hunting in a program with a limited scope, focusing on a SaaS application. After authenticating in the application, I began exploring its features, specifically testing the ‘View My Agreements’ functionality related to an agreement-signing feature. This feature allowed users to check and view their current agreements. The application was well-secured with JWT-based authentication, and most resources were hosted on S3 with signed URLs. However, this particular endpoint’s resources were not hosted in an S3 bucket; instead, they were hosted separately.

Domain e.g: useragreements.example.com

The Sample Agreement stored location url was similar to below HTTP Request

If you request this URL, it surprisingly displays the specific PDF without any authentication.

Sample URL: https://useragreements.example.com/tenant/signedpdfs/020456760124

Since the URL ends with a pattern of digits, I tried brute-forcing the digits, but I didn’t receive any valid responses. Instead, the response returned was “NotFound.” However, I didn’t give up at this point; I started analyzing the URL further.

I generated more sample PDFs to check how this number pattern was assigned. Then, I noticed an unusual combination within the digits.

URL Analysis
Let’s take three sample PDFs generated for this proof of concept (POC). They look as follows:

As you can see, we can break this number pattern into two sections.

Whereas the pattern generates Part 01 as a dynamic value, Part 02 remains the same.

I then brute-forced the Part 01 value, thinking I had cracked their pattern. However, I only retrieved my own agreement samples and no unauthorized ones.

After further examination of Part 02 of the pattern, I cross-referenced the Agreement Signed Date with these values and realized that “0124” represents “01” as the month and “24” as the year!

I began by changing the month value to brute-force, incrementing each month and brute-forcing Part 01.

The brute-force patterns would look like:

1st Attempt

2nd Attempt

Using this method, I was able to find many PDF agreements containing Personally Identifiable Information (PII) such as Social Security Numbers (SSNs), addresses, names, and dates of birth.

Although this instance was specifically created for a Bug Bounty Program, this misconfiguration allowed access to production data of actual customers.

I reported this vulnerability promptly, and a temporary fix was implemented by adding an authorization token for each request. Later, the entire functionality was migrated to Amazon S3 with signed URLs, providing secure, temporary access and effectively mitigating the risk of unauthorized access to sensitive documents.

I always find these kind of vulnerbiltiies interesting by examing how developers find creative ways to implement these kinds of patterns.

In fact, I recently encountered a similar vulnerability, which you can read about in my write-up below, detailing the discovery process, analysis, and the steps taken to address the issue effectively.

Thank you for reading my write-up! I’ll be back soon with another one. Happy Hacking !!