Enabling a discrepancy factor by enabling user enumeration

Account enumeration

For a long time, SAP thought that a user Id should contain a number (and still does). The D, I, C or S-Users are based on a number, and so are the P-Users everyone was able to get by registering at SCN. Enabling attackers to guess a valid SAP user Id was always possible by increasing a number. This security issue is known as account enumeration. Account enumeration alone is just bad practice. It gets interesting when it is possible to find out if a guessed user id is valid or not. Knowing that there are possible user ids like P000123, P000124 or P000125 is one thing. Knowing that P000123 is not a valid user Id (not used, not assigned to a user) and that P000124 is a valid user id is a different level of knowledge.

Think of an attacker that wants to block logon for a user. To achieve this, a valid user Id is needed and maybe 6 unsuccessful logon attempts. With 1 million possible user Ids it takes 6 million logon attempts to be sure that a user id is blocked. Such kind of attack should be blocked by the site operator before the attacker can block more than a handful of user Ids. When the attacker however knows that a user Id is valid, the whole attack approach changes. Knowing that a user Ids are valid, it is easy to block logon for those, and without giving the site operator any chance to block the attack. All that is needed to such an attack is to know if a user Id is valid or not.

Best practice

Preventing attackers from being able to find out if a user Id is valid is a common security task. OWASP provides information on this security issue in their security cheat sheet. There it is also described why not preventing account enumeration is a bad idea and how to prevent it.

Following the recommendations helps to prevent a discrepancy factor (CWE-204). OWASP has a test that checks for this.

While this might sound complicated, implementing the recommendation is easy. The logon process must only ensure that no information about the validity of a user Id is exposed. Everyone can easily validate this with any system: try to log on to a system with a random user Id and password and check the error message. It should never be: User Id invalid. Password invalid. It should be either “user or password incorrect”, or a simple “logon failed”. Not even the hint that the user is disabled, expired, etc should be shown when the logon was not successful.

SAP Universal ID

Let’s validate this with a recurring guest in my blog: SAP Universal ID. These are the experts; they know what they do. Millions of SAP professionals trust them. Maybe not necessarily voluntary.

Try to log on to SCN: SAP Answers. UID is taking care of the logon.

Use a user Id you know exists (e.g. your P- or S-User).

Go to the next screen to enter your password.

So far, so good.

Let’s take your user Id and increase it by 1. If you user Id is S0000055551 change it to S0000055552.

Now click on Next.

Congratulations, you found a user Id that is not taken. Using this process allows you to find the user Ids that are assigned. These are the ones an attacker can than target.

Works for other sites too

What kind of user Id is accepted during the logon process also depends on the site configuration. For instance, try to log on at sap.com.

Using a user Id like an S-User won’t work.

An e-mail as user Id is needed.

The flow however is the same. With a valid e-mail address SAP UID is asking for your password.

Let’s take another email address. A fake one. I change the TLD of my email (com/de). There should no other person with this email.

The error message says, “We could not find any account associated with <fake email>”. This allows an attacker to find out if certain users from a company do have an account at sap.com.

Changing from .com to .de is still using an existing domain. Using a really, really fake email address with a fake domain gives me a different response.

Now I am asked again to create a new account, because the email address / user Id does not exist. I am not sure how to interpret this. Why do I once get the screen to sign up for Universal ID, and the other time I get asked to create an account? What kind of logic is running in the backend?

To be honest, others do it similar. A logon at Microsoft also validates early if a user Id exists or not.

As with sap.com logon, a simple account enumeration is not possible. You need to find out first a valid user Id.

Fun fact

As Universal ID is a gift that keeps on giving. On the first screen, enter the user Id with a lower s.

Go to the next screen.

Please note the message informing me to link the user to UID. Why does the message appear at all? Why at the password input screen? Why not later? And why does it not appear when using an uppercase letter (s -> S) in the user Id?

In case you think: the X allows to close the message: No.