Skip to main content

Automatic information enumeration - Corporate information

Need​

Prevention of automatic enumeration of corporate information

Context​

  • Usage of C# for building robust and scalable applications
  • Usage of _context for managing application state and data sharing
  • Usage of Findings for analyzing and presenting data insights
  • Usage of IActionResult for handling and returning HTTP responses in a structured manner
  • Usage of NotFound for handling 404 errors in a web application
  • Usage of the Ok library for handling HTTP responses

Description​

Non compliant code​

[HttpGet("{id}")]
public async Task<IActionResult> GetFinding(int id)
{
    var finding = await _context.Findings.FindAsync(id);

    if (finding == null)
    {
        return NotFound("Finding not found");
    }

    return Ok(finding);
}

The above code is an example of an ASP.NET Core action method that is vulnerable to automatic information enumeration. The action method is designed to retrieve a specific "finding" from a database based on its ID.

The vulnerability lies in the different responses that are returned when a finding is found versus when a finding is not found. If a finding with the given ID exists, the method returns the finding. However, if a finding with the given ID does not exist, the method returns a message saying "Finding not found".

An attacker can use this difference in responses to enumerate system information. By making repeated requests with different ID values, the attacker can determine which IDs exist in the system and which do not. This allows the attacker to gather information about the system that they should not have access to.

This vulnerability could be exploited to reveal sensitive information about the system, such as the internal structure of the database or the total number of findings in the system. It could also be used as a stepping stone for more serious attacks, such as SQL injection or brute force attacks.

Steps​

  • Avoid providing different error messages for existing and non-existing finding IDs.
  • Use a generic error message for all not found cases to prevent information enumeration.
  • Ensure that the response does not reveal any sensitive information about the system or the finding ID.

Compliant code​

[HttpGet("{id}")]
public async Task<IActionResult> GetFinding(int id)
{
    var finding = await _context.Findings.FindAsync(id);

    if (finding == null)
    {
        return NotFound("Resource not found");
    }

    return Ok(finding);
}

The above code is a revised version of the original vulnerable code. The vulnerability was that the system was providing different error messages for existing and non-existing finding IDs. This could potentially allow an attacker to enumerate system information by trying different IDs and observing the responses.

The fix for this vulnerability is to use a generic error message for all cases where a finding is not found, regardless of whether the ID exists or not. In the revised code, the error message has been changed to "Resource not found". This message does not reveal whether the ID exists or not, thus preventing information enumeration.

Furthermore, the revised code ensures that the response does not reveal any sensitive information about the system or the finding ID. The only information returned in the response is the finding itself if it exists, or the generic error message if it does not. This ensures that even if an attacker tries to probe the system by sending different IDs, they will not be able to gain any useful information.

References​

Last updated on