Overrun
Overrun's change-order endpoint authorises by parent project, but loads the child object by global id alone. Players who change one digit in the URL read change orders that belong to other project managers.
Room Description
https://dashboard.webverselabs-pro.com/challenges/overrun
Scenario
Overrun's contract change-order module shipped two sprints ago. The endpoint that opens a single change order is mounted under a project route — and the middleware on that route only checks that the calling PM owns the project. The handler then loads the change order by its global record id without re-checking that the change order actually belongs to that project. The bug has been live for weeks. The internal notes on a confidential change order at Harbour Point are about to be read by the wrong people.
Objective
Overrun's change-order endpoint authorises by parent project, but loads the child object by global id alone. Players who change one digit in the URL read change orders that belong to other PMs.
Initial Analysis
My my, another web application that looks expensiveeee! This is a project management application, and of course, IDORs are always present when project managers are involved. The landing page is just a registration page more or less.
We do not have an account given to us, so let's create a PM account.
Damn, the description to the left is already shutting down one attack vector which would be providing a role during registration.
Yep, we don't send a role parameter during registration, we can try of course, but it won't work so skipping that.
The landing page after registration has A LOT of buttons leading to places.
We have the following endpoints:
/site-log
/reports
/audit
/project/3
/projects/3/change-orders
Finding the bug
Well, that seems weird, a /project and a /projects endpoint? Let's check out /projects/3/change-orders first.
Hm, that bit at the bottom seems interesting?
About the record id: Each CO has a contract identifier (the CO number, e.g. CO-0007) and a separate global record id used internally and in deep-link URLs (/projects/3/change-orders/<id>). The record id is sequential firm-wide so finance and audit can reference any CO unambiguously.
I checked out the /project endpoint as well, just seems to be a general page about the change orders we are seeing in the current view anyways.
Let's open the first order we see on our page.
Okay, so for the project with the ID 3, we have CO-0007, CO-0008 and CO-0009 and we know IDs are sequential.
Exploitation
So uhm, what's stopping us from trying to open change orders with lower IDs than ours?
Apprently nothing, we for a fact know that this isn't ours. Now, what's interesting is that for the /project endpoint, if we try to do the same, it sends us back to the /dashboard. And if we try to change the ID for /projects from 3 to 2 or 1 for example we get Access denied.
Regardless, we already have our attack vector, the vulnerable ID, we just need to enumerate all the change orders, luckily there aren't many so when you land on the 4th ID, you can see the flag in internal notes.
