Source: keystone Version: 2:27.0.0-3+deb13u5 Severity: serious Tags: security X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Copying launchpad.net bug from: https://bugs.launchpad.net/keystone/+bug/2159643 Tokens obtained via delegated authentication methods (ec2credential, application_credential) can call PATCH /v3/credentials and DELETE /v3/credentials/{id} on any credential owned by the same user, regardless of credential type. This allows a holder of an ec2 access/secret key pair (or an application credential) to: • Overwrite a TOTP seed (type=totp) — immediately invalidates the user's authenticator app and substitutes the attacker's seed, bypassing MFA • Read credentials: • ec2credential token can Read TOTP seed — full silent MFA compromise (as well as any other credential blobs) • application_credential token is correctly blocked from GET on individual credentials (403), but can still list all ec2 credentials (one API call dumps all credentials with their complete secrets) • Change the project_id of any ec2 credential — re-scopes the credential to any other project the user has roles in, escalating the access the key provides. (A holder of an ec2 access/secret key pair can use the token obtained from that key to change the project_id of that same credential, re-scoping it to any other project the user has roles in.) • Delete TOTP, SSH, or other credential types — credential wipe/DoS • Create new credentials of any type via POST /v3/credentials (also unblocked for ec2credential tokens — see bug 2153453 for the related CREATE gap) Steps to reproduce (PATCH TOTP seed via ec2credential token): 1. User creates an ec2 credential and a TOTP credential 2. Attacker obtains the ec2 access/secret keys (e.g., from a shared server) 3. Attacker calls POST /v3/ec2tokens (via a service account) to obtain an ec2credential token 4. Attacker calls PATCH /v3/credentials/{totp_cred_id} with the new TOTP seed using that token → 200 OK 5. User's authenticator app is now invalid; attacker controls the MFA seed Steps to reproduce (project_id scope escalation): 1. User has ec2 credential scoped to Project A (member), and also has admin role in Project B 2. Attacker obtains the ec2 access/secret 3. Attacker gets ec2credential token, calls PATCH /v3/credentials/{ec2_cred_id} with {"project_id": "<project_B_id>", "blob": "..."} 4. Next ec2tokens call returns a token scoped to Project B with admin role Root cause: credentials.py patch() and delete() handlers have no guard against delegated token methods. post() has a partial guard (_check_unrestricted_application_credential) that bug 2153453 is extending, but patch() and delete() have no equivalent. The _validate_blob_update_keys guard only fires for existing ec2-type credentials and only validates blob key stability, not the token method. Proposed fix: Add a _require_primary_auth guard to POST, PATCH, and DELETE in credentials.py (and users.py OS-EC2 endpoint) that blocks any token whose methods list contains no primary authentication method: _PRIMARY_METHODS = frozenset({'password', 'totp', 'mapped', 'token'}) def _require_primary_auth_for_credential_write(token): if not _PRIMARY_METHODS.intersection(token.methods): raise exception.ForbiddenAction( action=_("Modifying credentials requires primary " "authentication (password, totp, or mapped).") ) This covers ec2credential, application_credential, oauth1, and trust tokens by default, and any future delegated method without needing per-type guards. It also handles third-party custom credential types. Note: This is the tip of the iceberg. EC2-derived tokens and application credential tokens produce fully-privileged project-scoped Keystone tokens usable against any OpenStack service API. Nova's keypair API (POST/DELETE /v2/{project_id}/os-keypairs) has the same structural exposure — a stolen ec2 key can add attacker-controlled SSH keypairs to a project. This behavior is undocumented -- one might assume that EC2 tokens work only on EC2/S3 APIs. Nova and other services do not introspect token methods; enforcement there would require a broader cross-project effort. Note2: Type is a free-form string, no validation or whitelist. Any auth plugin, integration, or third-party service can store credentials under custom types. So any restrictions might interfere with legitimate, custom usage. Severity: High Affects: All Keystone versions with ec2credentials enabled Related: bug 2153453 (credential creation via delegated tokens), bug 2158970 (Adding/removing TOTP credentials requires no MFA re-auth)
