If you read my previous post regarding Common Information Disclosure Vulnerabilities During Registration and Authentication, then you know how difficult it is to prevent user enumeration. Most developers seem to shrug their shoulders at this problem and wonder what’s the big deal. If you fall into this bucket, you aren’t alone. There are many reasons, however, why user enumeration can be a very dangerous thing. In this post, I hope to identify three major reasons.
The Basis of All User Enumeration Problems
Let’s start with a little context. In order to login to a system, you must provide a means of identifying yourself. In order to identify yourself you provide a unique identifier, commonly called a “username.” This username is typically human-readable, is negotiated at the time of registration, and is typically chosen by the user.
The username can take one of two forms: an email address or a label. Many websites and users prefer to use email addresses because there is no risk of colliding with a different user. A user can furnish proof of ownership of an email address, but anyone can slap a label on himself. How many people do you think login to a system as “admin”, “user”, or “big-daddy,” for example? The risk of colliding with another user using a label, therefore, is much higher.
Because of this, labels present a user experience problem. You cannot allow a user to choose a label that is already in use. Also, a user doesn’t want to have to remember a different label for each system that s/he uses. So naturally, the user is going to choose a label that has a higher probability of being unique. If you have an uncommon first and last name, for example, you may choose to register with a label that takes the form <first-name>.<last-name> or <first-initial><last-name>. You may have a unique nickname that you have been called your entire life. Still can’t get it to be unique? Tack your favorite number on the end.
The reality is that regardless of whether or not email addresses or labels are used, a user will always tend to recycle a username across different systems. And this is the basis for all of our user enumeration problems.
1. The Problem of Passwords
Whereas usernames are used to identify a user to a system, a password is used to verify that the user is who he says he is. Ideally, a user chooses a different password for every system that s/he logs into. But, as we learned above, this presents a poor user experience. Users will tend to recycle the same password across different systems.
Dealing with passwords is a tough problem, which is why most systems get it wrong. Many developers simply choose to store a password in plain text in a database. If the system is compromised, an attacker will dump the contents of the database and recover all of the username and password combinations.
If a user registers a username and password combination with a system that is ultimately compromised, then this is a huge problem. Why? Because there is a high probability that the user registered the exact same username and password in another system.
A Simple Password Attack
Let’s consider an example. An imaginary user named John Doe has registered on two different websites: we’ll just call them Web-A and Web-B. John, like most people, doesn’t want to remember two different sets of credentials. He therefore registers accounts with both websites using the following information:
Username: john.doe@example.com
Password: aR3alStr0ngP@ssword
An attacker breaks into Web-B via a SQL-injection vulnerability and dumps the credentials. He then attempts to login to Web-A using the credentials he discovered. When he attempts to login using John Doe’s credentials, he succeeds. He can then proceed to use Web-A as John Doe. Web-A is none the wiser.
Consider if Web-A was an e-commerce system and had John’s credit card on file. The attacker could then purchase thousands of dollars in merchandise and send it to an untraceable location – all without John’s knowledge. John may not recognize that the attacker took advantage of him until he attempts to reconcile his financial records in a month.
Password managers like LastPass and 1Password alleviate the problem of having to remember usernames and passwords. They even provide services to generate unique passwords when you register with a system. However, it’s unrealistic to assume that a less-technically inclined user is going to use a password manager. And, even if a user chooses to use a password manager, old habits are hard to break. This is a lot of responsibility to place on a user.
2. The Problem of Social Engineering
Many times, I have seen authentication circumvented through a simple call to a help desk. If an attacker is able to determine if a user has an account with a system, he may be able to break into the account with a little social engineering. Several help desks fail to properly verify a user’s identity. It’s quite possible that all an attacker needs to do is provide a name and email address.
A Simple Social Engineering Attack
For example, let’s say that John Doe is registered with a system using the credentials above. If an attacker were able to determine that John is registered with the system, he can call the system’s help desk. The conversation may go something like this:
Help Desk: Thank you for calling the help desk. How can I be of service today?
Attacker: Yes, hi. My name is John Doe. I’m having some difficulty logging into my account.
Help Desk: Hello, John. Can I get your email please so that I can pull up your information?
Attacker: Sure thing. My email address is john.doe@example.com.
Help Desk: Thank you. One second please while I pull up your account. Okay, Mr. Doe I can see your account here. Have you attempted to reset your password online?
Attacker: Yes, I sure have. It says that it sent me an email, but I haven’t received one yet. I’ve waited a long time, and I really can’t wait any longer. There’s a high priority issue I need to resolve.
Help Desk: Sure thing. I can reset your password for you. One second please. Mr. Doe, I have reset your password to abc123. Please log into the system and change your password immediately.
Attacker: Thank you so much. You have really helped me out of a bind.
At this point, the attacker can login with these new credentials.
Don’t think this is a likely scenario? SANS published an interesting survey back in 2013 that shed some amazing light on Help Desks. The information is a bit dated, but I can assure you that it is still quite applicable.
3. The Problem of Privacy
We live in a highly polarized society. In my opinion, social networking has contributed significantly to the ever increasing number of divisions. Podiums such as Facebook and Twitter allow anyone to be the king of their own kingdom, so to speak. I don’t see this problem getting any better in the near future.
As our day-to-day lives have become more ingrained with the interconnected systems of the world wide web, it has become easier and easier to piece together someone’s political and religious affiliations via his or her online presence. What would it mean if a user had an account on a website like “i-am-a-conservative.com” or “i-am-a-liberal.com?” Or a website like “i-am-a-christian.com” or “i-am-a-muslim.com?” What about a website such as “i-believe-in-x.com” or “i-believe-in-y.com?”
This is why user enumeration is poses a huge problem to privacy. Not everyone lives in an area where they can freely express their opinions without the risk of repercussions. There have been many well-documented examples of people suffering persecution and even death for certain religious beliefs, for example. A political party could use this information to put together a more effective campaign. A nation state could use this information to control certain people groups.
An attacker can still gain valuable information from a non-polarized website. The nature of the website can still provide valuable insight into a user’s likes, dislikes, abilities, and behavioral patterns. And, though many people may willingly shout their private lives out on social media, a user should always be granted the ability to keep private things private.
Conclusion
User enumeration can lead to data breaches as a result of password reuse, can open up the door to social engineering, and can undermine a user’s privacy. Preventing user enumeration is not an easy task, but the costs of doing so need to be weighed against the risk of a data breach.
Photo by rawpixel.com from Pexels.
