Close Widget

This is part 1/2 of “Pentesting Keycloak”, this section will cover:

– Reconnaissance

    • 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

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

This testing methodology 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.

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:

 

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:

  • https://repology.org/project/keycloak/cves
  • https://www.cvedetails.com/version-list/16498/37999/1/Keycloak-Keycloak.html
  • https://www.exploit-db.com/

 

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. It is 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 is: https://github.com/telahdihapus/wordlist-default-username-password-product/blob/master/username_clean.txt

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

  

account
account-console
accounts
accounts-console
admin
admin-cli
broker
brokers
realm-management
realms-management
security-admin-console

No HTTP response code could help us to identify a valid client_id from a wrong one. You should focus on the length of the response that is different from the majority of the responses. In my 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 – Is 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 they don’t hold or send any secrets.

Confidential – Used for backend servers and able to initiate login flaw. They 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. Later on in the article, more information about this type of access in the exploitation part.

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.:

/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 scopes via Burp Suite Intruder, by keeping all the other parameters with the same value:

 

A good list to use for this purpose could be: https://github.com/CyborgInfinix/wordlist/blob/master/common.txt

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

 

 

address
addresses
email
emails
microprofile-jwt
offline_access
phone
openid
profile
role_list
roles
role
web-origin
web-origins

It is quite straight forward to identify valid scopes from non-valid scope (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.:

...&scope=openid+offline_access+roles+email+phone+profile+address+web-origins&...

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 at https://aaronparecki.com/oauth-2-simplified/#authorization

Grants cannot be enumerated and are as follow:

authorization_code
password
client_credentials
refresh_token
implicit
urn:ietf:params:oauth:grant-type:device_code
urn:openid:params:grant-type:ciba

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:

/auth/realms/<realm_name>/broker/<IDP_Name>/endpoint

 

The full list of default IDP names is as follow:

gitlab
github
facebook
google
linkedin
instagram
microsoft
bitbucket
twitter
openshift-v4
openshift-v3
paypal
stackoverflow
saml
oidc
keycloak-oidc


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:

default-roles-<realm_name>
offline_access uma_authorization

Client ID Default Roles:

manage-account
manage-account-links
delete-account
manage-content
view-applications
view-consent
view-profile
read-token
create-client
impersonation
manage-authorization
manage-clients
manage-events

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:

/auth/realms/<realm_name>/account/#/personal-info


When changing the email address to some 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:

POST /auth/realms/<realm_name>/account/ HTTP/1.1
Host: <target>
Content-Type: application/json
Authorization: Bearer <valid_JWT_token>
Origin: <target>
Content-Length: 635
Connection: close
Cookie: <valid_cookies>

{
"id": "<user_GUID>",
"username": "myuser",
"firstName": "my",
"lastName": "user",
"email": "<Enumerate_Here>",
"emailVerified": false,
"userProfileMetadata": {
"attributes": [
{
"name": "username",
"displayName": "${username}",
"required": true,
"readOnly": true,
"validators": {}
},
{
"name": "email",
"displayName": "${email}",
"required": true,
"readOnly": false,
"validators": {
"email": {
"ignore.empty.value": true
}
}
},
{
"name": "firstName",
"displayName": "${firstName}",
"required": true,
"readOnly": false,
"validators": {}
},
{
"name": "lastName",
"displayName": "${lastName}",
"required": true,
"readOnly": false,
"validators": {}
}
]
},
"attributes": {
"locale": [
"en"
]
}
}

The valid email addresses identified in this process can be used to perform brute force (explained in the exploitation part below). 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 part 2 of the blog here: Pentesting Keycloak – Part 2.

How can we help?