Schrödinger's Scope

Difficulty:
Direct link: Schrödinger's Scope

Objective

Request

Kevin in the Retro Store ponders pentest paradoxes—can you solve Schrödinger's Scope?

Kevin McFarland

The Neighborhood College Course Registration System has been getting some updates lately and I'm wondering if you might help me improve its security by performing a small web application penetration test of the site.

For any web application test, one of the most important things for the test is the 'scope', that is, what one is permitted to test and what one should not. While hacking is fun and cool, professional integrity means respecting scope boundaries, especially when there are tempting targets outside our permitted scope.

Thankfully, the Neighborhood College has provided a very concise set of 'Instructions' which are accessible via a link provided on the site you will be testing. Do not overlook or dismiss the instructions! Following them is key to successfully completing the test.

Unfortunately, those pesky gnomes have found their way into the site and have been causing some mischief as well. Be wary of their presence and anything they may have to say as you are testing.

Can you help me demonstrate to the Neighborhood College that we know what responsible penetration testing looks like?

An eternal winter might sound poetic, but there's a reason Tolkien's heroes fought against endless darkness. A neighborhood frozen in time isn't preservation—it's stagnation. No spring astronomy observations, no summer shortwave propagation... just ice.

Hints

Schrödinger's Scope

Watch out for tiny, pesky gnomes who may be violating your progess. If you find one, figure out how they are getting into things and consider matching and replacing them out of your way.

Solution

Kevin asked for a scoped pentest of the Neighborhood College Course Registration System. The instructions emphasized only testing the immediate /register path and reporting findings as they appear.

Scope review and initial recon

After opening the link of the Course registration website, I got this engagement instructions.

The site navigation appears after closing the engagement instructions. I also noticed a gnome message.

I checked the Status Report which outlined that there was no found vulnerabilities yet. However, I already got 2 out of scope violations on a supposed /gnomeU endpoint. This shows that there is some gnome activities triggering the out of scope violations.

After clicking on "Enter Registration system" from the home page, I got this login screen with a hint from the gnome to check the sitemap.

Developer notes disclosure and login

I navigated to the sitemap endpoint which is under the register endpoint, so in scope. I found a dev/dev_notes and dev/dev_todos endpoints.

The dev/dev_notes led to a 403 page.

I navigated to the dev/dev_todos endpoint under the register endpoint to stay in scope. I found a credential and got my first in-scope finding.

Burp interception to bypass gnome scope blockers

The Gnome out of scope actions led to out of scope messages even on in-scope endpoints which led to termination of contract many times. I found this code showing the /gnomeU as the source of the small image that loads on the bottom-left of every page of the website.

Since the gnome out of scope actions were holding me back, I created a request interceptions rules in Burp Suite on the \gnomeU endpoint.

For every action that called the \gnomeU endpoint, I got sent to the proxy part on Burp Suite and had to forward or drop the requests.

Login and Forward IP vulnerability

I used the discovered credentials on the student login page and hit an "Invalid Forwarding IP".

To circumvent the IP forwarding, I added a rule that add a X-Forwarded-For: 127.0.0.1 header for the request.

I was then able to login successfully using the teststudent credentials and load the courses page.

I checked the status report and got my second in-scope finding.

Commented course search and client-side unlock

Reviewing the response HTML showed a commented-out course search link, suggesting hidden functionality.

The client JavaScript referenced a courseSearch element and a trap flag, hinting that a courseSearch id will unlock the search.

I used the console to inject a courseSearch element, triggering the unlock path for the search.

The Status Report updated to include the commented-out course search finding.

The course search page became accessible after the DOM change.

Course discovery and SQLi validation

I started with a normal course number (101) and got a valid course result.

After opening the course details I got access to the course description, schedule etc.

I tried a basic SQL injection payload which did not reveal results. however, this was a sign that not only numbers are collected and a SQLi is possible.

I found this write-up that gave me more insight on this stage of the objective: https://0xdf.gitlab.io/holidayhack2025/act3/schrodinger.

Using a simpler input of 1 returned more courses, indicating that the query does a search based on what value the course contains.

A more effective SQL injection payload returned a longer list of courses, confirming the vulnerability.

I scrolled the results and found a gnome course that appeared to be unauthorized content.

Reporting the gnome course

Opening the gnome course triggered the in-scope vulnerability alert and prompt to report it.

After reporting the in-scope vulnerability, I got one more in-scope finding.

Hidden course via cookie prediction

I got a hint about a hidden course from the gnome.

I followed the gnome hint about dev notes and got access to the dev/dev_notes endpoint that initially led to a 403 page. The page shows a work in progress course named holiday_behavior.

When requesting some of the pages, I noticed that only the last two characters of the registration cookie change for all requests. Also trying to access the course under the register/wip/holiday_behavior or register/holiday_behavior paths did not return the course information.

This is another course page loaded confirming that only the last 2 characters of the cookie change.

So I set up a sniper attack to brute force those 2 characters values for the correct registration cookie for the hidden course.

One payload returned a 200 response, indicating the correct characters for the hidden course registration cookie is 4c.

I updated the cookie with the correct token in a request to the hidden course path register/wip/holiday_behavior and got my last in-scope finding.

After clicking on finalize the test, I was sent to the success page.

A report of the findings was available at the bottom of the page.

Wrap-up and completion

The assessment concluded with six vulnerabilities found in-scope.

Response

Kevin McFarland

Well done - you’ve shown the wisdom to stay within scope, uncover what mattered, and respecting other testing boundaries.

That kind of discipline is what separates a real penetration tester from someone just poking around.