Microsoft «sin autenticación» es vulnerable a una simple suplantación de correo electrónico

En junio, investigadores revelaron una vulnerabilidad en Azure Active Directory y aplicaciones de terceros llamadas «sin autenticación,» que podría resultar en una apropiación total de la cuenta. Esta es sólo una de las muchas vulnerabilidades en el software y sistemas de Microsoft como Active Directory que pueden explotarse., poniendo en riesgo a las organizaciones. Aunque Microsoft ha respondido a la vulnerabilidad, los desarrolladores deben realizar cambios de código en sus aplicaciones, y organizaciones Necesita una protección de identidad sólida para evitar el uso indebido de cuentas privilegiadas por parte de administradores deshonestos.

¿Qué es OAuth??

El nombre «sin autenticación» es una implementación de Microsoft del protocolo de autorización OAuth. OAuth supone que el proveedor de identidad enviará a la aplicación que está intentando autenticar un conjunto de datos necesarios para iniciar sesión.. Esta información también debe contener un identificador único eso prevents spoofing the login attempt.

La ventaja de utilizar OAuth es su comodidad al utilizar docenas de servicios. Como solo necesitas una cuenta para iniciar sesión en todas partes, no es necesario recordar las contraseñas de todos ellos. Es posible revocar permisos en cualquier momento si ya no desea Aplicación para acceder a tus recursos.. Probablemente lo hayas usado al menos una vez., si tienes google, Manzana, Facebook u otra cuenta. Cada vez que veas la opción de «Iniciar sesión con Microsoft» o «Iniciar sesión con Facebook» - eso es todo.

La vulnerabilidad nOAuth permite la suplantación de correo electrónico

Los investigadores encontraron a «sin autenticación» vulnerabilidad, que se encuentra en la confianza entre Azure AD (proveedor de identidad) y una aplicación (parte que confía). En escenarios de Azure AD, cualquiera puede generar fácilmente ese reclamo simplemente falsificando la dirección de correo electrónico. Esto es posible para 2 razones: La suite Azure permite cambiar los dominios de las direcciones de correo electrónico incluso sin la validación de la propiedad del dominio. También por el uso de dirección de correo electrónico como identificador de usuario en el «sin autenticación».

¿Cuál es la mala configuración de Azure??

El problema se origina en una mala configuración que permite a actores maliciosos modificar los atributos del correo electrónico en cuentas de Azure AD’ «Información del contacto» sección. Attackers can hijack victim accounts explotando el «Iniciar sesión con Microsoft» característica. Para ejecutar el ataque, el adversario debe crear y acceder a una cuenta de administrador de Azure AD, cambiar su dirección de correo electrónico a la de la víctima, y aproveche la funcionalidad de inicio de sesión único en una aplicación o sitio web vulnerable. Si la aplicación de destino combina cuentas de usuario sin la validación adecuada, el El atacante obtiene el control total. sobre la cuenta de la víctima, Incluso si los la víctima no tiene una cuenta de Microsoft. Esto permite al atacante establecer persistencia., extraer datos, y realizar otras actividades posteriores a la explotación basadas en la funcionalidad de la aplicación.

La siguiente captura de pantalla muestra dos inicios de sesión OAuth diferentes para la misma aplicación., siendo todos los valores de reclamo iguales excepto el «correo electrónico» afirmar.

La naturaleza mutable y no verificada de las direcciones de correo electrónico causa la vulnerabilidad en Azure AD. Microsoft no recomienda enviar reclamos de autorización por correo electrónico.

Cómo contrarrestar los ataques basados ​​en identidad en AD y Azure AD ?

Microsoft tiene Guía publicada para que los desarrolladores aborden las vulnerabilidades. en sus aplicaciones. La empresa recomienda no utilizar notificaciones por correo electrónico para la identificación o autorización del usuario y, en su lugar, sugiere seguir las mejores prácticas para la validación de tokens.. Además, desarrolladores deberían revisar el código fuente de su aplicación para comprobar si hay patrones de autenticación incorrectos.

Para garantizar que su lógica de autorización sea segura, validar la siguiente información en reclamos:

• El actor (aplicación cliente) está autorizado.
  Una aplicación cliente que actúa en nombre de un usuario debe estar autorizada. Utilizar el SCP reclamar para validar permisos, limitado a usuarios’ Necesidades y principios de mínimo privilegio..
• El ID del inquilino del token coincide con el ID de la ubicación de almacenamiento..
  Siempre verifique que el token TID coincide con el ID utilizado para almacenar los datos de la aplicación. Solo se debe acceder a los datos almacenados en el contexto de un inquilino dentro de ese inquilino.. Never allow data from one tenant ser accedido por otro.
• El token especifica la audiencia prevista..
  El AUD El reclamo especifica la audiencia prevista del token.. Antes de validar reclamaciones, siempre verifique que el valor del reclamo aud en el token de acceso coincida con la API web – ya que el valor puede variar dependiendo de cómo el cliente solicitó el token.
• El tema del token es apropiado..
  Determine si el usuario o la aplicación está autorizado verificando reclamos específicos para SUB o OID o si el sujeto pertenece a un rol o grupo relevante utilizando ROLES, GROUPS, and WIDS reclamos. Utilizar el TID and OID valores de reclamo inmutables como una clave combinada para los datos de la aplicación y el acceso del usuario.