From JavaScript Analysis To UUID Pattern Exploration Revealed a Critical IDOR!

Hey everyone! After a little break, I’m back and excited to share an amazing story about finding a serious vulnerability. This one’s a real gem, and I think you’ll find it really interesting!

Let’s dive right in!

my investigation begins with a government portal offering sensitive services to users. To protect the organization’s identity, I’ve tweaked the details a bit, but the essence of the story remains. So, buckle up and let’s get started!

I started by diving into the JavaScript files of the site. Since it’s built on React, many endpoints are accessible on the client side. After discovering some vulnerabilities in the JavaScript files, I tried collecting more files using various methods, but came up empty ):

Here’s a quick tip: When you open a site and check the Dev Tools, you’ll see the JavaScript files loaded by your browser. However, this isn’t the complete picture. Some files might be hidden or loaded dynamically, such as those for admin functions.

Determined to find these hidden gems, I employed some tricks to extract as many JavaScript files as possible. Despite my efforts, I wasn’t having much luck ):

Then I noticed a pattern in the file names, like users.js, customer.js, and static.js. This gave me an idea: what if I tried fuzzing the JavaScript file names?

Most of us are familiar with path guessing or fuzzing, but have you ever thought of applying fuzzing to JavaScript files?

That’s exactly what I did. Upon noticing the file naming pattern, I compiled a list of possible JavaScript file names based on the site’s nature. With the help of my best friend ChatGPT and a tool called RSMangler I created a wordlist with potential patterns for the site.

I ran the fuzzing process and, to my surprise, discovered a new JavaScript file named Reports.js.

Inside Report.js, I found an endpoint on the client side that allowed me to modify (my own) government documents via an API request. Exciting right? But the real fun was just beginning.

Never trust UUIDs (:

Upon examining the API request, I saw parameters like RequestId in the path and id in the JSON body. It became clear that the backend used UUIDs to identify user requests. I was curious if changing UUIDs could let me alter documents. So I created a second account, obtained its UUID, and tried updating it using my first account. I was able to do so, which indicated an IDOR vulnerability. However, since UUIDs are generally non-guessable, this might not be directly exploitable ):

But I didn’t stop there. I investigated the structure of the UUIDs further, as sometimes there might be misconfigurations. I made several requests and extracted UUID values for different requests. To my excitement, I noticed that all the UUIDs followed a specific pattern, such as:

f6b168b5-A805-ef11-A832–005056066af713a6d3c4-Ab05-ef11-A832–005056066af7972a6aad-Ab05-ee11-A832–005056066af7b542816d-Ab05-ef11-A832–005056066af7

As you can see, all UUIDs followed the same pattern except for the first segment, which was variable. I was thrilled to discover that the UUID pattern was consistent across all accounts!

Armed with this information, I could update any government document for anyone by simply guessing the first part of the UUID. And with no rate limits on the API, it made the process quite straightforward.

Key Takeaways:

Don’t limit your analysis to accessible JavaScript files — search for hidden ones too.Never trust UUIDs — they can be deceptive!

And there you have it! From analyzing JavaScript files to cracking UUID patterns, this journey led to discovering a critical IDOR vulnerability. I hope you found this tale as intriguing as I did.

If you enjoyed this story or learned something new, don’t forget to hit that like button and share it with your network!

X\Twitter
https://twitter.com/omarzzu