¿Qué es la envoltura de firmas XML?

Los ataques de envoltura de elementos de firma tienen como objetivo eludir la autenticación y obtener acceso no autorizado manipulando la estructura de un documento XML sin invalidar su firma digital.

Un ataque de envoltura de firmas XML explota la brecha entre el proceso de validación de firmas y procesamiento de datos. El atacante inyecta un elemento duplicado o manipulado (como una aserción SAML falsificada o un cuerpo SOAP) fuera de la parte firmada, y la aplicación termina procesando los datos maliciosos.

El lenguaje de marcado extensible (XML) es un formato de datos basado en texto que se utiliza para estructurar y almacenar datos de una manera que sea legible por humanos y por máquinas. Se utiliza en servicios web, sistemas de identidad e intercambio de datos entre aplicaciones. 

Al igual que HTML, XML está estructurado con etiquetas diseñadas para representar datos. Admite elementos y atributos anidados, lo que permite jerarquías complejas.

XML se utiliza a menudo en los protocolos SOAP, SAML y WS-Security.

<User>

 <Name>Bob</Name>

 <Role>Admin</Role>

</User> 

Una firma XML es una firma digital aplicada a datos XML, definida por la especificación W3C XML Signature. El elemento XML Signature ayuda a garantizar la integridad de los datos al afirmar que los datos son confiables, verificables y no han sido manipulados.

• Una parte del documento XML se selecciona para firmar mediante el uso de un <Reference> elemento con un ID (por ejemplo, #ID123).
  
  

• Se calcula un hash o resumen a partir de esos datos.

• El hash se cifra con la clave privada del remitente para formar la firma.

• A <Signature> el bloque se agrega al documento con SignedInfo, que contiene el URI de referencia, SignatureValue con el hash cifrado y KeyInfo, como clave pública o certificado.

<ds:Signature>

 <ds:SignedInfo>

  <ds:Reference URI=”#ID123”/>

  <!-- Otros detalles como DigestMethod, CanonicalizationMethod -->

 </ds:SignedInfo>

 <ds:SignatureValue> ABC123xyz...</ds:SignatureValue>

</ds:Signature>

Los ataques de envoltura de firmas XML explotan la flexibilidad estructural de XML para engañar a las aplicaciones para que procesen datos no autenticados mientras pasan la validación de firmas. Los atacantes crean una discrepancia entre el elemento que se firma y el elemento realmente procesado (normalmente mediante la duplicación o reubicación de elementos). El resultado es que la aplicación utiliza contenido sin firmar, aunque la firma parezca válida.

Así es como suelen funcionar los ataques de envoltura de firmas XML (XSW):

• Los atacantes comienzan con un mensaje XML real y confiable, como una respuesta de inicio de sesión válida firmada digitalmente (como una respuesta SAML legítima). 

• Mueven la parte firmada (a la que se hace referencia en el) <ds:Reference URI=”#ID123”/> a un lugar diferente en el documento donde todavía está técnicamente presente pero no se utiliza. 

• Pusieron datos falsificados en la ubicación original. Estos datos falsificados no están firmados, pero están diseñados para parecer legítimos. 

• La mayoría de las aplicaciones buscan datos por nombre de etiqueta o expresión XPath, no comprobando si es la versión firmada, por lo que terminan utilizando los datos falsificados. 

• La firma digital aún se verifica porque está verificando la parte original firmada (ahora oculta), no la parte falsificada que utiliza la aplicación. 

Entonces, la aplicación piensa que está trabajando con un documento firmado seguro, pero en realidad está actuando sobre datos manipulados y no autorizados.

Este ejemplo demuestra cómo un atacante puede manipular una aserción SAML firmada para obtener acceso de administrador no autorizado mediante la explotación de una lógica de validación y análisis XML débil.

SAML es un protocolo basado en XML que se utiliza para intercambiar de forma segura información de autenticación entre dos sistemas: el proveedor de identidad (IdP) y el proveedor de servicios (SP). Permite el inicio de sesión único (SSO), lo que permite a los usuarios autenticarse una vez y obtener acceso a múltiples servicios sin inicios de sesión repetidos.

Esta es una solicitud SAML genuina capturada por una herramienta como SAML Raider en Burp Suite. Incluye una sección firmada digitalmente, conocida como aserción SAML, que contiene los detalles de identidad del usuario. Dentro de esta afirmación está la <NameID> etiqueta que normalmente representa la identidad de un usuario normal. 

La solicitud también contiene una firma digital válida (<ds:Signature> ), lo que ayuda a garantizar que el contenido de la aserción no haya sido manipulado. En esta etapa, la solicitud es segura, confiable y funciona según lo previsto.

En la respuesta de la aplicación, muestra que el usuario inició sesión con la identidad del campo <NameID> original (la dirección de correo electrónico de un usuario normal). La aplicación lee y utiliza correctamente la información de los datos SAML firmados como se esperaba.

El atacante modifica en secreto la solicitud SAML moviendo la aserción original firmada digitalmente a otra parte del documento XML, lo que permite que la firma siga siendo válida y pase la verificación. 

Una falsificación <Assertion> luego se inserta en su lugar, que contiene una falsificación <NameID> falso como admin@libcurl.so. La aplicación termina utilizando esta nueva aserción, sin firmar y controlada por el atacante, en lugar de los datos originales firmados. 

Esta actividad ilustra el concepto central de un ataque XSW: la firma digital parece válida, pero los datos procesados por la aplicación son falsos y no confiables.

Como resultado, la aplicación otorga acceso de administrador en función de la aserción falsa inyectada por el atacante. No puede verificar si la aserción que procesó era la que realmente estaba firmada digitalmente. Esta falla permite al atacante suplantar con éxito a un usuario administrador. El sistema que permite al usuario iniciar sesión como admin@libcurl.so demuestra claramente que el ataque de envoltura de firmas XML tuvo éxito.

Este ejemplo muestra cómo se puede engañar a una verificación de firma XML débil para que confíe en datos falsos. El atacante no rompe la firma digital. En cambio, los datos firmados se mueven a otro lugar y la información falsa se coloca donde la aplicación espera los datos reales. Luego, la aplicación procesa por error los datos falsos, creyendo que son seguros.

Los ataques XSW generalmente se dividen en algunos subconjuntos o tipos principales, cada uno de los cuales explota la forma en que se implementan la verificación y el análisis de la firma XML.

Aquí hay un desglose de los más comunes:

Método: el atacante mueve el elemento firmado a una parte diferente del documento XML e inserta un elemento malicioso en su lugar original.

Objetivo: la firma sigue verificando (porque los datos firmados no se modifican), pero la aplicación procesa los datos inyectados por el atacante en su lugar.

Ejemplo: lo firmado <Assertion> se traslada a <Extra> y se reemplaza por una firma falsa <Assertion> que otorga derechos de administrador.

Método: el atacante explota el uso de atributos de ID XML para hacer referencia a datos firmados.

Objetivo: el atacante crea un elemento duplicado con el mismo ID, pero lo coloca en una ubicación que la aplicación procesa primero.

Ejemplo: la firma hace referencia a #ID-1234, pero el analizador utiliza el elemento falso del atacante con ese ID en lugar del firmado.

Método: el atacante manipula los espacios de nombres XML para confundir la validación de firmas.

Objetivo: cambiar la interpretación de los elementos u omitir las comprobaciones estrictas del esquema manteniendo la validez de la firma.

Ejemplo: Inyectar un <Assertion> elemento malicioso en un nuevo espacio de nombres para que la validación pase, pero la lógica de procesamiento la acepte.

Método: modifica la ubicación <Signature> dentro del XML firmado para que la validación cubra la parte incorrecta del documento. 

Objetivo: hacer que el validador piense que todo está firmado, pero excluir las partes controladas por el atacante de la cobertura de la firma.

Ejemplo: Mover el original <ds:Signature> fuera de lo firmado <Assertion> en un contenedor e insertar un nuevo sin firmar <Assertion> (como <NameID>admin@libcurl.so</NameID> ). La firma aún se valida, pero la aplicación termina procesando la aserción controlada por el atacante.

Método: manipula las consultas XPath utilizadas durante la validación de firmas para apuntar a los nodos controlados por el atacante en lugar del nodo firmado.

Objetivo: engañar al verificador de firmas para que verifique datos inofensivos mientras la aplicación procesa datos maliciosos.

Ejemplo: modifique el XML para que el XPath del verificador (por ejemplo, //Assertion[@ID=’A1’] ) se manipula para que coincida con un nodo inofensivo mientras que un atacante controlado <Assertion> Con <NameID>admin@libcurl.so</NameID> se encuentra donde lee la aplicación. La firma se verifica, pero la aplicación procesa el nodo malicioso.

Los ataques XSW pueden tener graves consecuencias en el mundo real, especialmente cuando se trata de datos confidenciales u operaciones críticas. Estos escenarios hipotéticos destacan el impacto potencial de tales ataques.

Escenario: una aplicación empresarial utiliza el inicio de sesión único basado en SAML para autenticar a los usuarios. Cada respuesta de inicio de sesión incluye una aserción SAML firmada digitalmente que identifica al usuario. 

Ataque XSW: un atacante captura una respuesta SAML legítima, mueve la aserción firmada a una parte diferente del documento XML e inserta una aserción falsificada que afirma ser un administrador en su lugar. 

Impacto: el sistema valida la firma en la aserción original, pero procesa la aserción inyectada por el atacante sin firmar, lo que le da al actor de amenazas acceso como usuario privilegiado.

Escenario: una interfaz de programación de aplicaciones (API) de servicios web utiliza SOAP y WS-Security para procesar solicitudes. El cuerpo del mensaje SOAP está firmado digitalmente para ayudar a garantizar que el comando sea confiable.

Ataque XSW: el atacante envuelve el cuerpo SOAP original firmado en un elemento contenedor inofensivo y lo reemplaza con un nuevo cuerpo sin firmar que contiene privilegios elevados o acciones no autorizadas.

Impacto: si el servicio procesa el cuerpo sin firmar, el atacante puede escalar privilegios o realizar acciones restringidas, como ver o modificar datos confidenciales.

Escenario: una interfaz administrativa permite a los usuarios enviar comandos basados en XML, como la eliminación de cuentas o el restablecimiento de contraseñas, protegidos por firmas digitales.

Ataque XSW: el atacante mueve el comando firmado a una ubicación secundaria e inyecta un comando sin firmar (como eliminar la cuenta de otro usuario o restablecer la contraseña de un administrador) en su lugar.

Impacto: si la aplicación procesa el comando sin firmar, puede realizar operaciones críticas en nombre de un usuario no autorizado.

Escenario: un banco protege sus operaciones de transferencia de fondos mediante el uso de firmas XML. Cada solicitud contiene detalles de la transacción, como el monto de la transferencia y los números de cuenta del remitente y el destinatario. Las solicitudes se firman digitalmente para ayudar a garantizar la autenticidad.

Ataque XSW: un atacante captura una solicitud de transferencia válida, reubica los datos firmados en una sección no crítica del documento e inserta una transacción falsificada con una cantidad mayor y una cuenta de destinatario diferente.

Impacto: si la aplicación no verifica estrictamente que la transacción procesada sea la que se firmó, podría ejecutar la transacción falsificada del atacante, lo que daría lugar a transferencias no autorizadas y pérdidas financieras.

Escenario: una plataforma en línea protege sus tokens de autenticación mediante firmas digitales XML. Cada token contiene información de identidad del usuario y derechos de acceso, y está firmado criptográficamente para evitar manipulaciones.

Ataque XSW: un atacante captura un token de autenticación válido, mueve la parte firmada a otra ubicación dentro del XML e inyecta un nuevo segmento sin firmar que incluye privilegios elevados o no autorizados.

Impacto: si el servidor procesa la sección manipulada en lugar de la firmada, el atacante puede obtener acceso no autorizado o realizar operaciones privilegiadas, comprometiendo la seguridad de la aplicación.

Para analizar si una aplicación es vulnerable a los ataques de envoltura de firmas XML, es importante comprender cómo analiza y procesa los datos XML. Es especialmente importante comprender el análisis y procesamiento de XML en contextos sensibles a la seguridad, como la autenticación SAML o la mensajería SOAP.

Estas son algunas técnicas y estrategias de prueba para identificar dichas vulnerabilidades en entornos reales:

Compruebe si la aplicación extrae elementos como <Assertion> basado en el nombre de la etiqueta, XPath o posición en lugar de verificar que es el elemento realmente firmado. Este comportamiento es una señal de advertencia grave de vulnerabilidad a los ataques XSW.

Utilice Burp Suite con SAML Raider para inyectar un elemento falso sin firmar y envolver el firmado. Si la aplicación procesa los datos falsos mientras la firma aún se valida, es vulnerable a XSW.

Inserte una aserción firmada en una sección oculta y una falsa en un lugar visible. Si la aplicación procesa los datos falsos, es vulnerable a XSW.

Reubique el elemento firmado (el que se menciona en <ds:Reference URI=”#some-id” /> ) a una parte diferente del XML. Luego, inyecte un elemento nuevo, sin firmar, con una estructura similar en su lugar original.

Si la aplicación procesa la versión sin firmar en lugar de la que realmente está firmada, entonces la aplicación es vulnerable a un ataque XSW. La aplicación valida la firma correctamente, pero no se asegura de que esté utilizando el contenido firmado, lo que permite a los atacantes inyectar datos no autorizados.

Envíe afirmaciones mal formadas y observe errores detallados o respuestas incoherentes. Estas respuestas pueden exponer debilidades en la lógica de validación y seguridad XML de la aplicación.

Utilice herramientas como SAML Raider, SoapUI o arneses de prueba XML personalizados para aplicar patrones de ataque XSW. Si la aplicación acepta y procesa cualquiera de las cargas útiles, indica una vulnerabilidad XSW.

Si la aplicación lee datos XML seleccionando elementos basados en el nombre de la etiqueta sin asegurarse de que está utilizando el elemento firmado y confiable, puede ser engañada para procesar datos falsos.

Para proteger una aplicación de los ataques XSW, los desarrolladores pueden implementar un procesamiento XML estricto, validar las firmas correctamente y garantizar que solo se utilicen datos firmados y confiables.

Estas son algunas contramedidas específicas que pueden ayudar a defenderse contra los ataques XSW:

Estas prácticas pueden reducir el riesgo de que los atacantes exploten las estructuras XML y la lógica de procesamiento de firmas, cerrando efectivamente la puerta a muchos ataques XSW.