Skip to content
July 20, 2023
8 min read time

Pentesting Keycloak – Part 2: Identifying Misconfiguration Using Risk Management Tools

Cyber Security Associates
  • Penetration Testing

    • Pentesting Keycloak – Part 2 

    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
    • Bypassing/Automating CSRF
    • JWT Signing Algorithms
    • Make the most out of your scopes/roles
    • offline_access
    • uma_authorization
    • profile
    • email
    • address
    • phone

    References

    If you missed the first part, you can use this direct link: Part One

    Reconnaissance

    Additional Services and Ports

    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.

    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:

    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

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

    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.

    1. Submit a login request in the page and send it to Burp Intruder
    2. 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:

    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

    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.

    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.

    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:

    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:

    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

    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.

    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:

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

    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

    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.

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

    References

    [1] Using Client Scope with RedHat SSO Keycloak

    [2] Server Administration Guide - Keycloak features and concepts

    [3] Authorization Services Guide - Authorization services overview