Vulnerabilidades en servicios SSO permitirían saltar controles de autenticación

Se ha desvelado estos días una nueva vulnerabilidad sobre SSO (un tipo de vulnerabilidad, mejor dicho) que permite a un atacante hackear cuentas corporativas, según cuentan desde el grupo NCC.

La tecnología de Single Sign-On, implementada sobre mecanismos de autenticación y control de accesos, permiten a un usuario de un servicio -personal o corporativo- acceder a un amplio abanico de aplicaciones con un inicio de sesión único, mediante mecanismos de federación (confianza mutua) entre proveedores/servicios, normalmente terceras partes.

Es una tecnología muy conveniente para el usuario y también para el administrador, por eso no es raro que su adopción sea tremenda a día de hoy. Pero además de dejarnos manejar diferentes servicios con una única cuenta (por ejemplo, la de Google) y reducir el número de contraseñas que atiende un help-desk, tiene sus inconvenientes.

Vulnerabilidades de inyección XML sobre SAML

SSO también mejora la seguridad, en teoría. Pero Adam Roberts, de NGC Group, ha descubierto un conjunto de vulnerabilidades en varios servicios SSO, que emplean el languaje SAML para autenticar al usuario. SAML equivale a Security Assertion Markup Language y es un equivalente del XML empleado en negociaciones de seguridad de tipo segundo factor de autenticación, además de en mecanismos de federación.

Se resume en lo siguiente:

El fallo descubierto posibilitaría la modificación de respuestas SAML generadas por un Identitiy Provider, por tanto podrían conseguir acceso no autorizado a cuentas de usuario, o escalar privilegios dentro de una aplicación.

NCG

Detalles

La tecnología de autenticación federada o multifactor requiere que las diferentes partes (cliente, servidor que actúa como Proveedor de Identidades y servidor que actúa como proveedor de servicio) hablen el mismo idioma y realicen unos pasos para autenticar al usuario. Esta tecnología se integra también con Active Directory y desde hace algún tiempo, también con Azure Active Directory.

Mediante la definición de una serie de perfiles en directorios y configuración del Identity provider, un usuario obtiene acceso a las aplicaciones corporativas que debería tener, ni más ni menos. A no ser que alguien consiga inyectar contenido en la aserción SAML enviada por una parte.

Dependiendo de la ubicación del flujo donde se introduzca un cambio y de la configuración del SP (Service Provider) podrían incluirse nuevos roles, modificar el receptor de la aserción o inyectar un nombre de usuario diferente.

Los fallos potenciales normalmente se dan porque los proveedores de identidad han utilizado implementaciones poco seguras basadas en plantillas, para construir los mensajes SAML/XML. Esto se aprovecha mediante el uso de herramientas regex, mediante un lenguaje de plantilla o simplemente, usando la concatenación.

Una inyección XML sobre SAML otorgaría a los atacantes un control total sobre las cuentas de usuario. Pero, en este caso, la dificultad de implementación del ataque supone un riesgo bajo.

¿Estoy afectado por este problema?

Fallos como este pueden normalmente advertirse utilizando patrones de inyección (payloads) comunes de tipo XML. Mediante el uso de herramientas (ejemplo) por parte de los tester.

Como conclusión, los desarrolladores de los Identity Provider deberían verificar su códigoy asegurar que los datos cuya fuente es el usuario (user controlled data) no está siendo incluida dentro de una aserción SAML de forma insegura.

Es muy recomendable además implementar la firma de aserciones SAML mediante clave público-privada, siempre que sea posible.

Por supuesto, desde la óptica de los pentesters o Red Team, debería recogerse este caso de ataque para ser incluido en baterías sucesivas.

En cualquier caso, los protocolos como este son fáciles de catalogar como vulnerables, pero de ahí a explotar la vulnerabilidad con éxito, hay mucha distancia.