How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability in OpenStack Keystone allows federated users to maintain access indefinitely by bypassing operator-configured token lifetime policies. This indefinite session persistence can lead to unauthorized prolonged access to sensitive systems and data.

Such unauthorized persistent access may conflict with compliance requirements in standards and regulations like GDPR and HIPAA, which mandate strict access controls, session management, and timely revocation of access to protect personal and sensitive information.

Therefore, this vulnerability could undermine an organization's ability to enforce token expiration policies, potentially leading to non-compliance with these regulations.

Useful 0 Not Useful 0

How can this vulnerability impact me? :

This vulnerability allows a federated user to maintain continuous access by repeatedly rescoping tokens before they expire, bypassing configured token lifetime restrictions. As a result, unauthorized prolonged access can occur, increasing the risk of misuse or compromise of sensitive resources.

Useful 0 Not Useful 0

Can you explain this vulnerability to me?

This vulnerability exists in OpenStack Keystone versions before 29.0.2 and involves the federated token rescoping mechanism. When a federated user requests a new scoped token, the system fails to propagate the original token's expiry time to the new token. Instead, the new token is issued with a fresh default time-to-live (TTL). This means that by repeatedly rescoping tokens before they expire, a user can maintain access indefinitely, effectively bypassing the token lifetime policies set by the operator.

Only deployments using federated identity methods such as SAML2 or OpenID Connect are affected by this issue.

Useful 0 Not Useful 0

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves the federated token rescoping mechanism in OpenStack Keystone not propagating the original token's expiry to the newly issued token, allowing indefinite token validity.

To detect this vulnerability on your system, you should monitor federated token rescoping activity, specifically POST requests to /v3/auth/tokens, and check if the issued tokens lack the expires_at attribute or have a default TTL instead of the expected expiry.

Commands to assist detection could include querying Keystone logs for repeated token rescoping requests by the same federated user before token expiry, for example using grep or OpenStack CLI tools to inspect token expiry times.

• Use OpenStack CLI to list tokens and check their expiry: `openstack token list --user <federated_user>` and verify the expires_at field.
• Inspect Keystone logs for repeated POST /v3/auth/tokens requests from federated users occurring before token expiry using: `grep 'POST /v3/auth/tokens' /var/log/keystone/keystone.log | grep <federated_user>`.
• Check token expiry values in logs or via API responses to identify tokens issued without proper expires_at propagation.

Useful 0 Not Useful 0

What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, you should apply the patch that ensures the federated token rescoping mechanism correctly propagates the original token's expires_at value to the new token.

Until the patch is applied, consider limiting the use of federated identity features or monitoring and restricting frequent token rescoping requests to prevent indefinite session persistence.

Additionally, review and enforce token lifetime policies and consider reducing token TTLs to minimize the window of exploitation.

• Apply the patch that adds `response_data['expires_at'] = token.expires_at` to the federated token handler as proposed.
• Monitor and restrict repeated token rescoping requests from federated users.
• Temporarily disable federated identity features if feasible until patched.

Useful 0 Not Useful 0