Pentesting 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.
Fingerprint and enumeration
Keycloak running...
For assessing an environment running Keycloak, we will need first to fingerprint it, meaning to identify that we are facing a keycloak implementation and to determine which version is. For that:
- Cookie Name – Once logged in with valid credentials, pay attention to cookies.
- URLs: Keycloak has a very distinctive URL.
- 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’.
- Page Source: Finally, you might also find references of /keycloak/ in the source code of the login page.
Version
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/
Enumeration
OpenID Configuration / SAML Descriptor
/auth/realms/<realm_name>/.well-known/openid-configuration /auth/realms/<realm_name>/protocol/saml/descriptor
For public keys:
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 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:
A possible dictionary: https://raw.githubusercontent.com/chrislockard/api_wordlist/master/objects.txt.
Realms can be configured to allow user self-registration. This is not an issue itself and is often advertised in the login page:
If the application 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/
Of course, disabling self-registration in a production environment is recommended.
Clients ID+
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.
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=<...>
We can use here some dictionaries.
Additionally, the following 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. We should focus on whether the length of the response differs from the majority of the responses.
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.
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.
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:
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 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.:
...&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.
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:
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/
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-
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/
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:
POST /auth/realms/
Host:
Content-Type: application/json
Authorization: Bearer
Origin:
Content-Length: 635
Connection: close
Cookie:
{
"id": "
"username": "myuser",
"firstName": "my",
"lastName": "user",
"email": "
"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 of the Pentesting Keyclock Part Two). For this reason, access to the Keycloak’s account page should be disabled.
Last update: 2024-02-01 Created: February 1, 2024 17:39:08