0% found this document useful (0 votes)
40 views15 pages

Keycloak Part 2

Uploaded by

0xt3st
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
40 views15 pages

Keycloak Part 2

Uploaded by

0xt3st
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

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 2

Pentesting Keycloak – Part 2


Written by Simone Q, SureCloud's Principle Cybersecurity Consultant

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


Reconnaissance
Additional Services and Ports
Interesting Local Files
Reconnaissance Conclusion
Exploitation
Brute Force Login

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 1/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

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

If you missed the first part, you can read it here.

Reconnaissance

Additional Services and Ports


By default Keycloak starts the following services:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.bindin

<socket-binding name="**management-http**" interface="management" port="${jboss.management.http.port:

<socket-binding name="**management-https**" interface="management" port="${jboss.management.https.por

<socket-binding name="**ajp**" port="${jboss.ajp.port:**8009**}"/>

<socket-binding name="**http**" port="${jboss.http.port:**8080**}"/>

<socket-binding name="**https**" port="${jboss.https.port:**8443**}"/>

<socket-binding name="**txn-recovery-environment**" port="**4712**"/>

<socket-binding name="**txn-status-manager**" port="**4713**"/>

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 2/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

<outbound-socket-binding name="**mail-smtp**">

<remote-destination host="localhost" port="**25**"/>

</outbound-socket-binding>

</socket-binding-group>

The http(s) defines what port Keycloak is listening to. On a production environment this is often set to be 443 on 0.0.0.0
The management-http(s) interface defines the HTTP connection used by Wildfly CLI and web console. This is known as the ‘ManagementRealm’ and it’s
protected via a Digest Authorization header. Password complexity is enforced on user creation (8 digits, alpha, numeric and special).
The ajp socket defines the port used for the AJP protocol. This protocol is used by Apache HTTPD server in conjunction mod-cluster when you are using
Apache HTTPD as a load balancer.
The txn-* refers to the recovery environment.
The above ports are all bound to 127.0.0.1 by default, but this can be changed via “-b” parameter at start-up.

Interesting Local Files


If you had a chance to get a local shell on a machine running Keycloak, the following files might be of interest:

$Keycloak_install_dir/standalone/configuration/mgmt-users.properties
$Keycloak_install_dir/domain/configuration/mgmt-users.properties $Keycloak_install_dir/standalone/configurati

Properties declaration of users and groups for the realm ‘ManagementRealm‘ (port 9990/9993). Further authentication mechanism can be configured as part
of the <management /> in standalone.xml.
Contains username and password (hashed) to access it. Format is:

username=HEX( MD5( username ':' realm ':' password))

Permissions were correctly set to allow only the local user to write on the file:
-rw- — —

$Keycloak_install_dir/domain/configuration/application-roles.properties
$Keycloak_install_dir/domain/configuration/application-users.properties $Keycloak_install_dir/standalone/conf

Properties declaration of users for the realm ‘ApplicationRealm‘ (port 8080/8443). This includes the following protocols: remote ejb, remote jndi, web,
remote jms. Contains username and password (hashed) to access it. Format is:
username=HEX( MD5( username ‘:’ realm ‘:’ password))
Permissions were correctly set to allow only the local user to write on the file:
https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 3/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

-rw- — —

$Keycloak_install_dir/domain/configuration/domain.xml
$Keycloak_install_dir/standalone/configuration/standalone.xml $Keycloak_install_dir/standalone/configuration/

The above contain definitions to the data source (database username and password).
Keycloak comes with its own embedded Java-based relational database called H2. This is the default database that Keycloak will use to persist data and
really only exists so that you can run the authentication server out of the box. A client might have changed it to other DBMS.
The physical position of the H2 database (also containing the user’s password) is:

$Keycloak_install_dir/standalone/data/keycloak*

And can be accessed locally (when Keycloak is not locking it), via the command:

java -jar $Keycloak_install_dir/modules/system/layers/base/com/h2database/h2/main/h2-*.jar

This will open the H2 database console on http://127.0.1.1:8082 – Use the following configuration to access it (default password is sa:sa)

User’s hashes can be extracted via query: ‘SELECT * FROM CREDENTIAL’

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 4/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

Hash format is pbkdf2-sha256 with 27500 iterations.


Finally, log files are available in:

$Keycloak_install_dir/standalone/log/

$ ls -lha standalone/log/
totale 644K
drwxrwxr-x 2 user user 4.0K Sep 9 08:45 .
drwxr-xr-x 8 user user 4.0K Aug 23 09:38 ..
-rw-rw-r-- 1 user user 0 Aug 23 09:38 audit.log
-rw-rw-r-- 1 user user 103K Sep 9 10:42 server.log

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 5/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

Reconnaissance Conclusion
At the end of this reconnaissance stage, you should have obtained:
A list of valid realms
A list of realms that allow self-registration (if any)
A list of valid client ids for each realm
A list of valid scopes for each realm
A list of valid email addresses for the realm(s) we have access to
A list of enabled identity providers for each realm
A list of additional service reachable from your perspective (local, adjacent or remote)
Basic knowledge of Keycloak’s file structure

Exploitation

Brute Force Login


Keep in mind that Keycloak has a brute force protection, which is not enabled by default.
In case user enabled it, you’ll have 30 invalid attempts before being locked out (in a default configuration). Perform this attack at the end of your test, to avoid
asking the client to manually re-enable your account.

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 6/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

Bypassing/Automating CSRF
The login page uses a Cross-Site Request Forgery (CSRF) token that needs to be extracted and used in the automated attack. For this task, we will use the Burp
Intruder Recursive Grep.
Submit a login request in the page and send it to Burp Intruder
Add the payload positions in the value of ‘session_code’ and ‘password’ parameters. Select the Pitchfork Attack Type.

3. In the Payload Tab, the first Payload Type should be Recursive Grep. The second Payload Type should be Simple List (with your passwords to try for a
specific user).
4. Move to the “Options” tab and add a new element to “Grep – Extract” menu. We will need to extract the “session_code” from the response:

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 7/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

5. Check “Extract the following items from responses” and also uncheck “Make unmodified baseline request” in the “Attack Results” section

6. In the “Resource Pool” tab, create one new pool with 1 maximum concurrent request

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 8/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

7. Go back to the “Payloads” tab and add the “initial payload for first request”, which should be a clean, unused, session_code – You can grab one just by
refreshing the login page.

Start the attack and you’ll see a 302 Status code if you’ve found the correct password for the user.

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 9/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

JWT Signing Algorithms


By default, Keycloak sets RS256 as a signing algorithm for JWT, which is already a great standard. However, it also offers additional, stronger, options:
It might be worth to raise an information risk issue to make the client aware of this possibility. Please note: EdDSA is not yet implemented in Keycloak, and
that’s the strongest algorithm to use (as today). Alternatively, RS512 or ES512 are the next best choices.
If HS* is in use, it should be noted that the secret is randomly generated by the system and it could be between 16 and 512 bytes (it cannot be easily cracked).

Make The Most Out of Your Scopes/Roles


In the reconnaissance part, we were able to identify roles and scopes available for our testing account. In this section, we’re going to make advantage of them
with practical examples
offline_access
Offline access is a feature described in OpenID Connect specification . The idea is that during login, your client application will request an Offline token
instead of a classic Refresh token. The application can save this offline token in a database or on disk and can use it later even if user is logged out. This is
useful if your application needs to do some “offline” actions on behalf of user even when the user is not online. An example is a periodic backup of some data
every night.
Therefore, having an offline_access scope on your user account is never a good idea, since it generates a long living refresh token that should only be used for
server-to-server applications.
Request an offline token (method 1)
This first method requires you to add the additional ‘offline_access’ scope in the URL of the login page.

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 10/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

Perform the login and the /token endpoint will generate a refresh_token that does not expire:

We can generate a valid session token from the offline refresh_token via the following request:

POST /auth/realms/<realm_name>/protocol/openid-connect/token HTTP/1.1


Host: <target>
Content-type: application/x-www-form-urlencoded
Content-Length: 808

grant_type=refresh_token&client_id=<client_id>&refresh_token=eyJ....

Request an offline token (method 2)


If you instead have client_id and client_secret of a client using ‘confidential’ access type, you can request an offline token via:

POST /auth/realms/<realm_name>/protocol/openid-connect/token HTTP/1.1


Host: <target>
Content-type: application/x-www-form-urlencoded
Content-Length: 150

grant_type=password&username=<account-username>&password=<account_password>&scope=openid+offline_access&clien

uma_authorization
Keycloak Authorization Services is based on User-Managed Access or UMA for short. UMA is a specification that enhances OAuth2 capabilities in the following
ways:
Privacy

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 11/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

Nowadays, user privacy is becoming a huge concern, as more and more data and devices are available and connected to the cloud. With UMA and Keycloak,
resource servers can enhance their capabilities to improve how their resources are protected in respect to user privacy where permissions are granted based
on policies defined by the user.
Party-to-Party Authorization

Resource owners (e.g.: regular end-users) can manage access to their resources and authorize other parties (e.g: regular end-users) to access these resources.
This is different than OAuth2 where consent is given to a client application acting on behalf of a user, with UMA resource owners are allowed to consent access
to other users, in a completely asynchronous manner.
Resource Sharing

Resource owners are allowed to manage permissions to their resources and decide who can access a particular resource and how. Keycloak can then act as a
sharing management service from which resource owners can manage their resources.
Keycloak is a UMA 2.0 compliant authorization server that provides most UMA capabilities.
To add a specific resource type, we can use the following request:

POST /auth/realms/myrealm/authz/protection/resource_set HTTP/1.1


Host: <target>
Authorization: Bearer <Valid JWT>
Content-type: application/json
Content-Length: 340

{ "name":"string", "type":"string", "icon_uri":"string", "resource_scopes":[ "read-public", "post-updates", "

By default, the owner of a resource is the resource server. If you want to define a different owner, such as an specific user, you can send a request as follows:

POST /auth/realms/myrealm/authz/protection/resource_set HTTP/1.1


Host: <target>
Authorization: Bearer <Valid JWT>
Content-type: application/json
Content-Length: 340

{ "name":"MyUser Resource", "owner": "myuser", "ownerManagedAccess": true }

To list the security permissions we can visit (with a valid token):

/auth/realms/<realm_name>/authz/protection/permission

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 12/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

profile
OPTIONAL. This scope value requests access to the End-User’s default profile Claims, which are: name, family_name, given_name, middle_name, nickname,
preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at.

email
OPTIONAL. This scope value requests access to the email and email_verified Claims.

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 13/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

address
OPTIONAL. This scope value requests access to the address Claim.

phone
OPTIONAL. This scope value requests access to the phone_number and phone_number_verified Claims.

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 14/15
27/11/2023, 14:30 Pentesting Keycloak – Part 2 - SureCloud

All of the above can be updated by the API endpoint available at

POST /auth/realms/**<realm>**/account/

You can catch up on part 1 of the blog here: Pentesting Keycloak – Part 1.
References
https://www.janua.fr/using-client-scope-with-redhat-sso-keycloak/
https://www.keycloak.org/docs/latest/server_admin/index.html#threat-model-mitigation
https://www.keycloak.org/docs/latest/server_installation/index.html#_database
https://www.keycloak.org/docs/latest/authorization_services/

https://www.surecloud.com/resources/blog/pentesting-keycloak-part-2 15/15

You might also like