Fecha de publicación inicial: 25/04/2023 10:00 h EST
Un investigador de seguridad informó hace poco sobre un problema en la compatibilidad de AWS, publicado recientemente (16 de noviembre de 2022), con dispositivos de autenticación multifactor (MFA) para las entidades principales de los usuarios de IAM. El problema que se informó solo podría haber surgido si se cumplían las tres condiciones siguientes: (1) que un usuario de IAM tuviera credenciales de clave de acceso prolongado (AK)/clave secreta (SK); (2) que el usuario de IAM tuviera el privilegio de agregar una MFA a su propia identidad sin utilizar una MFA; (3) que un administrador hubiera configurado los privilegios de acceso generales del usuario de IAM más allá del inicio de sesión en la consola para que fueran mayores después de agregar la MFA. En esas condiciones estrictas, la posesión de AK/SK por sí sola equivalía a la posesión de AK/SK y de una MFA previamente configurada.
Si bien los usuarios de IAM que podían agregar o eliminar un dispositivo de MFA asociado con su propia identidad siempre habían podido hacerlo únicamente con las credenciales de AK/SK, surgió un problema cuando la nueva característica se combinó con la autoadministración por parte de los usuarios de IAM de sus propios dispositivos de MFA, con acceso restringido antes de que el usuario agregara una MFA. Este patrón de autoadministración se documentó aquí, y esa página incluía un ejemplo de política de IAM para implementar el patrón. La combinación de la nueva característica de varias de MFA creó una incoherencia con ese enfoque. Gracias a la nueva característica, un usuario que solo tuviera credenciales de AK/SK podría agregar una MFA adicional sin utilizar una MFA previamente configurada, lo que permitiría tener solo AK/SK sin una MFA previamente configurada para obtener un acceso más amplio que el esperado por los clientes que utilizan la política de ejemplo.
Este problema no repercutió en el acceso basado en la Consola de administración de AWS, ya que siempre se requiere una MFA existente al iniciar sesión. Tampoco repercutió en los entidades principales federadas, que administran la MFA a través de su proveedor de identidad.
A partir del 21 de abril de 2023, el problema identificado se solucionó con el requisito de que los usuarios de IAM que ya tuvieran una o más MFA y que utilizaran credenciales de AK/SK para administrar sus propios dispositivos de MFA utilizaran primero sts:GetSessionToken y una MFA existente para obtener credenciales temporales habilitadas para la MFA a fin de firmar sus comandos de CLI o solicitudes de API antes de habilitar o deshabilitar los dispositivos de MFA por sí mismos. Hemos notificado directamente a un número muy reducido de clientes a través de su panel de estado personal que anteriormente habían asociado un dispositivo de MFA adicional mediante un mecanismo distinto de la Consola de administración de AWS. Recomendamos que los clientes notificados confirmen que sus configuraciones de MFA sean correctas. No se requiere ninguna otra acción por parte del cliente.
Nos gustaría agradecer a los investigadores de MWR Cybersec por identificar este problema y comunicarlo de manera responsable a AWS. Puede plantearnos preguntas o dudas relacionadas con la seguridad a través de aws-security@amazon.com.