Ory Kratos's setting required_aal `highest_available` does not properly respect code + mfa credentials
Date: 2024-09
Affected: go/github.com/ory/kratos
Attack vector: auth-bypass
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2024-45042
CWE: CWE-287
CVSS: 4.4 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N)

## Preconditions - The `code` login method is enabled with the `passwordless_enabled` flag set to `true` . - A 2FA method such as `totp` is enabled. - `required_aal` of the whomai check or the settings flow is set to `highest_available`. AAL stands for Authenticator Assurance Levels and can range from 0 (no factor) to 2 (two factors). - A user uses the `code` method as the **only** login method available. They do not have a password or any other first factor credential enabled. - The user has 2FA enabled. - The user’s `available_aal` is incorrectly stored in the database as `aal1` or `aal0` or `NULL`. - A user signs in using the code method, but does not complete the 2FA challenge. **Example server configuration** Below you will find an vulnerable example configuration. Keep in mind that, for the account to be vulnerable, the account must have no first factor except the `code` method enabled plus a second factor. ``` selfservice: methods: code: # The `code` login method is enabled with the `passwordless_enabled` flag set to `true` passwordless_enabled: true totp: # 2FA method such as `totp` is enabled enabled: true flows: settings: # This is set required_aal: highest_available session: whoami: # Or this required_aal: highest_available ``` ## Impact Given the preconditions, the `highest_available` setting will incorrectly assume that the identity’s highest available AAL is `aal1` even though it really is `aal2


Mitigations:

Architectural layers (MAESTRO):