This is part 2/2 of “Pentesting Keycloak”, this section will cover:
Reconnaissance
Exploitation
References
If you missed the first part, you can use this direct link: Part One
By default Keycloak starts the following services:
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.
If you had a chance to get a local shell on a machine running Keycloak, the following files might be of interest:
Properties declaration of users and groups for the realm 'ManagementRealm' (port 9990/9993). Further authentication mechanism can be configured as part of the 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- --- ---
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:
-rw- --- ---
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'
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
At the end of this reconnaissance stage you should have obtained:
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 attempt 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.
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.
1. Submit a login request in the page and send it to Burp IntruderStart the attack and you'll see a 302 Status code if you've found the correct password for the user.
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).
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 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.
This first method requires you to add the additional 'offline_access' scope in the URL of the login page.
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:
If you instead have client_id and client_secret of a client using 'confidential' access type, you can request an offline token via:
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:
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 in order to improve how their resources are protected in respect to user privacy where permissions are granted based on policies defined by the user.
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 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:
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:
To list the security permissions we can visit (with a valid token):
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.
OPTIONAL. This scope value requests access to the address Claim.
OPTIONAL. This scope value requests access to the phone_number and phone_number_verified Claims.
All of the above can be updated by the API endpoint available at
[1] Using Client Scope with RedHat SSO Keycloak
[2] Server Administration Guide - Keycloak features and concepts
[3] Authorization Services Guide - Authorization services overview