How I Discovered My First Bug: Worth $150 for Information Exposure Through Debug Logs (CWE-215)

Every bug hunter remembers their first win. Mine came while exploring the fascinating world of web vulnerabilities, and I stumbled upon a seemingly innocent debug log file left accessible on a website. This experience introduced me to the critical vulnerability of Information Exposure Through Debug Information (CWE-215). In this post, I’ll walk you through my journey, what I uncovered, how I reported it, and why even small oversights can have significant consequences.

During a routine scan of a WordPress site — https://example.com—I came across an interesting URL:https://example.com/wp-content/debug.log

Intrigued, I clicked on it. Bingo! A text file loaded, revealing sensitive debug information:

[13-Oct-2024 12:34:56] PHP Notice: Undefined variable $user in /var/www/html/wp-content/plugins/plugin-name/file.php on line 32
[13-Oct-2024 12:35:01] Database connection failed: User ‘admin’@’localhost’ access denied.
[13-Oct-2024 12:35:07] Warning: API key exposed in /wp-content/plugins/example-plugin/config.php

This was a jackpot for any hacker — an exposed debug log filled with critical information.

The vulnerability I found belongs to CWE-215: Information Exposure Through Debug Information. This issue arises when web applications leak internal information through debug logs. Some common details that attackers can harvest include:

File paths and source code referencesDatabase connection errors and usernamesAPI keys, tokens, and credentialsStack traces exposing the backend logic

Exposing such logs publicly is equivalent to handing a roadmap to attackers, giving them insights that can help them target the site’s weaknesses.

An exposed debug.log file might seem trivial, but it opens several attack avenues:

Exploiting Plugins or Themes: Debug information related to plugins can hint at known vulnerabilities.Brute-Forcing: Leaked usernames can help in brute-forcing login credentials.Unauthorized API Access: Exposed API keys can grant attackers unauthorized access to external services.SQL Injection Opportunities: Revealed database errors might provide clues about vulnerable queries.

After confirming the vulnerability, I prepared a responsible disclosure report with all the relevant details:

URL: https://example.com/wp-content/debug.logDescription: The file contains sensitive information such as API keys, database errors, and file paths.Impact: Information exposure that can lead to further exploitation of the site.Steps to Reproduce: Access the URL directly to view the contents.Recommended Fix: Disable debug mode on production or restrict access to sensitive files through .htaccess.

Soon after submitting the report, I received a response from the AirAsia Infosec Team:

“A fix has been deployed for this vulnerability. Could you please verify that you cannot reproduce the bug nor bypass the fix?”

I revisited the URL after the fix, and this time, the debug.log file was no longer accessible. Issue confirmed resolved! ✅

Here are a few key lessons from this experience:

Don’t Ignore the Basics: Even small vulnerabilities like information exposure can open doors for attackers.Keep an Eye on Debug Files: Logs that help developers can also help attackers if exposed publicly.Clear Reporting is Crucial: Providing a well-documented report ensures faster resolutions.Celebrate Small Wins: Every bug you find adds to your experience, so don’t undervalue minor findings.