Pentesting Keycloak Part 1: Identifying Misconfiguration Using Risk Management Tools

What is Keycloak?

Keycloak is an open-source Identity and Access Management (IAM) solution. It allows easy implementation of single sign-on for web applications and APIs.

Many businesses don’t have the risk management software tools to carry out proper testing and analysis on popular solutions such as Keycloak. As penetration testers, it’s our job to highlight common pitfalls or vulnerabilities in software, tools, and systems that we know business rely on and trust. Keycloak is a perfect example of this.

The testing methodology we explore in this post would give security consultants the ability to identify misconfigurations on a system running Keycloak.

All of the below tests were performed on Keycloak version 15.0.2; newer versions might fix/prevent the described attack methodologies. The security team reviewed this article at Keycloak before publication.

Pentesting Keycloak, Part One

This is part 1of 2 in our Pentesting Keycloak Guide. This section will cover the following topics:

- Am I Testing Keycloak?
- Keycloak Version Information
- OpenID Configuration /SAML Descriptor
- Realms
- Realms Enumeration
- Realms Self-Registration Enabled
- Client IDs
- Client IDs Enumeration
- Scopes
- Scopes Enumeration
- Grants
- Identity Providers
- Identity Providers Enumeration
- Roles
- User Email Enumeration

Am I Testing Keycloak?

To understand if the target web application is running a Keycloak instance, we should look at the following clues:

Cookie Name – Once logged in with valid credentials, you should be able to see the following cookies in the first server’s response:

URLs: Keycloak has a very distinctive URL, e.g.:

JWT Payload: Even if this is an OAuth requirement, the JWT could also give you a hint that you’re using Keycloak, just by looking at sections like ‘resource_access’ and ‘scope’; e.g.:

Page Source: Finally, you might also find references of /keycloak/ in the source code of the login page:

Identifying Keycloak Version Information (auth)

At the moment, there is no way to identify the running Keycloak version by looking at it from an unauthenticated perspective. The only way is via an administrative account (with the correct JWT token in the request header):

GET /auth/admin/serverinfo

The latest stable version of Keycloak is available at https://www.keycloak.org/downloads – Make sure the client is running the latest. If not, check if there are public CVEs and/or exploits on:

OpenID Configuration / SAML Descriptor

For a bit more information regarding what’s supported by the platform:

/auth/realms/realm_name/.well-known/openid-configuration /auth/realms/realm_name/protocol/saml/descriptor

For public keys:

/auth/realms/realm_name/

These endpoints are in line with the specification of OpenID (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) and the response is a set of Claims about the OpenID Provider’s configuration, including all necessary endpoints and public key location information.

Realms

A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control.

When you boot Keycloak for the first time, Keycloak creates a pre-defined realm for you. This initial realm is the master realm – the highest level in the hierarchy of realms. Admin accounts in this realm have permissions to view and manage any other realm created on the server instance. When you define your initial admin account, you create an account in the master realm. Your initial login to the admin console will also be via the master realm.

It is not recommended to configure a web application’s SSO on the default master realm for security and granularity.

Realms Enumeration

Realms can be easily enumerated, but that’s a default behaviour of the platform. Obtaining a list of valid realms might be useful later on in the assessment.

It is possible to enumerate via Burp Suite Intruder on the following URL: /auth/realms/realm_name/

A good list to use, can be found in: https://raw.githubusercontent.com/chrislockard/api_wordlist/master/objects.txt

Realms Self-Registration Enabled

Realms can be configured to allow user self-registration. This is not an issue itself and is often advertised in the login page:

Just in case the client is using a custom template for the login page, hiding the registration link, we can still try to directly access the registration link, which is: /auth/realms/<realm_name>/login-actions/registration?client_id=<same_as_the_login_page>&tab_id=<same_as_the_login_form>

The registration process can be configured to verify a newly registered user email or not.

If not strictly necessary for the realm, we recommend disabling self-registration in a production environment.

Client IDs

Clients are entities that can request Keycloak to authenticate a user. Most often, clients are applications and services that want to use Keycloak to secure themselves and provide a single sign-on solution. Clients can also be entities that just want to request identity information or an access token so that they can securely invoke other services on the network that Keycloak secures.

Each realm (identified below) might have a different set of client ids.

Client IDs Enumeration

When landing on a login page of a realm, the URL will be auto-filled with the default ‘client_id’ and ‘scope’ parameters, e.g.:

/auth/realms/<realm_name>/protocol/openid-connect/auth?**client_id=account-console**&redirect_uri=<...>&state=<...>&response_mode=<...>&response_type=<...>&**scope=openid**&nonce=<...>&code_challenge=<...>&code_challenge_method=<...>

It is possible to identify additional client_id via intruder, by keeping all the other parameters with the same value:

A good list to use for this purpose can be found on GitHub.

The following, additional, default client ids should also be available upon Keycloak installation:

No HTTP response code could help us to identify a valid client_id from a wrong one. You should focus on whether the length of the response differs from the majority of the responses. In this example case, I had 1283 responses with a length of 2451 and just 6 with a different length. Those are the valid client IDs.

This process should be repeated for each valid realm identified in previous steps.

Clients can be configured with different Access Types:

Bearer-Only – Used for backend servers and API (requests that already contain a token/secret in the request header)

Public – Able to initiate login flaw (Auth flow to get an access token) and does not hold or send any secrets

Confidential – Used for backend servers and able to initiate login flaw. Can accept or send secrets.

Therefore, when we encounter a “client_secret” parameter in the login request, we’re probably looking at a client with a Confidential or Bearer-Only Access Type. Find more information about this type of access in the exploitation part of this article.

Scopes

When a client is registered, you must define protocol mappers and role scope mappings for that client. It is often useful to store a client scope to make creating new clients easier by sharing some common settings. This is also useful for requesting some claims or roles to be conditionally based on the value of the scope parameter. Keycloak provides the concept of a client scope for this.

Scopes Enumeration

When landing on a login page of a realm, the URL will be auto-filled with the default ‘client_id’ and ‘scope’ parameters, e.g.:

It is possible to identify additional scopes via Burp Suite Intruder, by keeping all the other parameters with the same value:

A good list to use for this purpose can be found on GitHub.

The following, additional, default scopes should also be available upon KeyCloak installation:

It is quite straight forward to identify valid scopes from non-valid scopes by looking at the content length or status code:

This process should be repeated for each realm identified in previous steps.

It should be noted that valid scopes can be concatenated within the URL prior of the login, e.g.:

This will ‘force’ Keycloak to grant any available/additional scope, for such realm – but also depending on the user’s role configuration. More information in the attack scenario below.

Grants

OAuth 2 provides several ‘grant types’ for different use cases. The grant types defined are:

- Authorization Code for apps running on a web server, browser-based and mobile apps
- Password for logging in with a username and password (only for first-party apps)
- Client credentials for application access without a user present
- Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with PKCE

A good resource to understand use cases of grants is available from Aaron Parecki.

Grants cannot be enumerated and are as follow:

Identity Provider

Keycloak can be configured to delegate authentication to one or more Identity Providers (IDPs). Social login via Facebook or Google+ is an example of an identity provider federation. You can also hook Keycloak to delegate authentication to any other OpenID Connect or SAML 2.0 IDP.

Identity Provider Enumeration

There are a number of external identity providers that can be configured within Keycloak. The URL to use within Intruder is:

The full list of default IDP names is as follow:

Once again, the status codes might differ, but the length will disclose which IDP is enabled. It should be noted that, by default, the login page will disclose which IDPs are enabled:

Roles

Roles identify a type or category of user. Admin, user, manager, and employee are all typical roles that may exist in an organization. Applications often assign access and permissions to specific roles rather than individual users as dealing with users can be too fine-grained and hard to manage.

Roles cannot be easily enumerated from an unauthenticated perspective. They are usually visible within the JWT token of the user upon successful login:

The above image shows that ‘account’ client_id has, by default, 2 roles.

Realm Default Roles:

Client ID Default Roles:

User Email Enumeration (auth)

It is possible to enumerate valid email addresses from an authenticated perspective via Keycloak’s account page (if enabled for the logged-in user), available at:

When changing the email address to an already existing value, the system will return 409 Conflict. If the email is not in use, the system will return ‘204 – No Content’. Please note that, if Email Verification is enabled, this will send out a confirmation email to all email addresses we’re going to test.

This process can be easily automated via Intruder and no CSRF token is needed to perform this action:

If the template of the account console was changed to not show the personal information page, you might want to try firing up the request via:

The valid email addresses identified in this process can be used to perform brute force (explained in the exploitation part of the Pentesting Keyclock Part Two). For this reason, access to the Keycloak’s account page should be disabled.

In the next part of “Pentesting Keycloak” we will take a look at the following:

Reconnaissance

- Additional Services and Ports
- Interesting Local Files
- Reconnaissance Conclusion

Exploitation

- Brute Force Login
- Bypassing/Automating CSRF
- JWT Signing Algorithms
- Make the most out of your scopes/roles
- offline_access
- uma_authorization
- profile
- email
- address
- phone

You can read Pentesting Keycloak Part Two here. Alternatively, if you’d like to find out more about penetration testing and other risk management software tools, head over to our Penetration Testing or Risk Consulting services.