CVE-2024-45042
Ory Kratos's `highest_available` setting does not properly respect code + mfa credentials
En resumen
Ory Kratos identifica incorrectamente a usuarios con autenticación de múltiples factores como si tuvieran un único factor, permitiendo acceso a endpoints sensibles sin verificación adecuada de MFA. Un atacante que obtenga la contraseña única de un usuario puede explotar esta configuración defectuosa para eludir controles de seguridad.
Detalle técnico
La configuración `highest_available` en Ory Kratos anterior a v1.3.0 falla en calcular correctamente el Authentication Assurance Level (AAL) para identidades con login solo por OTP, reportando incorrectamente AAL2 como AAL1. Esto permite que atacantes con OTP robada/adivinada accedan a endpoints de configuración y whoami sin sesiones válidas de AAL2, cuando la identidad tiene un valor `available_aal` incorrecto almacenado. La asignación de AAL en la sesión en sí no se ve afectada.
Resumen generado y traducido por IA a partir de la descripción oficial.
Ory Kratos is an identity, user management and authentication system for cloud services. Prior to version 1.3.0, given a number of preconditions, the `highest_available` setting will incorrectly assume that the identity’s highest available AAL is `aal1` even though it really is `aal2`. This means that the `highest_available` configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a `aal2` session, even though that should be disallowed. An attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect `available_aal` value stored, to exploit this vulnerability. All other aspects of the session (e.g. the session’s aal) are not impacted by this issue. On the Ory Network, only 0.00066% of registered users were affected by this issue, and most of those users appeared to be test users. Their respective AAL values have since been updated and they are no longer vulnerable to this attack. Version 1.3.0 is not affected by this issue. As a workaround, those who require MFA should disable the passwordless code login method. If that is not possible, check the sessions `aal` to identify if the user has `aal1` or `aal2`.
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N