GHSA-gx67-694c-655c: AshAuthentication TOTP setup lets a user install their own authenticator secret on another user's account
Summary
Authorization Bypass Through User-Controlled Key vulnerability in team-alembic ashauthentication allows a user with an account to install a TOTP secret they control on another user's account, and then sign in as that user or hold their second factor.
AshAuthentication.Strategy.Totp.ConfirmSetupChange verified a setup token but did not check that it was issued to the record being confirmed, so an attacker's own pending secret could be confirmed onto another user's record. The TOTP setup changes, ConfirmSetupChange, GeneratePendingSetupChange and GenerateSecretChange, also marked their changesets as AshAuthentication interactions, which the standard AshAuthenticationInteraction policy bypass lets through. A policy limiting setup and confirmsetup to the actor's own record therefore never ran when an application exposed those actions by record key, and a direct setup call on another user's record returned that user's pending secret and setup token.
This issue affects ashauthentication: from 5.0.0-rc.0 before 5.0.0-rc.16.
Workarounds
Do not expose setup or confirmsetup on a record the caller chooses. Call them through AshAuthentication.Strategy.Totp.Actions with the signed-in user, as the built-in routes do.
Configurations
An application exposes the TOTP setup or confirmsetup action on a record the caller identifies, for example through AshJsonApi, AshGraphql or a controller that passes a looked-up user to AshAuthentication.Strategy.Totp.Actions.confirmsetup/3, and the attacker can read the victim's user record. Installing the attacker's secret requires confirmsetupenabled? true; signing in with it alone requires signinenabled? true. The routes AshAuthentication and AshAuthenticationPhoenix provide always use the signed-in user and are not affected.
Other sources
Authorization Bypass Through User-Controlled Key vulnerability in team-alembic ashauthentication allows a user with an account to install a TOTP secret they control on another user's account, and then sign in as that user or hold their second factor.
AshAuthentication.Strategy.Totp.ConfirmSetupChange verified a setup token but did not check that it was issued to the record being confirmed, so an attacker's own pending secret could be confirmed onto another user's record. The TOTP setup changes, ConfirmSetupChange, GeneratePendingSetupChange and GenerateSecretChange, also marked their changesets as AshAuthentication interactions, which the standard AshAuthenticationInteraction policy bypass lets through. A policy limiting setup and confirmsetup to the actor's own record therefore never ran when an application exposed those actions by record key, and a direct setup call on another user's record returned that user's pending secret and setup token.
This issue affects ashauthentication: from 5.0.0-rc.0 before 5.0.0-rc.16.
— OSV
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.16 - Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.16 - Compensating control
Call TOTP setup and confirm_setup through AshAuthentication.Strategy.Totp.Actions with the signed-in user, as the built-in routes do; do not expose setup or confirm_setup on a record selected by the caller.
Event History
Frequently Asked Questions
Which deployments are affected?
Affected versions are ash_authentication 5.0.0-rc.0 through versions before 5.0.0-rc.16. Exposure depends on whether the application exposes TOTP setup or confirmation actions against a record selected by the caller.
What does an attacker need to exploit this?
The attacker needs an account and the ability to invoke setup or confirmation for another user's record. They can use a pending TOTP secret from their own account to confirm setup on the target record, then use that factor to sign in as the target or retain control of its second factor.
Does a policy restricting setup actions to a user's own record prevent exploitation?
Not necessarily. The affected TOTP setup changes were marked as AshAuthentication interactions, allowing the standard AshAuthenticationInteraction policy bypass to skip policies intended to limit setup and confirm_setup to the actor's own record.
What can be done before upgrading?
Do not expose setup or confirm_setup for a record chosen by the caller. Invoke these operations through AshAuthentication.Strategy.Totp rather than allowing direct actions addressed by a record key.
How can we determine whether an application is exposed?
Review whether callers can directly invoke setup or confirm_setup using another user's record key. A direct setup call on another user's record could return that user's pending secret and setup token in affected versions.