Unveiling Hidden Dangers: An Unprotected Symfony Profiler Endpoint Leads to Critical Exposure

Introduction

In the ever-evolving landscape of web application security, the discovery of vulnerabilities can often be a race against time. Recently, I encountered a profound security oversight in an application, which served as a stark reminder of the importance of diligent security practices. This post details my journey in uncovering a critical endpoint in a web application exposed via Symfony framework.

The Discovery

The application, hosted at a specific IP address (redacted for security), presented itself as a typical web application based build using symphony framework. However, a deeper inspection revealed a critical flaw: the Symfony Profiler endpoint was publicly accessible without any form of authentication. This endpoint, typically used for debugging and performance monitoring, was exposed at https://[redacted]/_profiler/58feca?panel=request

In addition to it, the application also exposed Adminer on a different port within the host.

What Was Exposed?

In Symfony, the _profiler endpoint is part of the Web Profiler bundle, which is a powerful tool for development and debugging purposes.

The profiler page, a goldmine for any developer, turned into a potential nightmare due to this oversight. It provided comprehensive insights into the application’s server variables, which are generally hidden and secured. However, in this case, they were laid bare for anyone who stumbled upon this endpoint.

Among the exposed details were:

• AWS client IDs and client secrets
• MySQL Database Credentials
• GitHub usernames and passwords
• Azure client IDs and client secrets

Approach/ Methodology:

• Using one of my tool Katana to crawl the endpoint for any hidden js or any specfic endpoints.
• Results from Katana helped me to identify this profiler URL https://[redacted]/_profiler/58feca?panel=request
• As I am already aware that profiler could expose sensitive informations, so I have looked into it further and then identified the server variables section which exposed the sensitive credentials.

So now, I wanted to show an high impact after obtaining the credentials, therefore I tried first using AWS Client and Secrets to login to the AWS envrionment, but unfortunately the access keys were expired. Maybe they might have done the key rotation.

Then from Katana output, I saw we have the adminer mysql portal which is been exposed and we have sql credentials. So, I have logged in using the obtained credentials and got the admin access to the portal.

It should be noted, that this version of adminer 4.8.1 also has a RCE exploit available CVE-2018-12613. Due to the synack RoE, I haven’t proceeded to exploit further.

Addressing the Vulnerability

I have submitted my report to synack immediately and they have validated within next 1-2 hrs and happily got paid.

• By default, this profiler should only be enabled in the development environment, not in production, due to the sensitive information it can reveal.

• However, if for some reason you need to have the profiler active in a production environment, or if you want to ensure it’s secured regardless of the environment, you can implement access control to restrict access to the _profiler endpoint.

Lessons Learned

• Identify the technologies on which the application runs. Utilize tools like the Wappalyzer plugin to gain an idea.
• Use Crawler/Fuzzing tools to crawl/fuzz the endpoints, which will help in identifying certain endpoints.
• Always aim to demonstrate high impact in your report. For example, if I had only reported the credentials, I would have been paid only $250. However, by showing the impact through logging into the Adminer application, I managed to receive the full payout of $700 (based on Synack’s pricing model). Other programs might pay more.
• I wouldn’t have been able to use the credentials if I hadn’t discovered the /adminer endpoint. That’s why fuzzing and content discovery are very important.

I hope you guys enjoyed reading my blog.

Cheers!!