Baby BoneChewerCon: Unleashing the Devil in the Debugging Details

Introduction:

In the bustling world of cybersecurity, there's no such thing as 'routine maintenance'. With the upcoming event "Baby BoneChewerCon" sending the website into maintenance mode, an unexpected opportunity has come knocking on our doors. The devil seems to be tempting us with an intriguing hint - the debugger is still enabled in production. What secret could it be hiding? Let's dive in!

Machine name: baby BoneChewerCon

Difficulty: Easy

Category: Web

DESCRIPTION

Due to heavy workload for the upcoming baby BoneChewerCon event, the website is under maintenance and it errors out, but the debugger is still enabled in production!! I think the devil is enticing us to go and check out the secret key.

No Code, No Problem:

After initializing the machine, we procured the IP address to explore this mystery. Interestingly, unlike our previous adventures, there was no source code this time. An intriguing start!

Reservation Trials:

With an option to 'Make a Reservation' under your name, we decided to test it out. We attempted to make a reservation using the name 'test' and intercepted the request with our trusty Burp Suite.

However, we were greeted with an unexpected error:

Symfony \ Component \ HttpKernel \ Exception \ MethodNotAllowedHttpException

The POST method is not supported for this route. Supported methods: GET, HEAD.

Debugging Delights:

While an error like this might seem like a dead-end, in our case, it turned out to be a treasure trove of information. The debug log revealed the application's environmental details, including GET Data, POST Data, Cookies, Server/Request Data, and Environment Variables. Notably, amidst all these details, we found our elusive flag in the APP_KEY Environment Variable - "XXXXXXXXXXX".

Server Error Handling: A Brief Explanation:

It is essential to handle errors in a server-side script carefully to avoid exposing sensitive information. In this case, a MethodNotAllowedHttpException was thrown, indicating that the POST method was not supported for the route accessed. The exception handling was not designed securely, resulting in the entire environment data, including the secret APP_KEY, being exposed. This flag's discovery illustrates a classic example of a server error handling vulnerability, where insufficiently protected error handling can lead to unauthorized information disclosure.

Conclusion:

With the conclusion of our thrilling adventure into the depths of "Baby BoneChewerCon", we've seen how the devil is indeed in the details. The erroneous exposure of a debugger in a production environment allowed us to discover the precious flag. As we savour our victory, it's a sobering reminder of the importance of secure error handling and the potential risks that even a simple maintenance window could pose if not managed correctly. Remember, in the cybersecurity world, even debuggers can turn against the debugger!