Findings Series: User Enumeration
Contents
Description
User Enumeration occurs on web applications when there are discrepancies in responses received from the application when sending a valid versus invalid username. User enumeration is typically found in authentication and password reset processes. When an authentication attempt on a web application fails, it might be helpful to tell a legitimate end user "Username does not exist" if they misspelled their username. This would prevent a legitimate user from having to worry about whether or not they misspelled their username or their password, ideally facilitating a quicker login. However, telling a threat actor which usernames do not exist will also indirectly reveal which usernames do exist. This can help an attacker generate a list of valid usernames that can be leveraged in the form of password sprays or phishing campagins. This vulnerability can occur anywhere a username can be provided by an end user, including password recovery forms.
Classification
User enumerations are trivial to exploit and have the potential to greatly assist a threat actor if certain other vulnerabilities are present. Therefore, this finding is typically rated with a High Probability, indicating that its likely that this could be identified by an adversary. Since the actual impact that this finding could have on the application and supporting environment varies, the Impact rating could be as low as Informational to as high as Medium.
Probability
Impact
High
Informational - Medium
Classification Criteria
User Enumerations are generally an Informational finding unless the following characteristics also exist:
- The application usernames match the email format of the employees at the company.
- The application does not have a login threshold for authentication attempts.
- The application enforces a weak password policy.
The combination of these additional vulnerabilities can result in a successful foothold should a threat actor make a concerted effort to breach the web application.
Examples
Visual Errors
The differences in application responses can be present in various ways. There may be scenarios where a visual message states something to the effect of "Username not found" when an invalid username is submitted. An example of this is shown below, taken from the Microsoft Outlook login page:
Attempting to authenticate to Outlook using an invalid username results in an error stating that there's no account associated with the submitted username.
Non-Visual Errors
There are also scenarios where non-visual differences in the response can identify valid versus invalid usernames. These differences can occur in API responses where an adversary can use messages returned from the API to determine whether the username is valid, even if the actual error presented to the user is the same. For example, consider the following responses:
Valid username submitted:
{
"error":"invalidCredentials",
"thrown":"2023-09-05T15:32:02.008Z",
"message":"The email or password you entered is incorrect!"
}
Invalid username submitted:
{
"error":"invalidCredentials",
"detail":"passwords do not match",
"thrown":"2023-09-05T15:32:05.942Z",
"message":"The email or password you entered is incorrect!"
}
While the actual message is the same in both instances, the API returns the additional detail field. This field contains information that the passwords do not match. Since this message is only returned when the username is valid, a threat actor can create a list of valid usernames by checking the response for the detail field.
Timing Differences
When error messages or application responses don't yield identifiable differences that can be used to enumerate valid accounts, there are still additional test cases to perform to determine whether user enumeration is possible via timing attacks. A well-known example of this exists in Microsoft Outlook Web Application (OWA). When probing an OWA application, an attacker can utilize an identifiable difference in application response times to determine whether the account exists in the application. If the submitted username does not exist, the application takes significantly longer to respond than if the username does exist.
Output from msmailprobe against an OWA instance showing valid accounts being identified via response time differences.
Using a tool such as msmailprobe, attackers can enumerate valid users against OWA applications. For custom applications where no current tooling exists, an attacker can review the application response times in Burp when sending requests via Repeater.
Remediation
If User Enumeration is reported when testing your web application, the following actions may be recommended, depending on the specifics:
- Change the error displayed during failed authentication attempts to something more generic, such as:
- "The credentials provided do not match our records."
- "Login Failed"
*"Invalid Login"
The lack of specific details regarding the veracity of the Username or Password will prevent threat actors from generating lists of valid users.
- In instances where timing-based attacks can be leveraged to enumerate valid accounts, remediation options for this are more difficult to implement.
- The authentication process code should be reviewed to ensure that the application attempts to take the same path to validate usernames and passwords, even in cases where the submitted username doesn't exist.
Caveats
Remediating this finding comes with caveats. Implementing a generic message to the authentication or password reset process makes it more difficult for legitimate users to know whether they've entered the account associated with the application. In cases where the user needs help remembering which account is correct, they will no longer receive information from the application. In some cases, organizations are willing to accept the risk associated with the user enumeration finding to ensure a better user experience.
