SAML Attacks
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
SAMLExtractor: Una herramienta que puede tomar una URL o lista de URL y devuelve la URL de consumo SAML.
En XML, la parte firmada del XML se guarda en memoria, luego se realiza alguna codificación/decodificación y se verifica la firma. Idealmente, esa codificación/decodificación no debería cambiar los datos, pero basado en ese escenario, los datos que se están verificando y los datos originales podrían no ser los mismos.
Por ejemplo, revisa el siguiente código:
Ejecutar el programa contra REXML 3.2.4 o anterior resultaría en la siguiente salida en su lugar:
This is how REXML saw the original XML document from the program above:
And this is how it saw it after a round of parsing and serialization:
For more information about the vulnerability and how to abuse it:
En XML Signature Wrapping attacks (XSW), los adversarios explotan una vulnerabilidad que surge cuando los documentos XML se procesan a través de dos fases distintas: validación de firma y invocación de función. Estos ataques implican alterar la estructura del documento XML. Específicamente, el atacante inyecta elementos falsificados que no comprometen la validez de la Firma XML. Esta manipulación tiene como objetivo crear una discrepancia entre los elementos analizados por la lógica de la aplicación y aquellos verificados por el módulo de verificación de firma. Como resultado, mientras que la Firma XML sigue siendo técnicamente válida y pasa la verificación, la lógica de la aplicación procesa los elementos fraudulentos. En consecuencia, el atacante elude efectivamente la protección de integridad y la autenticación de origen de la Firma XML, permitiendo la inyección de contenido arbitrario sin detección.
Los siguientes ataques se basan en este blog y este documento. Así que revisa esos para más detalles.
Estrategia: Se agrega un nuevo elemento raíz que contiene la firma.
Implicación: El validador puede confundirse entre el legítimo "Response -> Assertion -> Subject" y el "malvado nuevo Response -> Assertion -> Subject" del atacante, lo que lleva a problemas de integridad de datos.
Diferencia de XSW #1: Utiliza una firma separada en lugar de una firma envolvente.
Implicación: La estructura "malvada", similar a XSW #1, tiene como objetivo engañar a la lógica de negocio después de la verificación de integridad.
Estrategia: Se crea una Assertion malvada al mismo nivel jerárquico que la assertion original.
Implicación: Tiene la intención de confundir a la lógica de negocio para que use los datos maliciosos.
Diferencia de XSW #3: La Assertion original se convierte en un hijo de la Assertion duplicada (malvada).
Implicación: Similar a XSW #3 pero altera la estructura XML de manera más agresiva.
Aspecto Único: Ni la Firma ni la Assertion original se adhieren a configuraciones estándar (envolvente/envolvente/separada).
Implicación: La Assertion copiada envuelve la Firma, modificando la estructura del documento esperada.
Estrategia: Inserción en una ubicación similar a XSW #4 y #5, pero con un giro.
Implicación: La Assertion copiada envuelve la Firma, que luego envuelve la Assertion original, creando una estructura engañosa anidada.
Estrategia: Se inserta un elemento Extensions con la Assertion copiada como hijo.
Implicación: Esto explota el esquema menos restrictivo del elemento Extensions para eludir las contramedidas de validación de esquema, especialmente en bibliotecas como OpenSAML.
Diferencia de XSW #7: Utiliza otro elemento XML menos restrictivo para una variante del ataque.
Implicación: La Assertion original se convierte en un hijo del elemento menos restrictivo, invirtiendo la estructura utilizada en XSW #7.
Puedes usar la extensión de Burp SAML Raider para analizar la solicitud, aplicar cualquier ataque XSW que elijas y lanzarlo.
Si no sabes qué tipo de ataques son XXE, por favor lee la siguiente página:
XXE - XEE - XML External EntityLas respuestas SAML son documentos XML desinflados y codificados en base64 y pueden ser susceptibles a ataques de Entidad Externa XML (XXE). Al manipular la estructura XML de la Respuesta SAML, los atacantes pueden intentar explotar vulnerabilidades XXE. Aquí se muestra cómo se puede visualizar tal ataque:
También puedes usar la extensión de Burp SAML Raider para generar el POC a partir de una solicitud SAML para probar posibles vulnerabilidades XXE y vulnerabilidades SAML.
Consulta también esta charla: https://www.youtube.com/watch?v=WHn-6xHL7mI
Para más información sobre XSLT, ve a:
XSLT Server Side Injection (Extensible Stylesheet Language Transformations)Las Transformaciones de Lenguaje de Hojas de Estilo Extensibles (XSLT) se pueden usar para transformar documentos XML en varios formatos como HTML, JSON o PDF. Es crucial notar que las transformaciones XSLT se realizan antes de la verificación de la firma digital. Esto significa que un ataque puede tener éxito incluso sin una firma válida; una firma autofirmada o inválida es suficiente para proceder.
Aquí puedes encontrar un POC para verificar este tipo de vulnerabilidades; en la página de hacktricks mencionada al principio de esta sección puedes encontrar cargas útiles.
También puedes usar la extensión de Burp SAML Raider para generar el POC a partir de una solicitud SAML para probar posibles vulnerabilidades de XSLT.
Consulta también esta charla: https://www.youtube.com/watch?v=WHn-6xHL7mI
La Exclusión de Firma XML observa el comportamiento de las implementaciones SAML cuando el elemento de Firma no está presente. Si este elemento falta, la validación de la firma puede no ocurrir, haciéndolo vulnerable. Es posible probar esto alterando los contenidos que normalmente son verificados por la firma.
También puedes usar la extensión de Burp SAML Raider. Intercepta la Respuesta SAML y haz clic en Remove Signatures. Al hacerlo, todos los elementos de Firma son eliminados.
Con las firmas eliminadas, permite que la solicitud continúe hacia el objetivo. Si la Firma no es requerida por el Servicio
La Falsificación de Certificado es una técnica para probar si un Proveedor de Servicios (SP) verifica correctamente que un Mensaje SAML está firmado por un Proveedor de Identidad (IdP) de confianza. Implica usar un *certificado autofirmado para firmar la Respuesta o Afirmación SAML, lo que ayuda a evaluar el proceso de validación de confianza entre SP e IdP.
Los siguientes pasos describen el proceso utilizando la extensión de Burp SAML Raider:
Intercepta la Respuesta SAML.
Si la respuesta contiene una firma, envía el certificado a SAML Raider Certs usando el botón Send Certificate to SAML Raider Certs.
En la pestaña de Certificados de SAML Raider, selecciona el certificado importado y haz clic en Save and Self-Sign para crear un clon autofirmado del certificado original.
Regresa a la solicitud interceptada en el Proxy de Burp. Selecciona el nuevo certificado autofirmado del menú desplegable de Firma XML.
Elimina cualquier firma existente con el botón Remove Signatures.
Firma el mensaje o la afirmación con el nuevo certificado usando el botón (Re-)Sign Message o (Re-)Sign Assertion, según corresponda.
Reenvía el mensaje firmado. La autenticación exitosa indica que el SP acepta mensajes firmados por tu certificado autofirmado, revelando posibles vulnerabilidades en el proceso de validación de los mensajes SAML.
La Confusión de Destinatario de Token y la Confusión de Objetivo de Proveedor de Servicios implican verificar si el Proveedor de Servicios valida correctamente el destinatario previsto de una respuesta. En esencia, un Proveedor de Servicios debería rechazar una respuesta de autenticación si estaba destinada a un proveedor diferente. El elemento crítico aquí es el campo Recipient, que se encuentra dentro del elemento SubjectConfirmationData de una Respuesta SAML. Este campo especifica una URL que indica dónde debe enviarse la Afirmación. Si el destinatario real no coincide con el Proveedor de Servicios previsto, la Afirmación debe considerarse inválida.
Para que un ataque de Confusión de Destinatario de Token SAML (SAML-TRC) sea factible, deben cumplirse ciertas condiciones. En primer lugar, debe haber una cuenta válida en un Proveedor de Servicios (denominado SP-Legit). En segundo lugar, el Proveedor de Servicios objetivo (SP-Target) debe aceptar tokens del mismo Proveedor de Identidad que sirve a SP-Legit.
El proceso de ataque es sencillo bajo estas condiciones. Se inicia una sesión auténtica con SP-Legit a través del Proveedor de Identidad compartido. La Respuesta SAML del Proveedor de Identidad a SP-Legit es interceptada. Esta Respuesta SAML interceptada, originalmente destinada a SP-Legit, se redirige a SP-Target. El éxito en este ataque se mide por la aceptación de la Afirmación por parte de SP-Target, otorgando acceso a recursos bajo el mismo nombre de cuenta utilizado para SP-Legit.
La investigación original se puede acceder a través de este enlace.
Durante el proceso de fuerza bruta de directorios, se descubrió una página de cierre de sesión en:
Al acceder a este enlace, se produjo una redirección a:
Esto reveló que el parámetro base acepta una URL. Considerando esto, surgió la idea de sustituir la URL por javascript:alert(123); en un intento de iniciar un ataque XSS (Cross-Site Scripting).
La herramienta SAMLExtractor se utilizó para analizar subdominios de uberinternal.com para dominios que utilizan la misma biblioteca. Posteriormente, se desarrolló un script para apuntar a la página oidauth/prompt. Este script prueba XSS (Cross-Site Scripting) ingresando datos y verificando si se reflejan en la salida. En los casos en que la entrada se refleja, el script marca la página como vulnerable.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
