27/11/2023, 14:30 Keycloak
SureCloud Named a Representative Vendor in the 2022 Gartner® Market Guide for IT Vendor Risk Management. Access the report
Capabilities GRC Software Services Resources Company ?
Home > Pentesting Keycloak Part 1: Identifying Misconfiguration Using Risk Management Tools
Pentesting Keycloak Part 2: Identifying
Misconfiguration Using Risk Management
Tools
Written by Simone Q, SureCloud's Principle Cybersecurity Consultant
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.
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 1/22
27/11/2023, 14:30 Keycloak
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:
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 2/22
27/11/2023, 14:30 Keycloak
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.:
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 3/22
27/11/2023, 14:30 Keycloak
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):
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 4/22
27/11/2023, 14:30 Keycloak
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
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 5/22
27/11/2023, 14:30 Keycloak
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>/
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 6/22
27/11/2023, 14:30 Keycloak
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:
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 7/22
27/11/2023, 14:30 Keycloak
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_l
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.
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 8/22
27/11/2023, 14:30 Keycloak
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
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:
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 9/22
27/11/2023, 14:30 Keycloak
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 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.
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 10/22
27/11/2023, 14:30 Keycloak
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
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 11/22
27/11/2023, 14:30 Keycloak
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
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:
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 12/22
27/11/2023, 14:30 Keycloak
address
addresses
email
emails
microprofile-jwt
offline_access
phone
openid
profile
role_list
roles
role
web-origin
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 13/22
27/11/2023, 14:30 Keycloak
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. More information in the
attack scenario below.
Grants
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 14/22
27/11/2023, 14:30 Keycloak
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/<realm_name>/broker/<IDP_Name>/endpoint
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 15/22
27/11/2023, 14:30 Keycloak
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:
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 16/22
27/11/2023, 14:30 Keycloak
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
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 17/22
27/11/2023, 14:30 Keycloak
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
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 18/22
27/11/2023, 14:30 Keycloak
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:
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 19/22
27/11/2023, 14:30 Keycloak
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
}
}
},
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 20/22
27/11/2023, 14:30 Keycloak
{
"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.
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
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 21/22
27/11/2023, 14:30 Keycloak
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 cybersecurity
services.
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-1 22/22
