Conozca Silver SAML: SAML dorado en la nube

Principales resultados

• Golden SAML, una técnica de ataque que explota el protocolo de inicio de sesión único SAML, se utilizó como un exploit posterior a la brecha, agravando el devastador ataque de SolarWinds de 2020, una de las mayores brechas del siglo XXI.
• El ataque a la cadena de suministro de SolarWinds afectó a miles de organizaciones de todo el mundo, incluido el Gobierno de Estados Unidos, mediante el despliegue de código malicioso en el software de gestión y supervisión de TI Orion de la empresa.
• A raíz de este ataque, CISA y los expertos en ciberseguridad animaron a las organizaciones con entornos de identidad híbridos a trasladar la autenticación SAML a un sistema de identidad en la nube como Entra ID.
• Los investigadores de Semperis Tomer Nahum y Eric Woodruff han descubierto una nueva aplicación de SAML Dorado, que puede explotarse incluso en organizaciones que han seguido las recomendaciones de seguridad anteriores destinadas a defenderse de SAML Dorado.
• La nueva técnica de ataque, denominada Silver SAML, permite explotar SAML para lanzar ataques desde un proveedor de identidades como Entra ID contra aplicaciones configuradas para utilizarlo para la autenticación, como Salesforce.
• Hasta donde Semperis sabe, no se ha informado de ningún ataque que utilice Silver SAML.
• Los investigadores de Semperis califican esta vulnerabilidad como un riesgo MODERADO para las organizaciones. Dependiendo del sistema comprometido, si Silver SAML se utiliza para obtener acceso no autorizado a aplicaciones y sistemas críticos para el negocio, el riesgo es SEVERO.

Golden SAML es una conocida técnica de ataque descubierta por CyberArk y publicada por Shaked Reiner. Durante años, Golden SAML ha sido conocido por su extracción de certificados de firma de Active Directory Federation Services (AD FS) y su uso de esos certificados para falsificar respuestas de autenticación SAML. Hoy, presentamos una nueva aplicación de Golden SAML-en Microsoft Entra ID y sin el uso de AD FS. Conozca Silver SAML.

¿Qué es SAML Plata?

En la actualidad, muchas organizaciones utilizan Entra ID como proveedor de identidad (IdP) para aplicaciones de software como servicio (SaaS) y de línea de negocio (LOB). SAML es el principal medio de autenticación para estas aplicaciones.

Dentro de Entra ID, Microsoft proporciona un certificado autofirmado para la firma de respuestas SAML. Alternativamente, las organizaciones pueden optar por utilizar un certificado generado externamente. Sin embargo, esa opción introduce un riesgo de seguridad.

Cualquier atacante que obtenga la clave privada de un certificado generado externamente puede falsificar cualquier respuesta SAML que desee y firmar esa respuesta con la misma clave privada que posee Entra ID. Con este tipo de respuesta SAML falsificada, el atacante puede entonces acceder a la aplicación-como cualquier usuario.

La prueba de concepto discutida en este post se centra en Entra ID. Pero este ataque puede aprovecharse de cualquier IdP que permita la importación de certificados de firma SAML generados externamente.

Para esta prueba de concepto, Semperis ha creado y publicado una nueva herramienta, llamada SilverSAMLForger, que puede utilizarse para falsificar respuestas SAML firmadas. Puedes encontrar SilverSAMLForger en GitHub.

Antecedentes: SAML, Golden SAML y el ataque de SolarWinds

SAML es un elemento básico de la autenticación moderna. Por ejemplo, el 63% de las aplicaciones de Entra ID Gallery se basan en SAML para su integración. Las integraciones multi-nube con Amazon Web Services (AWS), Google Cloud Platform (GCP) y otros dependen de SAML. Y muchas organizaciones siguen invirtiendo en SAML para aplicaciones SaaS y LOB debido a la simplicidad de su implementación.

SAML dorado y Solorigate

Como parte del ataque a la cadena de suministro global de SolarWinds (también conocido como Solorigate), Golden SAML fue uno de los vectores de ataque más innovadores de los atacantes.

Los atacantes obtuvieron acceso inicial a SolarWinds insertando código malicioso en la plataforma Orion de la compañía, utilizada para la monitorización de infraestructuras y la gestión de TI. Más tarde, los atacantes utilizaron este punto de apoyo para moverse lateralmente en el entorno AD FS. Desde allí, robaron el material de clave privada utilizado para firmar las respuestas SAML.

Como resultado de este ataque a SAML dorado posterior a la brecha, muchas organizaciones priorizaron el traslado de aplicaciones a Entra ID para la autenticación SAML. Este cambio eliminó la necesidad de gestionar una compleja infraestructura de nivel 0, y las claves de firma SAML no se pueden exportar desde Entra ID. Incluso CISA recomienda que las organizaciones con entornos de identidad híbridos trasladen la autenticación SAML a sistemas de identidad en la nube como Entra ID.

El problema de SAML y la firma de certificados

Por desgracia, muchas organizaciones gestionan mal los certificados de firma y debilitan la seguridad de SAML al utilizar certificados generados externamente. Según nuestras observaciones, las organizaciones empresariales tienden a:

• Generar certificados de firma autofirmados en un sistema cliente
• Generar certificados de firma a través de una infraestructura de clave pública (PKI) empresarial, como Active Directory Certificate Services (AD CS)
• Obtener y utilizar certificados de firma de una autoridad de certificación (CA) externa

Para agravar el problema, vemos organizaciones que toman estos certificados generados externamente y:

• Enviar archivos PFX de certificados y contraseñas a través de canales inseguros como Teams o Slack.
• Generar certificados en las máquinas cliente, dejando los certificados disponibles para su exportación en el almacén de certificados local de las máquinas.
• Generar certificados en servidores web, que suelen ejecutar Microsoft Internet Information Services (IIS), dejando los certificados disponibles para su exportación en el almacén de certificados local de las máquinas.

Incluso para las organizaciones que utilizan servicios como Azure Key Vault -un método más seguro para la gestión de secretos y certificados- pueden existir vectores de ataque. (Trataremos esos vectores en la siguiente sección).

El uso de un certificado generado externamente para la firma de respuestas SAML aumenta la superficie de ataque de cualquier IdP, incluyendo Entra ID. Hemos observado varias lecciones comunes en organizaciones que generan y gestionan certificados de firma SAML externamente, en lugar de hacerlo directamente dentro del Entra ID.

• Falta de cadena de confianza con los certificados autofirmados de Entra ID
• Incapacidad para aprovechar la revocación de certificados con certificados autofirmados.
• Necesidad de aplicar ciegamente una política corporativa definida a la gestión de certificados (normalmente basada en una o las dos razones anteriores).
• Sensación subjetiva de que los certificados autofirmados son "menos seguros".

Además, algunas organizaciones desean mantener una vida útil del certificado de firma SAML más larga que la predeterminada de Entra ID. Estas organizaciones emiten certificados externos, sin darse cuenta de que simplemente pueden emitir nuevos certificados desde Entra ID y configurar esos certificados para que tengan una vida útil más larga.

Muchas organizaciones no comprenden los matices de la utilización de certificados para la firma SAML; los certificados de firma simplemente se incluyen en sus directivas y políticas de gestión de certificados más amplias. Aunque las prácticas comunes de gestión y ciclo de vida de los certificados son importantes para muchos tipos de sistemas, no se aplican ni deben aplicarse a los certificados que se utilizan para la firma SAML.

Una cadena de confianza no es relevante en SAML. La mayoría de los IdP y aplicaciones de proveedores de servicios (SP) ignoran cualquier cadena de confianza. A diferencia del escenario servidor/cliente que se ve con los navegadores web, un administrador es efectivamente una parte esencial de la cadena de confianza en las configuraciones SAML. El administrador debe configurar y especificar en qué certificado de firma confiar, específicamente en la aplicación.

La revocación de certificados tampoco es una práctica relevante con SAML. Si un certificado de firma se ve comprometido, un administrador debe revocar (es decir, sustituir) ese certificado en el SP y el IdP. El perfil de interoperabilidad de metadatos SAML 2.0 versión 1.0 de OASIS indica específicamente abstenerse de utilizar listas de revocación, el protocolo de estado de certificados en línea (OCSP) u otros mecanismos para la validación de claves. En su lugar, debe hacer que el IdP elimine las claves comprometidas de los metadatos SAML.

Importación de certificados externos

Como muestra la Figura 1, usted puede configurar certificados autofirmados en una aplicación empresarial (Okta, en este ejemplo) en el centro de administración de Entra a través de la aplicación Manage > Single sign-on > SAML > SAML Certificates settings.

En el panel Certificado de firma SAM L, puede importar su propio certificado para firmar la respuesta o las aserciones SAML(Figura 2).

¿Qué ocurre con Azure Key Vault?

Tenemos que dedicar un momento a hablar de Azure Key Vault: uno de los lugares donde podrían almacenarse certificados autofirmados. Queríamos determinar si un atacante podría extraer claves de Key Vault. Spoiler: Pueden. (Si tu organización no utiliza Key Vault, siéntete libre de saltar a la siguiente sección).

Azure Key Vault es una popular solución de gestión de claves proporcionada por Microsoft. Key Vault permite almacenar y gestionar de forma segura secretos, claves de cifrado y certificados.

Como la mayoría de los servicios en la nube, Key Vault tiene dos planos que rigen el acceso y la gestión: el plano de control y el plano de datos.

• Plano de control. Los roles y permisos asignados al plano de control están asociados con tareas administrativas y ajustes de configuración de Key Vault. Los usuarios, grupos o principales de servicio a los que se asignan permisos de plano de control pueden configurar políticas de acceso, crear almacenes de claves y realizar otras tareas de gestión. Los derechos se pueden conceder de forma granular a una bóveda individual, pero a menudo se conceden a nivel de grupo de recursos, suscripción o grupo de gestión.
• Plano de datos. El plano de datos se refiere a los datos reales almacenados en una cámara acorazada de claves: secretos, claves y certificados. Los derechos asignados en el plano de datos controlan qué usuarios o responsables de servicios pueden leer y escribir material criptográfico en y desde el depósito de claves. Estos derechos incluyen la capacidad de leer las claves privadas de los certificados, lo cual es preocupante si dichas claves se utilizan para la firma de respuestas SAML.

Los permisos de Key Vault se pueden conceder mediante el control de acceso basado en funciones (RBAC) o mediante políticas de acceso a Key Vault.

El modelo de permisos RBAC

Con el modelo RBAC(Figura 3), cualquier usuario que tenga una de las siguientes funciones RBAC puede recuperar un certificado de almacén de claves.

• Administrador de Key Vault
• Responsable de Certificados de Bóveda de Llaves
• Administrador de acceso a datos de Key Vault. Esta función le permite gestionar el acceso añadiendo o eliminando asignaciones de funciones. Por lo tanto, puede asignar la función Administrador de almacén de claves o Responsable de certificados de almacén de claves a cualquier entidad.
• Colaborador de almacén de claves. Esta función no concede permisos de plano de datos, pero permite actualizar la política de acceso al almacén de claves si también se utiliza el modelo de permisos de políticas de acceso.

La Figura 4 muestra un ejemplo de los permisos concedidos a la función Administrador de Key Vault.

Una persona con el rol Key Vault Contributor, que no tiene permisos de plano de datos para acceder a los secretos y certificados del almacén de claves, puede extraerlos si se utilizan políticas de acceso. Este rol sí tiene el permiso de plano de control Microsoft .KeyVault/*. Este permiso puede traducirse a Microsoft. KeyVault/vaults/accessPolicies/write, lo que permite al titular escribir políticas de acceso a almacenes de claves y extraer secretos de almacenes de claves.

Si puede añadir permisos RBAC a nivel de grupo de recursos o de suscripción, obteniendo el control de una cuenta de propietario de grupo de recursos o de una cuenta de usuario que tenga el permiso Administrador de control de acceso basado en funciones RBAC o de cualquier usuario con permiso Microsoft.Authorization/roleAssignments/write, puede añadir permisos de almacén de claves. La bóveda de claves heredará entonces esos permisos. Como se mencionó anteriormente, algunos roles RBAC también pueden modificar directamente las políticas de acceso a Key Vault.

También se puede acceder a los depósitos de claves a través de cuentas de automatización e identidades gestionadas que tengan los permisos necesarios.

El modelo de permisos de las políticas de acceso a Key Vault

En este modelo, también puede conceder permisos de acceso a Key Vault a un usuario, servicio o grupo. Puede elegir entre permisos de clave, permisos de secreto y permisos de certificado(Figura 5).

Puede añadir políticas de acceso en el panel Políticas de acceso de Key Vault(Figura 6).

Cualquier atacante que obtenga el control de cualquier usuario, principal de servicio o grupo que tenga permiso para recuperar el archivo PFX que se utiliza para firmar las afirmaciones o respuestas SAML para el SP atacado, ya sea a través de políticas de acceso RBAC o Key Vault, puede realizar un ataque Silver SAML en ese SP.

SAML y Entra ID

SAML, en su versión actual 2.0, tiene casi 20 años. OASIS publicó el protocolo en marzo de 2005. Desde entonces, muchas empresas han adoptado SAML para la autenticación federada y las soluciones SSO basadas en web. La principal implementación del protocolo -y el caso de uso dentro de Entra ID- es aprovechar el perfil SSO del navegador web.

Un flujo de perfil SAML típico tiene tres componentes básicos:

• El proveedor de servicios (SP), o aplicación; también conocido comúnmente como la parte que confía (RP) en el ecosistema de Microsoft.
• El proveedor de identidad (IdP), que en nuestra prueba de concepto es Entra ID
• El agente de usuario, normalmente el navegador web del cliente (usuario final).

Los usuarios interactúan con las aplicaciones para la autenticación de muchas maneras, dependiendo de si la aplicación está configurada o admite flujos iniciados por el SP o por el IdP.
En un flujo iniciado por el SP(Figura 7), se produce la siguiente secuencia:

1. El usuario navega hasta una URL de la aplicación (SP).
2. El SP genera una solicitud SAML(Figura 8) y redirige al usuario a Entra ID (IdP).
3. Entra ID consume la solicitud SAML.
4. Si el usuario aún no se ha autenticado en Entra ID, se le pedirá que se autentique.
5. El usuario se autentica con éxito en Entra ID.
6. Entra ID genera una respuesta SAML(Figura 9) y redirige al usuario al SP.
7. El SP verifica la respuesta SAML.
8. El usuario recibe acceso a la aplicación.

En un flujo iniciado por un IdP(figura 10), se produce la siguiente secuencia:

1. El usuario navega a myapps.microsoft.com.
2. Si el usuario aún no se ha autenticado en Entra ID, se le pedirá que se autentique.
3. El usuario se autentica con éxito en Entra ID.
4. Entra ID proporciona una lista de aplicaciones disponibles para el usuario en myapps.microsoft.com.
5. El usuario selecciona la aplicación de destino.
6. Entra ID genera una respuesta SAML y redirige al usuario al SP.
7. El SP verifica la respuesta SAML.
8. El usuario recibe acceso a la aplicación.

El contenido de una aserción SAML incluye varios bits de información sobre el usuario final, o sujeto, en una serie de pares clave-valor. Esta información se suele denominar afirmaciones SAML e incluye datos como:

• El asunto. La aplicación utiliza este componente obligatorio como identificador único del usuario. En muchas implementaciones, el asunto es el nombre de usuario principal (UPN) o la dirección de correo electrónico del usuario.
• Información sobre atributos. Esta información puede incluir el nombre, los apellidos, la dirección de correo electrónico y el nombre para mostrar del usuario. La pertenencia a un grupo o los roles suelen proporcionarse para que la aplicación pueda tomar decisiones de autorización sobre los derechos que debe tener el usuario.
• Otra información contextual de autenticación. Esta información puede incluir el tipo de autenticación utilizado, el emisor y el público, e información de fecha y hora que indique el periodo de validez de la respuesta SAML.

¿Cómo asegurarse de que la respuesta SAML, que maneja el usuario, no ha sido manipulada? Aquí es donde entra en juego la firma.

Entra ID soporta tanto la firma de respuesta SAML como la firma de aserción SAML. A un alto nivel, el propósito de la firma de respuesta y aserción es verificar que el contenido de la respuesta no ha sido manipulado y que la aplicación puede confiar en la información de la respuesta. La aplicación utiliza la firma para validar que la respuesta ha sido generada por el IdP, que posee la clave privada utilizada para firmar la respuesta.

Por ello, el robo de la clave privada de firma es un problema crítico. Con la clave de firma en la mano, un actor de amenaza puede falsificar una copia de una respuesta SAML, realizando un ataque Silver SAML.

Realizar un ataque Silver SAML

Para probar la teoría de que la técnica de ataque Golden SAML puede volverse contra Entra ID -en lo que hemos denominado un ataque Silver SAML- hemos creado la herramienta SilverSAMLForger. Esta herramienta genera una respuesta SAML que duplica una respuesta Entra ID, firmando esa respuesta con un certificado proporcionado.

Nuestra prueba de concepto de Silver SAML se basa en la premisa de que una organización está utilizando un certificado de firma generado externamente, que un atacante ha obtenido utilizando uno de los métodos previamente discutidos. Estudiamos la aplicación de Silver SAML tanto en flujos iniciados por SP como en flujos iniciados por IDP, ya que ambos son susceptibles de sufrir ataques.

Silver SAML en un flujo iniciado por un SP

Ataque Silver SAML usando Entra ID como el IdP y Okta como el SP. Para lanzar el ataque en un flujo iniciado por el SP, necesitábamos interceptar la solicitud SAML y reemplazar el contenido de la respuesta SAML con la respuesta SAML falsificada que creamos(Figura 11). Pudimos realizar estas tareas fácilmente utilizando Burp Suite.

Para este ejemplo, intentamos falsificar una respuesta SAML para el usuario oktaAdministrator@xd6z7.onmicrosoft.com. Este usuario es un Super Administrador en Okta. No tenemos la contraseña del usuario ni el dispositivo conectado MFA del usuario (si está configurado).

En primer lugar, necesitamos algunos atributos en la información de las reclamaciones SAML de acuerdo con lo que se configuró cuando la aplicación se registró en el IdP. Por ejemplo, necesitamos el UPN, apellido, nombre, displayName, y objectID. Un atacante puede encontrar fácilmente estos atributos en el centro de administración de Entra o usando la API Microsoft Graph.

También necesitábamos conocer el destinatario y la audiencia. Esa información estaba disponible en el centro de administración de Entra, en el panel de inicio de sesión único de la aplicación(Figura 12).

Ejecutando SilverSAMLForger.exe con los parámetros requeridos se obtiene una cadena codificada en base64 y URL(Figura 13). Ahora podemos copiar esta respuesta SAML falsificada.

Copiamos la respuesta SAML generada a la solicitud HTTPS interceptada(Figura 14) y modificamos la respuesta a la falsificada(Figura 15).

Después de enviar la respuesta falsificada, podemos dejar de interceptar ya que ahora hemos iniciado sesión como el usuario objetivo(Figura 16).

Ataque Silver SAML en un flujo iniciado por un IdP

Los flujos iniciados por IdP conllevan un riesgo mucho mayor para la organización porque no se requiere interacción con Entra ID. Si la aplicación soporta flujos iniciados por IdP, puede enviar directamente una respuesta SAML a la aplicación(Figura 17).

Para esta parte de la prueba de concepto, intentamos realizar un ataque iniciado por IdP contra Salesforce.

Nos dirigimos al usuario Patti Fernandez, falsificando una respuesta con su UPN como asunto. La respuesta(Figura 18) se firmó utilizando el mismo certificado de firma SAML que se configuró para Salesforce en Entra ID.

Descifrando esta respuesta, se puede ver que es una respuesta falsificada para Patti(Figura 19).

En Burp Suite, utilizamos Repeater para enviar directamente la respuesta SAML falsificada a nuestra instancia de Salesforce(Figura 20).

Al abrir la respuesta en un navegador, comprobamos que hemos iniciado sesión en Salesforce como Patti, sin ninguna interacción con Entra ID(Figura 21).

Defensa contra los ataques Silver SAML

Para protegerse eficazmente contra los ataques Silver SAML en Entra ID, su organización debe utilizar únicamente certificados autofirmados Entra ID para fines de firma SAML.

Los certificados de firma SAML se almacenan en el principal de servicio para una aplicación SAML en Entra ID. Puede utilizar la Graph API para ver la información que se expone sobre la clave de firma. Simplemente llame a una solicitud GET a la siguiente URI:

https://graph.microsoft.com/beta/servicePrincipals/{serviceprincipalobjectid}

La Figura 22 muestra un ejemplo de la información expuesta. Obsérvese que el material de la clave privada no es exportable, lo que impide a los atacantes recopilar la información que necesitan para lanzar un ataque SAML Silver.

Los administradores globales, los administradores de aplicaciones, los administradores de aplicaciones en la nube y cualquier usuario en quien se delegue la propiedad de una aplicación pueden modificar qué claves de firma están disponibles y pueden importar una clave de firma externa. Aunque la aplicación asociada necesitará ser actualizada, las organizaciones deben limitar quién tiene propiedad sobre las aplicaciones en Entra ID. Como mínimo, supervise los cambios en las claves de firma SAML, especialmente si la clave no está cerca de su caducidad.

Las organizaciones pueden auditar los principales de servicio existentes que están configurados para SAML y comprobar el displayName. Si el certificado utilizado es generado por Microsoft, el certificado contendrá el valor CN=Microsoft Azure Federated SSO Certificate. Sin embargo, nada impide que un atacante importe un certificado externo que tenga el mismo nombre de asunto.

Las organizaciones también pueden monitorear los registros de auditoría de Entra ID en busca de cambios en PreferredTokenSigningKeyThumbprint bajo ApplicationManagement. Usted necesitará correlacionar esos eventos con los eventos de credenciales de Add service principal que se relacionan con el service principal. La rotación de certificados caducados es un proceso común, por lo que necesitará determinar si los eventos de auditoría son legítimos. Implementar procesos de control de cambios para documentar la rotación puede ayudar a minimizar la confusión durante los eventos de rotación.
Si una aplicación soporta tanto SAML como OpenID Connect (OIDC) para autenticación, usted podría considerar cambiar la integración con Entra ID para usar OIDC, mitigando este ataque. La complejidad de cambiar de SAML a OIDC depende en gran medida de cómo el desarrollador de la aplicación haya implementado los estándares.

Por el lado de la aplicación, los desarrolladores de aplicaciones pueden protegerse contra los ataques de varias maneras. (Sus opciones dependerán de los métodos y bibliotecas utilizados en su implementación de SAML).

• Exigir flujos iniciados por el SP, que protegen contra los flujos iniciados por el IdP, los tipos de ataques más peligrosos.
• Para los flujos iniciados por el SP, siga la especificación SAML y asegúrese de que las respuestas contengan un valor InResponseTo que se correlacione con una solicitud SAML asociada.
• Observe el tiempo en el que la aplicación recibe una respuesta SAML. El IdP indica una ventana de validez en la respuesta, pero los desarrolladores de aplicaciones pueden introducir más limitaciones lógicas a la ventana aceptable para recibir una respuesta en los flujos iniciados por el SP.
• Ofrecer la opción de utilizar OIDC, en lugar de SAML, para la integración.

Que Silver SAML no le pille por sorpresa

Al igual que el ataque Golden SAML, los ataques Silver SAML pueden ser leves o devastadores. A medida que crece la adopción de entornos de identidad híbridos y en la nube, esperamos ver más amenazas dirigidas a IdPs como Entra ID. Este post muestra cómo Silver SAML es posible con Entra ID, pero cualquier IdP que le permita usar certificados autofirmados es susceptible. Animamos a las organizaciones a tomar medidas decisivas ahora para cerrar las brechas y vulnerabilidades en estos entornos.

Divulgación

Este problema se notificó a través del Centro de respuesta de seguridad de Microsoft (MSRC) el 2 de enero de 2024. Microsoft respondió el 26 de febrero de 2024: "Después de una cuidadosa investigación, este caso ha sido evaluado como de diseño y no cumple los requisitos del MSRC para un servicio inmediato. No obstante, hemos compartido el informe con el equipo responsable del mantenimiento del producto o servicio. Ellos tomarán las medidas apropiadas según sea necesario para ayudar a mantener protegidos a los clientes."

Cronología

• 2 de enero de 2024: Creación del caso MSRC
• 3 de enero de 2024: Estado del caso cambiado a Revisión/Reprod.
• 17 de febrero de 2024: Revisión del artículo de investigación por el MSRC
• 26 de febrero de 2024: Respuesta del MSRC recibida
• 29 de febrero de 2024: Divulgación pública