A7: 2021 | JWT Tokens (17) | Cycubix Docs

Claim misuse

Next, we will explore the security implications of misusing the Key ID (kid) claim in JSON Web Tokens (JWT).

JSON Key ID (kid)

The Key ID(kid) indicates which key from a JSON Web Key Set (JWKS) should be used to verify the signature of the JWT. When misused, attackers can exploit this vulnerability to gain unauthorized access to sensitive resources or perform privilege escalation.

An example KID would look like this:

{
  "alg": "RS256",
  "kid": "my_rsa_key"
}

Vulnerability

When the kid claim is misused, it usually means that the value of "kid" is manipulated to point to a different key than the one used to sign the token. This manipulation can lead to various security issues:

• Key confusion attack: In this attack, an attacker manipulates the "kid" claim value to point to a different key than the one used to sign the token. As a result, the recipient of the JWT will verify the signature using the wrong key, allowing the attacker to impersonate other users or perform unauthorized actions.

• Key enumeration: If the kid claim is not properly protected or is simply an incrementing number or easily predictable value, an attacker might try to guess or enumerate valid "kid" values. By doing so, they can potentially forge JWTs with different kid values to find vulnerabilities or weaknesses in the system.

• Key spoofing: In this attack, an attacker crafts a JWT with a forged kid claim pointing to a non-existent or invalid key. The intention is to bypass signature verification and potentially gain unauthorized access to resources or features.

• Key overwrite: An attacker might try to overwrite or modify the kid claim during token transmission or processing to point to a different key than originally intended. This manipulation can lead to signature verification failures or other security issues.

• Kidless tokens: If a system does not require the presence of the kid claim, an attacker could attempt to create a JWT without including the "kid" claim at all. This omission could lead to vulnerabilities if the recipient assumes a default or known key, which may not be secure.

• Insecure key storage: If the "kid" claim is combined with other weak security practices, such as storing keys in plaintext or using weak encryption, an attacker might obtain valid "kid" values and exploit the associated keys.

Exploitation steps:

• Identify the kid endpoint: The attacker must first find the kid endpoint in the application’s JWT handling logic or any exposed configurations.

• Generate a malicious JWT: craft a JWT with malicious claims, altering or adding claims to gain unauthorized access or escalate privileges.

• Generate a kid which enables you to know the verification key.

• Send the JWT to the Server: Send the crafted JWT with the malicious claims to the server.

• Server verification: Upon receiving the JWT, the server validates the signature using the "crafted" KID.

• Successful attack: If the server uses the weak or manipulated key to verify the JWT, the attacker gains unauthorized access or executes their intended exploit.

Mitigation

To prevent JWT claim misuse with KID, developers and security professionals should follow these best practices:

• Validation: always validate the "kid" claim and ensure it points to a trusted key appropriate for signature verification.

• Key rotation: regularly rotate the keys used for signing JWTs and update the corresponding "kid" claims accordingly.

• Use strong keys: ensure that strong cryptographic keys are used to sign the tokens.

• Access control: limit access to keys and signing services to authorized personnel only.

• Rate limiting: implement rate limiting to prevent attackers from iterating through possible "kid" values.

• Monitoring: monitor and log JWT-related activities to detect potential misuse or suspicious behavior.

By following these best practices, you can reduce the risk of JWT claim misuse with the "kid" field and enhance the overall security of your system.