How Unguessable IDOR Worth me €1000 On Intigriti

2 months ago 39

BOOK THIS SPACE FOR AD

ARTICLE AD

Welcome back! I’m Manan Sanghvi, an Engineering Student and Ethical Hacker (Bug Bounty Hunter).

Recently, I was hacking on one of Intigriti’s private program, It was a medium scope target. Let’s say the target was xxx Organization.

I started by gathering all the subdomains within the program’s scope. Then, I used several tools like httpx-toolkit, Waybackurls, Katana, and Gauplus to collect as many endpoints as possible.

Now after gathering it, first task is to remove duplication of the parameters. So, therefore I used uro and urless tools. (You can find easily on Github).

Here’s how I did it:

Collecting URLs:cat subs.txt | httpx-toolkit -o urls.txt

cat urls.txt | waybackurls > wayback_urls

cat urls.txt | katana -o katana_urls

cat urls.txt | gauplus > gauplus_urls

2. Filtering out duplicates: After gathering URLs, I had to clean up the list to remove duplicates and unnecessary parameters. For that, I used uro and urless tools. Here’s how:

cat wayback_urls katana_urls gauplua_urls | sort -u | uro | urless > filtered_endpoints.txt

Even after cleaning, I still had a thousands of endpoints. So, the next step was to look for API endpoints manually one by one, especially since I love finding IDOR (Insecure Direct Object Reference) vulnerabilities in APIs. I did this by searching for /api/ paths:

therefore I searched like this:

cat filtered_endpoints.txt | grep /api/

After reviewing the results, I found a few interesting endpoints like:

https://xxx.com/api/payment-site/payment-{unguessable_ID}/start
https://xxx.com/api/payment-site/payment-{unguessable_ID}/start

This payment API endpoint was exposing sensitive data such as UserId, Payment Method, Order ID, Amount, and even masked Credit Card details. My first thought was: “MAKE IT RAIN, Another Bounty Is Coming!”

So, I just reported the vulnerability, the triager also asked me: This looks like a classical IDOR. How did you guess the UUIDs?

Here is your answer:

The triager was quite impressed with my method! 😏 They even discussed the issue with the company to understand its impact more thoroughly. While the payment ID was unguessable, which reduced the immediate risk, the exposure of sensitive transaction data was still a significant concern.

Ultimately, the vulnerability was accepted as a high severity issue rather than a critical one. The reasoning was simple: although the ID was unguessable, the lack of proper authorization still left the system vulnerable, making it a serious issue that needed fixing.

Even if your target’s scope is small, don’t lose hope. You can still Hack into it. Always aim to explore parameters and functionalities that might not have been tested by other Hackers yet.

I hope you enjoyed this write-up! If you found it helpful, feel free to connect with me on LinkedIn and Twitter.

Follow Me On Linked in (Most Active):

https://www.linkedin.com/in/manan-sanghvi-799863176/

Follow Me On Twitter:

https://twitter.com/An____Anonymous

Thank You.

Read Entire Article