GHSA-x585-4vv8-2mh2: Rucio: Unauthenticated administrator impersonation through SSH challenge tokens
Summary
SSH challenge tokens are mistakenly accepted as valid credentials during the authentication token validation process.
While an SSH challenge token is intended as a short-lived nonce for use in a subsequent SSH key exchange, the function to validate authentication tokens does not differentiate between these and actual authentication tokens. Because challenge tokens are generated based on an account name provided via headers without requiring prior authentication, an unauthenticated attacker can request a valid "challenge" token for any account (including administrative ones) and use it to authenticate against other API endpoints.
Proof of Concept
The vulnerability exists because SSH challenge tokens are stored in the same database table as regular authentication tokens and validateauthtoken in lib/rucio/core/authentication.py accepts these "challenge" tokens. An attacker can obtain a challenge token for an account such as “root” via the REST API and then present it as a valid authentication bearer token:
1. Request a challenge token for an arbitrary account (e.g., "root"): curl -i -H "X-Rucio-Account: root" https://rucio/auth/sshchallengetoken 2. The server returns a 200 OK with the header X-Rucio-SSH-Challenge-Token. 3. The attacker can then use this specific token within the ten-second challenge lifetime as an authentication credential in subsequent requests to the Rucio API: curl -H "X-Rucio-Auth-Token: $CHALLENGETOKEN" https://rucio/accounts/whoami
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/rucioto a version that resolves this vulnerability.Fixed in 41.1.1 - Upgrade
Upgrade
pip/rucioto a version that resolves this vulnerability.Fixed in 40.4.2 - Upgrade
Upgrade
pip/rucioto a version that resolves this vulnerability.Fixed in 38.6.1 - Upgrade
Upgrade
pip/rucioto a version that resolves this vulnerability.Fixed in 35.9.1
Event History
Frequently Asked Questions
Who can exploit this issue?
An unauthenticated network attacker can exploit it. They can request an SSH challenge token for an arbitrary account by supplying that account name in the X-Rucio-Account header, including an administrative account such as root.
What access does an attacker gain after obtaining a challenge token?
The token can be presented as an authentication bearer token to other API endpoints because challenge tokens are accepted during authentication-token validation. This allows the attacker to authenticate as the account named in the challenge-token request, including an administrator.
How can I check whether an instance is affected?
In a controlled test environment, request an SSH challenge token for an arbitrary account without authenticating, then determine whether that returned token is accepted as a bearer credential by another API endpoint. An affected instance does not distinguish the SSH challenge token from a normal authentication token.