Describe the bug

Hi,

I am doing a pentest for a client of mine. Responsible disclosing the bug wasn't possible. It was just turned down as I wasn't the recent version I was testing this against.

I was supposed to prove that this bug also exists in the latest version -- which I can't as it is a pentest and nobody will pay me for this. So this is my swift response on the response I just encountered. I am doing this because I suspect the bug exists also in the latest version and I want software to be secure.

Details:

During an authorization grant request to a keycloak server I tried to figure out whether one can guess userids by observing the response time. HTTP request to the keycloak server was

The hostname and HTTP Host header was the keycloak server. password was just an incorrect arbitrary one.

The column payload is the contents of the username variable above, the column starting with "Respon..." is the Response received time in milliseconds (was performed on a DSL).

If I order the request by response received time one can see that the requests with the existing usernames were responded significantly later (>100 ms) than the on-existing ones (<50ms), thus allowing the identification of usernames.

Usually that's the case when internally the real usernames are checked for their password -- hence the delay and the others just come back when the username isn't valid. It's recommended you add a baseline delay for the latter and some random time on any request.

An attacker can thus use e.g. so called dumps from the internet with just e-mail addresses and guess usernames (which in my case is the same. Otherwise a username dictionary would help). Once the usernames were identified, using a password list (in several projects @ github available) would then give full access. See also https://cwe.mitre.org/data/definitions/208.html .

As said this was discovered through a pentest. Atm I do not have access to the management interface. And probably I don't have access to the system anymore in a few days,

Fingerprinting the version tells me the keycloak version my client is using is between 15.0.2 and 13.0.1 . I haven't looked into the code whether the delay I suggested is implemented on recent versions as I spent a couple of hours already preparing the issue and reporting the bug.

For the sake of security it would be great if you or anybody reading this could check whether the security bug exists in 18.X too and if it does: fix that!

Cheers / thanks,

Dirk

Version

~15.0.2

Expected behavior

see above

Actual behavior

see above

How to Reproduce?

see above

Anything else?

I am really scratching my head when people spent time reporting a security bug why they are being turned down with such lame response. This may not shed a good light on the company behind this or the project -- which I normally appreciate.