A User Enumeration attack occurs when an attacker obtains the user name for a website by brute-forcing or social engineering, and then obtains the password and gains access to the service.
With that classic definition, let us begin this post and walk you through the A-Z of an enumeration attack.
Table of contents
- What is an enumeration attack?
- How does user enumeration leakage happen?
- Dangers of enumeration attacks
- How to prevent enumeration attacks?
What is an enumeration attack?
The login window, the registration form, and the password reset page are the most common components that interact with the user database in web applications. Attackers can utilize these features to detect if a specific username exists in the database if web developers do not implement them securely enough.
Previously, it was usual for developers to incorporate all of these functionalities without any safety net, allowing attackers to utilize a list of usernames and a program to manually enter them one by one. To keep the prospective hackers out of the picture, developers started implementing security features like captcha, limiting the number of login tries, and hiding certain answer details with asterisks or other techniques.
This type of security is generally present in the login window of newer web apps. But what about registration forms and password reset pages? You will find no such safety measures. Web developers usually do not consider the absence or presence of a user in the database as a way to connect it with the timing of the server response. If the user name is found in the database, for example, the server’s response time is 2 milliseconds. If this is not the case, the response time will be doubled, to 4 milliseconds. The difference is unnoticeable to a human, but it’s obvious to automated enumeration techniques. And this is the core concept of an enumeration attack.
How does user enumeration leakage happen?
The login page and the ‘Forgot Password’ feature of a website are two of the most common places where user enumeration occurs.
Based on the legitimacy of submitted credentials, a malicious actor looks for variations in the server’s response. This type of behavior is frequently seen on the Login form. The server responds that user ‘rapid7’’ does not exist when the user inputs an improper username and password. A malicious actor would recognize that the issue isn’t with the password, but rather with the fact that this username doesn’t exist in the system, as illustrated below:
If a user provides a valid username but an invalid password, and the server responds with a different answer indicating that the password is incorrect, the malicious actor can deduce that the username is valid, as seen below:
This type of attack can also be used in the application’s Forgot Password page. When a user forgets their password, they usually type their username in the area, and the system sends them an email with instructions on how to reset it. In addition, a vulnerable system will show that the username does not exist, as shown below:
Dangers of enumeration attacks
Although username enumeration is not always a high-risk problem, it does give an attacker useful information that can be used in subsequent attacks. Here are some ways they do it -
- Brute forcing passwords: An attacker can quickly target users for popular passwords if they have a list of legitimate usernames. For instance, they can pull their year of birth from the username and use it for deducing passwords. Many of us still use our year of birth as an important component of our passwords.
- Credential stuffing: An attacker can use the usernames to look for passwords in already hacked databases. Your users’ usernames are likely to be the same on other platforms, and they may have used the same passwords.
- Social engineering: An attacker can certainly determine the names of those users after learning their usernames and utilize social engineering tactics to contact them directly.
How to prevent enumeration attacks?
Following are the ways to prevent enumeration attacks:
A good solution would be for the server to respond with a general notice that doesn’t specify which field is wrong. The malicious actor cannot determine whether the username or password is genuine. An example of a generic error answer is shown in the diagram below:
Another option is to send an educational email to the address on the database without mentioning whether the entered username is right or not An example message could be -
Lastly, you can use rate limiting, which is nothing but restricting the maximum number of calls you can make in an interval. Rate restriction should only be used when all other options have been shown to be ineffective. This is because rate constraints can be circumvented by employing a huge network of IP addresses that are generally and easily available to even the least experienced of attackers. “Low and slow” assaults, in which requests are issued over a long period of time, can also be used to get around them.
Applications owners must strike a fine balance between usability and security. For the vast majority of cases, the best solution is to resolve the problem from its root. Non-sensitive applications may choose to tolerate the risks, but developers should always consider the safety of users and protect their credentials so that malicious attacks are not possible in future.
If you want to read more articles about enumeration attack, take a look at our website for more publications: https://www.partech.nl/en/publications