Finding My First Information Disclosure Vulnerability

The journey to uncovering a significant information disclosure vulnerability began like many of my bug hunting sessions: with curiosity and methodical testing. In this detailed write-up, I’ll share how I discovered a vulnerability that exposed sensitive user information on a major platform participating in HackerOne’s bug bounty program, the steps I took to verify and report it, and the valuable lessons I learned throughout the process.

For security and compliance reasons, I’ll refer to the affected company as “the target” and have redacted specific URLs, endpoints, and identifying technical details.

Understanding Information Disclosure Vulnerabilities

Before diving into my discovery, it’s important to understand what information disclosure vulnerabilities are and why they matter. An information disclosure vulnerability occurs when an application unintentionally reveals sensitive information to unauthorized users. This might include:

• User personal data
• System information that could aid attackers
• Database structure or credentials
• Source code or configuration details
• Authentication tokens or session information

While sometimes appearing less dramatic than other vulnerability types, information disclosure vulnerabilities can provide critical stepping stones for more complex attacks or directly expose sensitive personal or business data.

Initial Reconnaissance and Discovery

Target Selection

I focused on a well-known platform with a public bug bounty program on HackerOne. The target had a wide attack surface with numerous features handling user data, making it promising for finding information disclosure vulnerabilities.

Methodology

My approach involved:

1. Mapping the application’s functionality
2. Identifying endpoints that process or display user data
3. Testing error handling mechanisms
4. Examining API responses for excessive information
5. Analyzing user profile and account features

The Discovery

While examining a specific user account feature, I noticed something unusual in the API response when requesting data about another user. The endpoint was:

GET https://api.[redacted].com/v2/users/[USER_ID]/profile

Normally, this endpoint would return basic, publicly available information about users. However, when manipulating certain parameters in the request, I discovered that the API was returning significantly more data than intended, including:

• Email addresses
• Phone numbers
• Account creation dates
• Internal user IDs
• Account preference settings
• Partial payment information

Verifying the Information Disclosure Vulnerability

To ensure this was a legitimate information disclosure vulnerability and not intended behavior, I performed several verification tests:

1. Created test accounts: I created multiple test accounts to verify the issue wasn’t specific to my account or certain user types.
2. Checked documentation: I reviewed the platform’s API documentation, which confirmed this level of data exposure was not intended.
3. Compared with UI: The web interface only displayed limited public information about users, while the API was exposing much more.
4. Tested access controls: I confirmed that the information was accessible without proper authorization.

The results consistently demonstrated an information disclosure vulnerability that exposed private user data contrary to the platform’s privacy policy and intended functionality.

Crafting a Comprehensive Vulnerability Report

Report Structure

I structured my HackerOne report to clearly communicate the issue:

1. Summary: Concise description of the information disclosure vulnerability
2. Impact: Assessment of severity and potential consequences
3. Steps to Reproduce: Detailed instructions to verify the vulnerability
4. Technical Details: Analysis of why the vulnerability existed
5. Supporting Evidence: Screenshots and response samples (with sensitive data redacted)
6. Recommended Fixes: Suggested solutions to address the vulnerability

Impact Assessment

In my report, I emphasized the real-world impact of this information disclosure vulnerability:

• Privacy violation for potentially millions of users
• Risk of targeted phishing campaigns using exposed data
• Potential violation of data protection regulations like GDPR
• Reputational damage if user data exposure became public

Example Request and Response

To illustrate the vulnerability, I included (redacted) examples of the API requests and responses:

REQUEST:
GET /v2/users/[USER_ID]/profile?detail=full HTTP/1.1
Host: api.[redacted].com
Authorization: Bearer [MY_TOKEN]

RESPONSE:
{
  "user": {
    "id": "u123456789",
    "username": "[redacted]",
    "email": "user@[redacted].com",
    "phone": "+1[redacted]",
    "created_at": "2022-03-15T14:22:31Z",
    "billing_info": {
      "payment_methods": [
        {
          "type": "card",
          "last_four": "1234",
          "expiry": "03/25"
        }
      ]
    },
    "settings": {
      "two_factor_enabled": false,
      "privacy_level": "strict",
      "notification_preferences": {
        // Additional sensitive settings
      }
    }
    // Additional sensitive data
  }
}

The Disclosure Process

Submission and Initial Response

I submitted the detailed report through HackerOne’s platform, marking it with an appropriate severity level based on the CVSS scoring system. Within 24 hours, I received acknowledgment that my report was being reviewed.

Triage and Validation

Three days after submission, the security team confirmed they could reproduce the information disclosure vulnerability and escalated it internally. They classified it as a “High” severity issue and added it to their remediation queue.

Resolution and Reward

The timeline proceeded as follows:

• Day 1: Report submitted
• Day 3: Vulnerability confirmed by security team
• Day 7: First patch deployed (partial fix)
• Day 14: Complete fix implemented
• Day 16: Fix verified and bounty awarded
• Day 30: Permission to write public disclosure granted

I was awarded a $2,500 bounty for identifying this information disclosure vulnerability, reflecting its significant impact on user privacy and data security.

Technical Analysis: What Went Wrong

Without revealing proprietary details, the root cause of this information disclosure vulnerability appeared to be:

1. Insufficient authorization checks: The API endpoint was validating authentication but not properly checking authorization for accessing detailed user information.
2. Parameter handling issues: The detail=full parameter was intended for internal use or when users viewed their own profiles, but the access control logic failed to restrict its use when accessing other user profiles.
3. Excessive data exposure: The API was returning complete user objects rather than filtering the response based on the requester’s permissions.

The fix implemented by the security team addressed these issues by:

• Adding proper authorization checks for detailed user information
• Implementing response filtering based on user relationships
• Restricting certain parameters to administrative roles only
• Adding additional logging and monitoring for sensitive data access

Lessons Learned from Finding an Information Disclosure Vulnerability

For Bug Hunters

1. Check parameter variations: Testing different parameter combinations often reveals information disclosure vulnerabilities that aren’t apparent with default values.
2. Compare interfaces: Differences between API responses and UI displays can highlight unintended information exposure.
3. Create detailed reports: Clear, comprehensive reporting significantly impacts how quickly vulnerabilities get addressed and bounties get awarded.
4. Think about impact: Articulating real-world consequences helps security teams prioritize fixes appropriately.

For Developers

1. Implement consistent authorization: Authorization should be checked at every level of the application.
2. Filter response data: Always filter API responses based on the requester’s permissions.
3. Be cautious with parameters: Parameters that control response detail levels should be carefully restricted.
4. Adopt the principle of least privilege: Only return the minimum data necessary for the specific function.

Conclusion: The Value of Responsible Disclosure

Discovering this information disclosure vulnerability reinforced my belief in the importance of responsible disclosure and bug bounty programs. By partnering with companies through platforms like HackerOne, security researchers can:

1. Help protect user data and privacy
2. Assist companies in improving their security posture
3. Receive recognition and compensation for their work
4. Contribute to a more secure digital ecosystem

For those new to bug hunting, information disclosure vulnerabilities represent an excellent area to focus on. They often require more logical thinking than technical expertise, making them accessible entry points into the field of security research.

By methodically examining how applications handle and expose data, you too might uncover significant vulnerabilities that protect user privacy and earn recognition for your security skills.

---

This write-up has been approved for publication with sensitive details redacted. The vulnerability described has been fully remediated. Always conduct security research only on systems where you have explicit permission to test.